4 Customizing the Domain Environment

While creating a domain, you can (optionally) perform certain advanced configuration tasks such:

To perform the advanced configuration tasks, you must select the appropriate check boxes in the Select Advanced Configuration screen.

The Configuration Wizard guides you through the following configuration tasks.

Configuring the Administration Server

In every domain, one server must be designated as the administration server: the central point from which the whole domain is managed.

You can access the administrator server by using the URL protocol://listen-address:listen-port. The protocol can be any of the following: t3, t3s, http, https.

Table 4-1 describes the fields in the Configure the Administration Server screen. Specify the appropriate values, and click Next to proceed.

Note:

Fields marked with an asterisk (*) are mandatory fields.

Table 4-1 Configuring the Administration Server

Field Description

Name*

Enter a valid server name: a string of characters.

Each server instance in the production environment must have a unique name, regardless of the domain or cluster in which it resides, and regardless of whether it is an administration server or a managed server. In addition, the name of the administration server must be unique among all component names within the domain.

Note: This value is specified for identification purposes only. It is not used as part of the URL for applications that are deployed on the server. The server name is displayed in the WebLogic Server administration console. In addition, if you use WebLogic Server command-line utilities or APIs, you must specify this name to identify the server.

Listen address

From the drop-down list, select a value for the listen address.

If you select localhost as the listen address for a server instance, remote processes cannot connect to that server instance. Only processes on the machine that hosts the server instance can connect to the server instance. If the server instance must be accessible as localhost (for example, if you create administrative scripts that connect to localhost), and it must also be accessible by remote processes, select All Local Addresses. The server instance determines the address of the machine and listens on it.

For more information, see Specifying the Listen Address.

Listen port

Enter a valid value for the listen port to be used for regular, nonsecure requests (through protocols such as HTTP and T3). The default value is 7001 for the administration server. If you leave this field blank, the default value is used. The valid listen port range is from 1 to 65535.

For more information, see Specifying the Listen Port.

SSL enabled

Select this check box to enable the SSL listen port. By default, SSL is disabled for all new servers.

SSL listen port

This field is enabled only if the SSL enabled check box is selected.

Enter a valid value to be used for secure requests (through protocols such as HTTPS and T3S). The default value is 7002. If you leave this field blank, the default value is used.

The valid listen port range is from 1 to 65535.

Note: By default, a server instance uses demonstration certificates to authenticate requests from a secure port. In a production environment, you must configure SSL to use certificates from a certificate authority. For more information, see "Configuring SSL" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

For more information, see Specifying the Listen Port.


Specifying the Listen Address

Table 4-2 provides guidelines for specifying the listen address for a server.

Table 4-2 Specifying Listen Address

Listen Address Behavior

All Local Addresses or a DNS name

On multi-homed Windows machines, a server instance binds to all available IP addresses.

An IP address or a DNS name

  • To connect to the server instance, processes can specify either the IP address or the corresponding DNS name.

  • Processes that specify localhost fail to connect.

  • You must update existing processes that use localhost to connect to the server instance.

  • For connections that specify the IP address for the listen address and a secured port for the listen port, host name verification must be disabled.

Note: To resolve a DNS name to an IP address, WebLogic Server must be able to contact an appropriate DNS server or obtain the IP address mapping locally. Therefore, if you specify a DNS name for the listen address, you must either leave a port open long enough for the WebLogic Server instance to connect to a DNS server and cache its mapping or you must specify the IP address mapping in a local file. If you specify an IP address for the listen address and then a client request specifies a DNS name, WebLogic Server attempts to resolve the DNS name, but if it cannot access DNS name mapping, the request fails.

localhost

  • Processes must specify localhost to connect to the server instance.

  • Only processes that reside on the machine that hosts the server instance (local processes) can connect to the server instance.


Specifying the Listen Port

Note the following guidelines when specifying the listen ports and secure listen port:

  • Although you can specify any valid port number, if you specify port 80, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port 80 as the listen port, you can use the URL: http://hostname/myfile.html instead of http://hostname:portnumber/myfile.html.

  • On some operating systems, port 80 can be accessed only by processes run under a privileged user or group ID. In this case, you can assign the server instance to a UNIX machine on which a post-bind UID or GID is defined.

Configuring Managed Servers

In production environments, enterprise applications are hosted, typically, on one or more managed servers, in addition to the administration server.

You can add and delete managed servers in the Configure Managed Servers screen of the Configuration Wizard.

Note:

