Weblogic Domain Configuration first part here

Configuring
Clusters and Assigning Servers to Clusters
The
screenshots show optional cluster parameters. On the Configure Clusters page,
enter a valid name for the cluster: a string of characters that can include
spaces. The name of the cluster must be unique among all the 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: This
could be “multicast”
or “unicast.” If you select “unicast,” the next two options are disabled. When
you would pick unicast over multicast or multicast over unicast is discussed
briefly on the next page and also in more detail in the lesson titled
“Introduction to Clustering.”
Multicast address: 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 through 239.255.255.255. Avoid using any address ending in .0.0.1.
Multicast port: 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 range from 1
through 65534.
Cluster address: Enter the addresses to identify the
managed servers in the cluster. A cluster address can be one of the following:
•A
comma-separated list of IP addresses or DNS names and ports (for example,
dns_name:port, dns_name:port)
•A
DNS name that maps to multiple IP addresses
•A
localhost, DNS name, or IP address if the listen address of all the managed
servers is listening to the same address with unique port numbers
The
cluster address is used in entity and stateless Enterprise JavaBeans (EJBs) to
construct the host name portion of the URLs. If the cluster address is not set,
EJB handles may not work properly.
Assigning Servers to Clusters
A
managed server may belong to zero or one cluster. A cluster may have zero, one,
or more servers. There is no point in having a cluster with zero or one server.
When to Use Multicast and When to Use Unicast
If
your machines are not on the same IP subnet, so that communications from one
machine to another need to go across several routers, possibly even over the
Internet, then multicast is not an option. But if the machines are all on the
same IP subnet, then multicast is preferable.
Creating
an HTTP Proxy Application and Configuring Machines
The
screenshots show creating proxies and machines. An HTTP proxy application acts
as an intermediary for HTTP requests.
On
the Create HTTP Proxy Applications page 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
page is displayed when you click Next on the Assign Servers to Clusters page 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.
Creating HTTP Proxy Applications
1. If
multiple clusters are defined, click the tab corresponding to the cluster for
which you want to create the HTTP proxy applications.
2. Select
the “Create HTTP proxy for cluster <cluster_name>”
check box.
A list of the managed servers that are not assigned to any cluster is displayed in the Proxy Server list.
A list of the managed servers that are not assigned to any cluster is displayed in the Proxy Server list.
3. From
the Proxy Server
list, select a managed server on which the proxy applications must be deployed.
A
proxy application named OracleProxy4_clustername_servername
is created and targeted at the managed server.
4. Repeat
steps 1 through 3 for each cluster for which you want to create the HTTP proxy
applications.
5.Click Next
to proceed.
Note: Although WebLogic Server has the built-in
function of Web and HTTP server, you may want to use the Oracle HTTP Server
covered in the lesson titled “Deployment Concepts.”
Creating Machines
In
a domain, the machine definitions identify the physical units of hardware and
are used to associate computers with the managed servers that they host.
You
might want to create machine definitions in situations such as (but not limited
to) the following:
•The
administration server uses the machine definition with the Node Manager
application to start remote servers.
•Oracle
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. Oracle 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.
The
machine name is used to identify the machine within the Oracle WebLogic Server
domain; it is not required to match the network name for the machine.
Node Manager listen address: Select
a value from the list for the listen address used by the Node Manager to listen
for connection requests. By default, the IP addresses defined for the local
system and localhost are shown in the list. The default value is localhost.
Node Manager listen port: Enter
a valid value for the listen port used by the Node Manager to listen for
connection requests. The valid Node Manager listen port range is from 1 through
65534. The default value is 5556.
Post bind GID enabled: This check box is displayed only
on 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 the privileged startup actions.
By default, this check box is not selected.
Post bind GID: This field is displayed only on the Unix Machine tab. Enter a valid UNIX group ID (GID)
that a server running on this machine will use after it finishes all the
privileged startup actions. Otherwise, the server continues to run under the
group from which it was started (requires you to enable a post bind GID).
Post bind UID enabled: This field is displayed only on
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 the privileged startup actions.
By default, this check box is not selected.
Post bind UID: This field is displayed only on 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 the
privileged startup actions. Otherwise, the server continues to run under the
account from which it was started (requires you to enable a post bind UID).
Assigning
Servers to Machines
The
screenshot shows assigning servers to machines. Machines are optional and
assigning servers is optional. It is possible to create a machine and then not
assign any servers to it, but there is no point in that.
No
databases are defined in the wls.jar
template. Therefore, the “Configure JDBC Data Sources” page would not normally
be displayed. For purposes of completeness, “Configure JDBC Data Sources” is
shown next.
Configuring
JDBC Data Sources
The
screenshot shows JDBC configuration. In this example, you create a new domain
based on the default template (wls.jar).
This default template does not contain any JDBC data source or JMS store
definitions. So, if you select the Oracle WebLogic Server template as the basis
for the domain, this “Configure JDBC Data Sources” page is not displayed.
To
see the screens pertaining to these options, you can run the Domain
Configuration Wizard and select the “Extend my domain using existing extension
template” option. If the template contains the existing JDBC data sources or
the JMS store (for example, use templates under the <WL_HOME>/common/templates/applications
directory), it will allow you to configure the JDBC data source, test the data
source connections, and configure the JMS file store.
After
step 12 (Assigning Servers to Machines), if the domain source on which you base
your domain contains the JDBC data source and JMS file store definitions, you
are presented with the option to modify them; otherwise, you are presented with
the option to review the domain settings and create the domain.
When
you create or extend a domain using the Configuration Wizard, you can change
the JDBC data source and JMS file store settings if they are defined in the
domain or template that you selected as the source for the domain that you are
creating.
Note: If you select Yes on the Customize Environment and
Services Settings page, the Configuration Wizard does not run any database
automatically, even though the domain JDBC is configured for whichever database
is specified in the data source. In the Run Database Scripts dialog box, click
the Run Scripts
button to load the respective database.
Note: If you select No on the Customize Environment and
Services Settings page, the Configuration Wizard automatically populates the
required database, whichever database is specified in the data source.
A
JDBC data source contains a pool of database connections that are created when
the data source instance is created—when the data source is deployed or
targeted, or at server startup. Applications look up a data source on the Java
Naming and Directory Interface (JNDI) tree, and then request a connection. When
the applications no longer need the connection, they return the connection to
the connection pool in the data source.
The
following are the fields on the Configure JDBC Data Sources page:
•Name: Enter a valid name for the JDBC data
source. The name of the JDBC data source must be unique among all the component
names within the domain.
•JNDI name: From the list, select the JNDI name to
which this data source is bound.
-To
add a new JNDI name, select Add New
and enter a valid JNDI path.
-To
change an existing JNDI name, select the name and edit it.
You
can associate multiple JNDI names with a single data source. When an
application looks up a JNDI path, a javax.sql.DataSource
instance corresponding to the data source is returned.
•Database type: From the list, select the type of
database to which you want to connect. If your DBMS is not listed, select Other.
•Driver: From the list, select the JDBC driver
that you want to use to connect to the database. The list includes common JDBC
drivers for the selected DBMS. If you selected Other
in the Database type
field, this field is not available.
•Class name: If you selected a DBMS in the Database type field, no action is required. If you
selected Other in
the Database type
field, enter the full package name of the class that implements the java.sql.Driver
interface for your DBMS.
•DBMS name: Enter the name of the database. If you
selected Other in
the Database type
field, this field is not available.
•DBMS host: Enter the name of the server machine
that hosts the database. If you selected Other
in the Database type
field, this field is not available.
•DBMS port: Enter the port to be used to connect to
the server. The default setting associated with the database selected is
displayed. If you selected Other in
the Database type
field, this field is not available.
•JDBC URL: If you selected a DBMS in the Database type field, no action is required. If the Driver name is set and a default URL exists, that
URL is displayed in this field. If you selected Other
in the Database type
field, enter the URL that should be used to create the connections in the
connection pool in the data source.
•User name: Enter the account login name that is
required for connecting to the database. If you selected Other in the Database
type field, this field is not available. This
value can be specified in the Additional Properties
field.
•User name: Enter the account login name that is
required for connecting to the database. If you selected Other in the Database
type field, this field is not available. You
can specify this value in the Additional Properties
field.
•User password: Enter a valid password for accessing the
database. Valid values consist of a string of alphanumeric characters. The
hyphen (-) and underscore ( _ )
characters are supported. This password overrides the password entered as part
of the JDBC properties. The value is encrypted.
•Known properties: If you selected a DBMS in the Database type field, no action is required. This field
displays the properties list that is passed to the JDBC driver for creating
physical database connections. If you selected Other
in the Database type
field, this field is blank and not available.
•Additional properties: Enter any additional properties to
be passed to the JDBC driver. If you specified Other
in the Database type field,
enter any properties to be passed to the JDBC driver, such as the property
needed to specify the user.
•Supports global transactions: If
you selected an XA driver in the Driver
field, Supports global transactions
and the Two-phase commit
protocols are selected automatically. You cannot change the protocol. If you
selected a non-XA driver in the Driver
field, you can, if required, select Supports
global transactions. Then you can select one of the
following protocols:
-Logging last resource: With this option, the transaction
branch in which the connection is used is processed as the last resource in the
transaction and is processed as a one-phase commit operation. The result of the
operation is written in a log file on the resource itself, and the result
determines the success or failure of the prepare phase of the transaction. This
option offers some performance benefits with greater data safety than Emulate
Two-Phase Commit, but it has some limitations.
-Emulate two-phase commit: With
this option, the transaction branch in which the connection is used always
returns success for the prepare phase of the transaction. It offers performance
benefits, but also exposes data to risks in some failure conditions. Select
this option only if your application can tolerate heuristic conditions.
-One-phase commit (default):
With this option, a connection from the data source can be the only participant
in the global transaction and the transaction is completed by using a one-phase
commit optimization. If multiple resources participate in the transaction, an
exception is thrown.