You can create managed servers on remote machines by using the pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.
  1. Review the current managed server configurations. Default values may vary based on the domain source you selected earlier.

    Note:

    The wizard provides two views: a concise tabular view of all the managed servers and an individual view of each managed server with each server represented by a tab. To toggle the view mode between table and tab views, click Switch Display.
  2. Add or delete managed servers, or change the settings for existing managed servers, as required for your domain.

    The columns in this screen are identical to the fields in the Configure the Administration Server screen. For more information, see Configuring the Administration Server.

  3. After configuring the managed servers, click Next in the wizard to proceed.

Configuring Clusters

A cluster is a group of WebLogic Server instances that work together to provide scalability and high-availability for applications. By creating clusters, you can group managed servers such that they operate as a single unit for hosting applications and resources.

You can add, configure, and delete clusters in the Configure Clusters screen of the Configuration Wizard. This screen is displayed only if the domain contains at least one managed server.

  1. Review the current cluster configuration. Default values may vary, based on the domain source you selected earlier.

    Note:

    The wizard provides two views: a concise tabular view of all the clusters, and an individual view of each cluster with each cluster represented by a tab. To toggle the view mode between table and tab views, click Switch Display.
  2. Add or delete clusters, or change the settings for existing clusters, as required for your domain.

    Note:

    Fields marked with an asterisk (*) are mandatory fields.

    Table 4-3 Configuring Clusters

    Field Action

    Name*

    Enter a valid name for the cluster: a string of characters.

    The name of the cluster must be unique among all component names within the domain.

    The default value in this field is new_Cluster_n, where n is a numeric value that is used to differentiate among all the default cluster names; the value of n for the first cluster is 1. The value is incremented by 1 for each cluster that you add.

    Cluster messaging mode

    Select the cluster message mode: unicast or multicast.

    Multicast address

    If you selected multicast as the cluster message mode, enter the multicast address for the cluster.

    This address is used by cluster members to communicate with each other. The default value is 239.192.0.0.

    The valid multicast address range is 224.0.0.1 to 239.255.255.255.

    Multicast port

    If you selected multicast as the cluster message mode, enter the multicast port for the cluster.

    The multicast port is used by cluster members to communicate with each other. The default value is 7001.

    Valid values for multicast ports are from 1 to 65535.

    Cluster address

    Enter the addresses to identify the managed servers in the cluster.

    A cluster address can be one of the following:

    • Comma-separated list of IP addresses or DNS names and ports (for example: dns_name:port, dns_name:port)

    • DNS name that maps to multiple IP addresses

    • localhost, DNS name, or IP address if the listen address of all managed servers is listening to the same address with unique port numbers

    The cluster address is used in entity and stateless EJBs to construct the host name portion of URLs. If the cluster address is not set, EJB handles may not work properly.


  3. After configuring the clusters, click Next.

For more information, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server.

Assigning Managed Servers to Clusters

You can assign the available managed servers to clusters within the domain in the Assign Servers to Clusters screen.

This screen is displayed only if you have defined at least one cluster.

  1. In the Cluster pane, select the cluster to which you want to assign a managed server.

  2. Assign managed servers to the selected cluster in one of the following ways:

    • Double-click the name of the managed server in the Server pane.

    • Select the managed server and click the right arrow.

    • Shift+click to select multiple managed servers; then, click the right arrow.

    The name of the managed server is removed from the Server pane and added below the name of the target cluster in the Cluster pane.

    Note:

    Only managed servers are listed in the Server pane. The administration server is not listed because it cannot be assigned to a cluster.
  3. Repeat steps 1 and 2 for each managed server to assign to a cluster.

  4. Review the cluster assignments.

    If necessary, you can remove a managed server from a cluster in one of the following ways:

    • Double-click the name of the managed server in the Cluster pane.

    • Select the managed server and click the left arrow.

    The name of the managed server is removed from the Cluster pane and restored to the Server pane.

  5. Click Next.

Creating HTTP Proxy Applications

An HTTP proxy application acts as an intermediary for HTTP requests.

In the Create HTTP Proxy Applications screen of the Configuration Wizard, you can create an HTTP proxy application for each cluster, and specify the managed server on which the proxy application must be deployed.

This screen is displayed only if both of the following statements are true:

  • At least one managed server is assigned to a cluster.

  • At least one managed server is not assigned to any cluster.

To create HTTP proxy applications:

  1. Select the Create HTTP Proxy check box against the cluster for which you want to create the HTTP proxy application.

    A list of the managed servers that are not assigned to any cluster is displayed in the Proxy Server list.

  2. From the Proxy Server list, select a managed server on which the proxy application must be deployed.

    A proxy application named OracleProxy4_clustername_servername is created and deployed in the managed server.

  3. Repeat steps 1 through 3 for each cluster for which you want to create HTTP proxy applications.

  4. Click Next in the wizard to proceed.

Configuring Machines

In a domain, the machine definitions identify physical units of hardware and are used to associate computers with the WebLogic Server instances that they host.

You might want to create machine definitions in situations such as the following:

  • The administration server uses the machine definition, with the node manager application, to start remote servers.

  • WebLogic Server uses configured machine names when determining the server in a cluster that is best able to handle certain tasks, such as HTTP session replication. WebLogic Server then delegates those tasks to the identified server.

    Note:

    You must configure machines for each product installation that runs a node manager process. The machine configuration must include values for the listen address and port number parameters.

You can create machine definitions in the Configure Machines screen of the Configuration Wizard.

  1. Select the Machine tab (for Windows) and Unix Machine tab (for UNIX).

  2. Review the current list of configurations, and add or change settings as required for your domain.

    • To add a machine, click Add.

    • To delete a machine, select the machine in the list and click Delete.

    Table 4-4 describes the configuration settings that you can define. Default values may vary based on the domain source that you selected earlier.

    Note:

    Fields marked with an asterisk (*) are mandatory fields.

    Table 4-4 Configure Machine

    Field Description

    Name*

    Enter a valid machine name: a string of characters.

    The machine name is used to identify the machine within the WebLogic Server domain; it does not have to match the network name for the machine.

    The name must be unique among all component names within the domain.

    The default value in this field is new_[Unix]Machine_n, where n is a numeric value that is used to differentiate among all default machine names; the value of n for the first machine is 1. The value is incremented by 1 for each machine that you add.

    Node manager listen address

    Select a value from the drop-down list for the listen address used by node manager to listen for connection requests. By default, the IP addresses defined for the local system and localhost are shown in the drop-down list. The default value is localhost.

    If you specify an IP address for a machine that hosts the administration server and you need to access the WebLogic Server Node Manager, you must disable host name verification.

    For more information, see "Using Host Name Verification" in Oracle Fusion Middleware Securing Oracle WebLogic Server.

    Node manager listen port

    Enter a valid value for the listen port used by Node Manager to listen for connection requests.

    The valid node manager listen port range is from 1 to 65535.

    The default value is 5556.

    Post bind GID enabled

    This field is displayed only in the Unix Machine tab.

    Select this check box to enable a server running on this machine to bind to a UNIX group ID (GID) after it finishes all privileged startup actions. By default, this check box is not selected.

    Post bind GID

    This field is displayed only in the Unix Machine tab.

    Enter a valid UNIX group ID (GID) that a server running on this machine will run under after it finishes all privileged startup actions. Otherwise, the server continues to run under the group from which it was started. For this setting to take effect, you must select the Post bind GID enabled check box.

    Post bind UID enabled

    This field is displayed only in the Unix Machine tab.

    Select this check box to enable a server running on this machine to bind to a UNIX user ID (UID) after it finishes all privileged startup actions. By default, this check box is not selected.

    Post bind UID

    This field is displayed only in the Unix Machine tab.

    Enter a valid UNIX user ID (UID) that a server running on this machine will run under after it finishes all privileged startup actions. Otherwise, the server continues to run under the account from which it was started. For this setting to take effect, you must select the Post bind UID enabled check box.


  3. After updating the settings, click Next.

The Assign Servers to Machines screen is displayed.

Assigning Servers to Machines

After configuring servers and defining machines, you can assign WebLogic Server instances to machines in the Assign Servers to Machines screen.

This screen is displayed only if you have defined at least one machine.

  1. In the Machine pane, select the Windows or UNIX machine to which you want to assign a WebLogic Server instance.

  2. Assign WebLogic Server instances to the selected machine in one of the following ways:

    • Double-click the WebLogic Server instance in the Server pane.

    • Select the appropriate WebLogic Server instance in the Server pane and click the right arrow.

    • Shift+click to select multiple servers in the Server pane; then, click the right arrow.

    The name of the WebLogic Server instance is removed from the Server pane and added, below the name of the target machine, in the Machine pane.

  3. Repeat steps 1 and 2 for each WebLogic Server instance to assign to a machine.

  4. Review the machine assignments.

    If necessary, you can remove a WebLogic Server instance from a machine in one of the following ways:

    • Double-click the name of the appropriate WebLogic Server instance in the Machine pane.

    • Select the appropriate WebLogic Server instance in the Machine pane and click the left arrow.

    The name of the WebLogic Server instance is removed from the Machine pane and restored to the Server pane.

  5. Click Next.

Targeting Deployments to Clusters or Servers

The Target Deployments to Clusters or Servers screen of the Configuration Wizard is displayed only if the selected template contains J2EE applications or libraries.

In this screen you can target applications and libraries for deployment on servers or clusters.

Applications and libraries associated with the product for which you are configuring the domain (for example, SOA) are targeted automatically to the managed server created for that product or to the cluster to which that managed server is assigned. In this screen, you can target applications and libraries to additional servers and clusters.

Note:

When you extend a domain, if you delete a managed server or cluster to which applications are currently targeted, the Configuration Wizard automatically retargets those applications as follows:
  • If the applications were originally targeted solely to the managed server or cluster that you are now deleting (that is, after you delete the managed server or cluster, the applications would become untargeted in the modified domain), then the Configuration Wizard automatically retargets the applications to all eligible targets.

    An eligible target is any cluster or managed server that is not defined in the configuration groups specification (config-groups.xml file) of an included template. Servers or clusters that are specified in config-groups.xml are essentially owned by the template and, therefore, are not eligible for automatic targeting.

  • If the applications were originally targeted to multiple targets (including managed servers, clusters, and the administration server), and one of the targeted managed servers or clusters is deleted, then, in the extended domain, the Configuration Wizard leaves the remaining target associations intact and does not attempt to retarget the applications.

  1. In the Target pane, select the cluster or server on which you want to deploy applications or libraries.

    The name of the selected target is displayed as the title of the right pane.

  2. In the right pane, select the check boxes corresponding to the applications or libraries to deploy on the selected target.

    The applications and libraries displayed here vary, depending on the products that you selected in the Select Domain Source screen, earlier in the wizard.

    Note:

    When you select a managed server in the Target pane, some of the check boxes in the right pane might be disabled, indicating applications and libraries that are already targeted at the cluster that contains the selected managed server.

    After you select applications and libraries, the names of the targeted clusters and servers are displayed in the Target column in the right pane.

  3. Repeat steps 1 and 2 for the other clusters and servers, as required.

  4. After making the required selections, click Next.

Targeting Services to Clusters or Servers

The Target Services to Clusters or Servers screen of the Configuration Wizard is displayed only if the selected template contains J2EE services.

Services that are associated with the product for which you are configuring the domain (for example, SOA) are targeted automatically, to the managed server created for that product or to the cluster to which that managed server is assigned. In this screen, you can target services to additional servers and clusters.

Note:

When you extend a domain, if you delete a managed server or cluster to which services are currently targeted, the Configuration Wizard automatically retargets those services as follows:
  • If the services were originally targeted solely to the managed server or cluster that you are now deleting (that is, after you delete the managed server or cluster, the services would become untargeted in the modified domain), then the Configuration Wizard automatically retargets the services to all eligible targets.

    An eligible target is any cluster or managed server that is not defined in the configuration groups specification (config-groups.xml file) of an included template. Servers or clusters that are specified in config-groups.xml are essentially owned by the template and, therefore, are not eligible for automatic targeting.

  • If the services were originally targeted to multiple targets (including managed servers, clusters, and the administration server), and one of the targeted managed servers or clusters is deleted, then, in the extended domain, the Configuration Wizard leaves the remaining target associations intact and does not attempt to retarget the services.

  1. In the Target pane, select the cluster or server on which you want to deploy services.

    The name of the selected target is displayed as the title of the right pane.

  2. In the right pane, select the check boxes corresponding to the services to deploy on the selected target.

    The services displayed here vary, depending on the products that you selected in the Select Domain Source screen earlier in the wizard.

    Note:

    When you select a managed server in the Target pane, some of the check boxes in the right pane might be disabled, indicating services that are already targeted at the cluster that contains the selected managed server.

    After you select services, the names of the targeted clusters and servers are displayed in the Target column in the right pane.

  3. Repeat steps 1 and 2 for the other clusters and servers, as required.

  4. After making the required selections, click Next.

Configuring JMS File Stores

A JMS file store is a disk-based file in which persistent messages can be saved.

You can modify the JMS file stores that are configured in your domain, in the Configure JMS File Stores screen, which is displayed only if the selected template contains JMS.

  1. Review the current list of JMS file stores. Default values may vary based on the domain source that you selected earlier.

    Note:

    The wizard provides two display modes: a concise tabular view of all the defined components, and an individual view in which each component is represented by a tab. To toggle the view mode between table and tab views, click Switch Display.
  2. Modify the settings, as required for your domain.

    Table 4-5 describes the fields of the Configure JMS File Stores screen.

    Note:

    Fields marked with an asterisk (*) are mandatory fields.

    Table 4-5 Configure JMS File Stores

    Field Description

    Name*

    Enter a name for the JMS file store. The name must be a string of characters.

    The name of the JMS file store must be unique among all component names within the domain.

    Directory

    Enter the path of the directory (in your system) in which the JMS file store resides.

    Synchronous write policy

    From the drop-down list, select one of the following synchronous write policies to determine how the file store writes data to the disk:

    • Cache-Flush: Transactions cannot be completed until all their write operations have been flushed to the disk.

    • Direct-Write: Write operations are performed directly to the disk. This policy is supported on Solaris and Windows. If this policy is active on an unsupported platform, the file store switches automatically to the cache-flush policy.

    • Disabled: Transactions are complete as soon as the writes are cached in memory. When this policy is active, completion of transactions does not depend on waiting for writes to reach the disk.

      This setting affects performance, scalability, and reliability.

    Note: The use of the direct-write policy is reliable in Solaris systems, but Windows systems may leave transaction data in the on-disk cache without writing it to disk immediately. This is considered unreliable, because a power failure can cause loss of on-disk cache data, possibly resulting in lost or duplicate messages. For reliable writes using the direct-write policy on Windows, either disable all write caching for the disk (enabled by default), or use a disk with a battery-backed cache. Some file systems, however, do not allow this value to be changed (for example, a RAID system that has a reliable cache).

    Note: If the JMS file store is used exclusively for paging nonpersistent messages to the disk, the synchronous write policy is ignored.


  3. After updating the settings, click Next.

The Configure RDBMS Security Store Database screen is displayed.

Configuring the RDBMS Security Store Database

You can define RDBMS security store settings in the Configure RDBMS Security Store Database screen of the Configuration Wizard.

Table 4-6 describes the fields in the Configure RDBMS Security Store Database screen.

Note:

Fields marked with an asterisk (*) are mandatory fields.

Table 4-6 Configure RDBMS Security Store Database

Field Description

*Database Type

From the drop-down list, select the type of database to use as the RDBMS security store.

*Driver

Select the driver to use for the database.

The list of available drivers varies, depending on the database type that you select.

*Class Name

No action is required.

The class name is displayed automatically, based on the driver that you select.

*DBMS SID

Enter the SID of the database.

*DBMS Host

Enter the name of the machine that hosts the database.

*DBMS Port

Enter the port to be used to connect to the server.

The default port number that is associated with the selected database type is displayed automatically.

*URL

No action is required.

The URL is displayed automatically based on the driver that you select.

*User Name

Enter the login name for connecting to the database.

*User Password

Enter the password for accessing the database. The password rules vary, depending on the database.

The value is encrypted.

*Confirm User Password

Re-enter the password.

*Known Properties

No action is required.

The known properties of the database are displayed automatically based on the driver that you select.

Additional Properties

Enter additional properties, if any, to be passed to the driver.


After specifying the RDBMS security store settings, click Next.

Note:

You can test the connection to the database by clicking Test Connection. Before starting the server, you must load the necessary SQL scripts for the RDBMS security store. If you use an RDBMS security store in a clustered domain, it is recommended that you use it with JMS configuration (JNDI name and JMS topic). For more information, see the WebLogic Server Administration Console Online Help.

The Configuration Summary screen is displayed.

Reviewing the Domain Settings and Creating the Domain

In the Configuration Summary screen, you review the detailed configuration settings of your domain before the Configuration Wizard creates it.

  1. Select an item in the Domain Summary pane on the left and review the associated details in the Details pane on the right. You can make limited adjustments by clicking Previous to return to a previous screen.

    Note:

    You can limit the type of information displayed in the Domain Summary pane by selecting a filter from the Summary View drop-down list.
  2. After reviewing the domain settings, click Create.

    The Creating Domain screen is displayed. It displays messages indicating the progress of the domain creation process.

    When the process is complete, the new domain is ready for use.

  3. To start the server immediately, select the Start Admin Server check box and click Done. This option is available only in Windows systems.

  4. Click Done.