Weblogic Cluster configuration

Configuring in Weblogic Server

Configuration
● JDBC
● JMS
● Messaging Bridge
● WLDF
● Weblogic Store-and-Forward
● Log
● Weblogic Server Environment

JDBC Resources
● Each data source that you configure contains a pool of database connections
that are created when the data source instance is created—when it is
deployed or targeted, or at server startup. Applications lookup a data source
on the JNDI tree or in the local application context (java:comp/env),
depending on how you configure and deploy the object, and then request a
database connection. When finished with the connection, the application
calls connection.close(), which returns the connection to the
connection pool in the data source.
● A multi data source is an abstraction around a selected list of data sources
that provides load balancing or failover processing between the data sources
associated with the multi data source. Multi data sources are bound to the
JNDI tree or local application context just like data sources are bound to the
JNDI tree. Applications lookup a multi data source on the JNDI tree or in the
local application context (java:comp/env) just like they do for data
sources, and then request a database connection. The multi data source
determines which data source to use to satisfy the request depending on the
algorithm selected in the multi data source configuration: load balancing or
failover.

Ownership of JDBC Resources
A key to understanding WebLogic JDBC data source configuration and
management is that who creates a JDBC resource or how a JDBC resource is
created determines how a resource is deployed and modified. Both WebLogic
Administrators and programmers can create JDBC resources:
• WebLogic Administrators typically use the Administration Console or the
WebLogic Scripting Tool (WLST) to create and deploy (target) JDBC modules.
These JDBC modules are considered system modules.
• Programmers create modules in a development tool that supports creating an
XML descriptor file, then package the JDBC modules with an application and
pass the application to a WebLogic Administrator to deploy. These JDBC
modules are considered application modules.

JDBC DataSource
Understanding JDBC Data Sources
In WebLogic Server, you configure database connectivity by adding data sources to your
WebLogic domain. WebLogic JDBC data sources provide database access and database
connection management. Each data source contains a pool of database connections that are created
when the data source is created and at server startup. Applications reserve a database connection
from the data source by looking up the data source on the JNDI tree or in the local application
context and then calling getConnection(). When finished with the connection, the
application should call connection.close() as early as possible, which returns the database
connection to the pool for other applications to use.
Types of WebLogic Server JDBC Data Sources
• Generic Data Sources—Generic data sources and their connection pools provide connection
management processes that help keep your system running efficiently.You can set options in the
data source to suit your applications and your environment.
· GridLink Data Sources—An event-based data source that adaptively responds to state
changes in an Oracle RAC instance.
· Multi data sources— A multi data source is an abstraction around a group of generic data
sources that provides load balancing or failover processing.

Creating a DataSource
● If you have not already done so, in the Change Center of the Administration
Console, click Lock & Edit
● In the Domain Structure tree, expand Services, then select Data Sources.
On the Summary of Data Sources page, click New and select Generic
Data Source. On the JDBC Data Sources Properties page, enter or select
the following information:
● Name - Enter a name for this JDBC data source. This name is used in the
configuration file (config.xml) and throughout the Administration
Console whenever referring to this data source.
● JNDI Name - Enter the JNDI path to where this JDBC data source will be
bound. Applications look up the data source on the JNDI tree by this name
when reserving a connection.
● Database Type - Select the DBMS of the database that you want to connect
to. If your DBMS is not listed, select Other.
● Click Next to continue.

Select the database driver:
Database Driver - Select the JDBC driver you want to use to connect to the database. The list
includes common JDBC drivers for the selected DBMS.
Note: You must install JDBC drivers before you can use them to create database connections.
Some JDBC drivers are installed with WebLogic Server, but many are not installed.

On the Transaction Options page, follow these steps. Depending on the driver you selected on
the JDBC Data Source Properties page, you may not need to specify any of these options.
Supports Global Transactions - Select this check box (the default) to enable global transaction
support in this data source. Clear this check box to disable (ignore) global transactions in this data
source. In most cases, you should leave the option selected.
If you selected Supports Global Transactions, select an option for transaction processing:
(available options vary depending on whether you select an XA driver or a non-XA driver)
• Two-Phase Commit - Select this option to enable standard XA processing.
This option is only available when you select an XA JDBC driver to make database connections.
• Logging Last Resource - Select this option to enable a non-XA JDBC connection to
participate in global transactions using the Logging Last Resource (LLR) transaction optimization.
Recommended in place of Emulate Two-Phase Commit.
This option is only available when you select a non-XA JDBC driver to make database
connections.
• Emulate Two-Phase Commit - Enables a non-XA JDBC connection to emulate
participation in distributed transactions using JTA. Select this option only if your application can
tolerate heuristic conditions.

On the Connection Properties page, enter values for the following properties:
Service Name - This field is available only if you selected one of the available Oracle
RAC Service-Instance connections drivers. Specify the service name of the database to
which you want to connect. This must be the same for each data source in a given multi
data source.
Database Name - Enter the name of the database that you want to connect to. Exact
database name requirements vary by JDBC driver and by DBMS.
Host Name - Enter the DNS name or IP address of the server that hosts the database. If
you are creating an Oracle GridLink service-instance connection, this must be the same
for each data source in a given multi data source.
Port - Enter the port on which the database server listens for connections requests.
Database User Name - Enter the database user account name that you want to use for
each connection in the data source.
Password/Confirm Password - Enter the password for the database user account.
Click Next to continue.

● On the Test Database Connection page, review the connection parameters and click
Test Configuration.
● WebLogic attempts to create a connection from the Administration Server to the
database. Results from the connection test are displayed at the top of the page. If the
test is unsuccessful, you should correct any configuration errors and retry the test.
● If the JDBC driver you selected is not installed on the Administration Server, you
should click Next to skip this step.
● Click Next to continue.
● On the Select Targets page, select the servers or clusters on which you want to
deploy the data source. Click Finish to save the JDBC data source configuration and
deploy the data source to the targets that you selected. To activate these changes, in
the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart

JMS Service
An enterprise messaging system enables applications to asynchronously communicate
with one another through the exchange of messages. A message is a request, report,
and/or event that contains information needed to coordinate communication between
different applications. A message provides a level of abstraction, allowing you to
separate the details about the destination system from the application code.
The Java Message Service (JMS) is a standard API for accessing enterprise messaging
systems that is implemented by industry messaging providers. Specifically, JMS:
• Enables Java applications that share a messaging system to exchange messages
• Simplifies application development by providing a standard interface for creating,
sending, and receiving messages
WebLogic JMS accepts messages from producer applications and delivers them to
consumer applications.

JMS Configurable Resources
● Destination
● Connection Factory

Steps for Configuring JMS Resource
If you require persistent messaging, use one of the following storage options:
• To store persistent messages in a file-based store, you can simply use the server's
default persistent store, which requires no configuration on your part. However, you can
also create a dedicated file store for JMS.
• To store persistent messages in a JDBC-accessible database, you must create a
JDBC store.
● Configure a JMS server to manage the messages that arrive on the queue and topic
destinations in a JMS system module.
● Configure a JMS system module to contain your destinations, as well as other
resources, such as quotas, templates, destination keys, distributed destinations, and
connection factories.

Before creating any queues or topics in your system module, you can optionally create
other JMS resources in the module that can be referenced from within a queue or topic,
such as JMS templates, quota settings, and destination sort keys:
• Define quota resources for your destinations. Destinations can be assigned their
own quotas; multiple destinations can share a quota; or destinations can share the JMS
server's quota.
• Create JMS templates, which allow you to define multiple destinations with similar
option settings. See
• Configure destination keys to create custom sort orders of messages as they arrive
on a destination.
Once these resources are configured, you can select them when you configure your
queue or topic resources.

Configure a queue and/or topic destination in your system module:
• Configure a standalone topic for the delivery of messages to multiple recipients
(publish/subscribe).
• Configure a standalone queue for the delivery of messages to exactly one recipient
(point-to-point).
If the default connection factories provided by WebLogic Server are not suitable for
your application, create a connection factory to enable your JMS clients to create JMS
connections.

Store-and-Forward(SAF) Service
The SAF service enables WebLogic Server to deliver messages reliably between
applications that are distributed across WebLogic Server instances. For example, with
the SAF service, an application that runs on or connects to a local WebLogic Server
instance can reliably send messages to an endpoint that resides on a remote server. If the
destination is not available at the moment the messages are sent, either because of
network problems or system failures, then the messages are saved on a local server
instance, and are forwarded to the remote endpoint once it becomes available.
WebLogic JMS utilizes the SAF service to enable local JMS message producers to
reliably send messages to remote JMS queues or topics
WebLogic Web Services relies on the SAF service to support the reliability of Web
Services Reliable Messaging (WSRM)

SAF Service Agents
There are two sides involved in the process of storing and forwarding messages: a local
sending side and a remote receiving endpoint. SAF agents are responsible for store-and-
forwarding messages between these local sending and remote receiving endpoints. A
SAF agent can be configured to have only sending capabilities, receiving capabilities, or
both.
JMS SAF only requires a sending agent on the sending side for JMS messages.
Whereas, WSRM SAF requires both a sending agent and a receiving agent.
• Sending agent — Used for JMS messages and WSRM. If message persistence is
required, a sending agent stores messages to a persistent storage, forwards messages to
the receiving side, and re-transmits messages when acknowledgements do not come
back in time.
• Receiving agent — Used only for WSRM. Receiving agents detect and eliminate
duplicate messages sent by a sending agent, and delivers messages to the final
destination.

Steps to Create SAF Agent
If you have not already done so, in the Change Center of the Administration Console,
click Lock & Edit.
In the left panel of the console, expand Services > Messaging and select Store-and-
Forward Agents. On the Summary of Store-and-Forward Agents page, click New.
Note: Once you create a SAF agent, you cannot rename it. Instead, you must delete it
and create another one that uses the new name.

On the Create a New Store-and-Forward Agent page:
Name -- Name for the SAF agent.
Persistent Store -- Select a custom persistent store if you want a dedicated store for SAF messages or click
Create a New Store to configure a new custom store. If you leave this field set to none, then the SAF agent
will use the default file store that is automatically configured on each targeted server instance.
Note: When a SAF agent is targeted to a migratable target, it cannot use the default store. Therefore, a custom
store must be configured and targeted to the same migratable target.
Agent Type -- Select one of the following:
• Sending-only -- Configures an agent that stores messages in persistent storage, forwards messages to the
receiving side, and re-transmits messages when acknowledgements do not come back in time.
• Receiving-only -- Configures an agent that detects and eliminates duplicate messages sent by a receiving
agent, and delivers messages to the final destination.
• Both -- Configures an agent that has sending and receiving agent functionality.
Note: JMS SAF users should select Sending-only since JMS SAF doesn't require a configured receiving agent.
Click Next.

On the Selects Targets page, select the server instance, cluster, or migratable target
where you want to deploy the SAF agent. A migratable target is a logical target that
serves as a grouping of services, such as a SAF agent, and which is active on only server
member in a cluster. High availability is achieved by migrating a migratable target from
one server member to another when a problem occurs on the original server.
Note: A recommended best practice is to target the SAF agent to a migratable target, so
that a member server will not be a single point of failure. However, if a SAF agent is
targeted to a migratable target, it cannot be targeted to any other server targets, including
an entire cluster.
Click Finish. To activate these changes, in the Change Center of the Administration
Console, click Activate Changes.

Messaging Bridge
The WebLogic Messaging Bridge is a forwarding mechanism that provides
interoperability between WebLogic JMS implementations, and between JMS and other
messaging products. Use the Messaging Bridge to integrate your messaging applications
between:
• Any two implementations of WebLogic JMS, including those from separate releases
of WebLogic Server.
• WebLogic JMS implementations that reside in separate WebLogic domains.
• WebLogic JMS and a third-party JMS product (for example, MQSeries).
A messaging bridge instance forwards messages between a pair of bridge source and
target destinations. These destinations are mapped to a pair of bridge source and target
destinations. The messaging bridge reads messages from the source bridge destination
and forwards those messages to the target bridge destination. For WebLogic JMS and
third-party JMS products, a messaging bridge communicates with source and target
destinations using the Java EE Connector Architecture (JCA) resource adapters provided
with WebLogic Server.

Messaging Bridge Architecture
●

Creating Message Bridge
Create source and target bridge destinations.
Deploy a resource adapter.
Create a messaging bridge instance.
Target the messaging bridge.

Steps in creating Message Bridge
If you have not already done so, in the Change Center of the Administration Console,
click Lock & Edit .
In the left pane of the console, expand Services > Messaging and select Bridges to open
the Summary of Messaging Bridges page.
Click New.
On the Create a New Bridge: Bridge Properties page, define the properties that will
identify your new messaging bridge instance.
Note: Once you create a messaging bridge instance, you cannot rename it. Instead, you
must delete it and create another one that uses the new name.
Click Next.

On the Create a New Bridge: Select or Create a Source Bridge Destination page, select a
source destination from the drop-down box.
If the drop-down box is empty or does not contain the source destination you need, click
New Destination, create a source destination, and then select the source destination
from the drop-down box.
Click Next.
On the Create a New Bridge: Select the Messaging Provider for the Source Destination
page, select a message provider from the drop-down box.
Click Next. On the Create a New Bridge: Select or Create a Target Bridge Destination
page, select a target destination from the drop-down box.
If the drop-down box is empty or does not contain the target destination you need, click
New Destination, create a target destination, and then select the target destination from
the drop-down box.
Click Next.
On the Create a New Bridge: Select the Messaging Provider for the Target Destination

On the Create a New Bridge: Targeting this Messaging Bridge page, select a target for
your messaging bridge instance.
Click Next. Review any additional interoperability guidelines.
Click Finish.
To activate these changes, in the Change Center of the Administration Console, click
Activate Changes.

Weblogic Logging Service
● WebLogic logging services provide facilities for writing, viewing, filtering, and
listening for log messages. These log messages are generated by WebLogic Server
instances, subsystems, and Java EE applications that run on WebLogic Server or in
client JVMs.
● WebLogic Server subsystems use logging services to provide information about
events such as the deployment of new applications or the failure of one or more
subsystems. A server instance uses them to communicate its status and respond to
specific events. For example, you can use WebLogic logging services to report error
conditions or listen for log messages from a specific subsystem.
● Each WebLogic Server instance maintains a server log. Because each WebLogic
Server domain can run concurrent, multiple instances of WebLogic Server, the
logging services collect messages that are generated on multiple server instances
into a single, domain-wide message log. The domain log provides the overall status
of the domain.

Weblogic Logging Architecture
●

Steps in Configuring Logger
●
If you have not already done so, in the Change Center of the Administration
Console, click Lock & Edit (see Use the Change Center). To view logs:
In the left pane of the Console, expand Diagnostics and select Log Files.
In the Log Files table, select the radio button next to the name of the log you
want to view.
Click View.
The page displays the latest contents of the log file; up to 500 messages in
reverse chronological order. The messages at the top of the window are the
most recent messages that the server has generated.
The log viewer does not display messages that have been rotated into
archive log files. For more information, see Rotate log files.
Select the radio button next to the log record you want to view.
Click View.
The page displays the log file entry.

Steps in Configuring Logger
● To configure logs:
In the left pane of the Console, expand Environment and select Servers.
In the Servers table, click the name of the server instance whose logging
you want to configure.
Select Logging > General.
Retain or modify the default values.
Click Save. To activate these changes, in the Change Center of the
Administration Console, click Activate Changes.

Weblogic Server Configuration
● Work Manager
● Network Resources
● Web Server Functionality
● Weblogic Persistent Store

Weblogic Server Work Manager
WebLogic Server prioritizes work and allocates threads based on an execution model
that takes into account administrator-defined parameters and actual run-time
performance and throughput.
Administrators can configure a set of scheduling guidelines and associate them with one
or more applications, or with particular application components. For example, you can
associate one set of scheduling guidelines for one application, and another set of
guidelines for other applications. At run time, WebLogic Server uses these guidelines to
assign pending work and enqueued requests to execution threads.
To manage work in your applications, you define one or more of the following Work
Manager components:
• Fair Share Request Class
• Response Time Request Class
• Min Threads Constraint
• Max Threads Constraint
• Capacity Constraint

Work Manager Configuration Files
● config.xml—Work Managers specified in config.xml can be assigned to any
application, or application component, in the domain.
● weblogic-application.xml—Work Managers specified at the application
level can be assigned to that application, or any component of that application.
● weblogic-ejb-jar.xml or weblogic.xml—Work Managers specified at
the component level can be assigned to that component.
● weblogic.xml—Work Managers specified for a Web application.

Overview of Network Configuration
For many development environments, configuring WebLogic Server network resources is simply
a matter of identifying a Managed Server listen address and listen port. However, in most
production environments, administrators must balance finite network resources against the
demands placed upon the network. The task of keeping applications available and responsive can
be complicated by specific application requirements, security considerations, and maintenance
tasks, both planned and unplanned.
WebLogic Server lets you control the network traffic associated with your applications in a
variety of ways, and configure your environment to meet the varied requirements of your
applications and end users. You can:
• Designate the Network Interface Cards (NICs) and ports used by Managed Servers for
different types of network traffic.
• Support multiple protocols and security requirements.
• Specify connection and message time-out periods.
• Impose message size limits.
You specify these and other connection characteristics by defining a network channel—the
primary configurable WebLogic Server resource for managing network connections. You
configure a network channel in the Administration Console (Servers > Protocols > Channels) or

Understanding Network Channels
A network channel is a configurable resource that defines the attributes of a
network connection to WebLogic Server. For instance, a network channel can
define:
• The protocol the connection supports.
• The listen address.
• The listen ports for secure and non-secure communication.
• Connection properties such as the login time-out value and maximum
message sizes.
• Whether or not the connection supports tunneling.
• Whether the connection can be used to communicate with other WebLogic
Server instances in the domain, or used only for communication with clients.

Configuring Channels
● Channels and Server Instances
• Each channel you configure for a particular server instance must have a unique
combination of listen address, listen port, and protocol.
• A channel can be assigned to a single server instance.
• You can assign multiple channels to a server instance.
• If you assign non-SSL and SSL channels to the same server instance, make sure that
they do not use the same combination of address and port number.
● Dynamic Channel Configuration
• In WebLogic Server, you can configure a network channel without restarting the
server. Additionally, you can start and stop dynamically configured channels while the
server is running. However, when you shutdown a channel while the server is running,
the server does not attempt to gracefully terminate any work in progress.

Configuring Channels
● Channels and Protocols
• Some protocols do not support particular features of channels. In particular the
COM protocol does not support SSL or tunneling.
• You must define a separate channel for each protocol you wish the server instance
to support, with the exception of HTTP.
HTTP is enabled by default when you create a channel, because RMI protocols typically
require HTTP support for downloading stubs and classes. You can disable HTTP
support on the Advanced Options portion of the Servers > Protocols > Channels page in
the Administration Console.
Reserved Names
• WebLogic Server uses the internal channel names .WLDefaultChannel and
.WLDefaultAdminChannel and reserves the .WL prefix for channel names. Do not
begin the name of a custom channel with the string .WL.

Weblogic Web Server
In addition to hosting dynamic Java-based distributed applications,
WebLogic Server functions as a Web server that handles high-volume
Web sites, serving static files such as HTML files and image files, as well
as servlets and JavaServer Pages (JSP). WebLogic Server supports the
HTTP 1.1 standard.

Configuring Server
● You can specify the port that each WebLogic Server listens on for HTTP requests.
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 form
http://hostname/myfile.html instead of
http://hostname:portnumber/myfile.html.
● On UNIX systems, binding a process to a port lower than 1025 must be done from
the account of a privileged user, usually root. Consequently, if you want WebLogic
Server to listen on port 80, you must start WebLogic Server as a privileged user; yet
it is undesirable from a security standpoint to allow long-running processes like
WebLogic Server to run with more privileges than necessary. WebLogic Server
needs root privileges only until the port is bound.

Configuring Server
● By setting the weblogic.system.enableSetUID property (and, if desired,
the weblogic.system.enableSetGID property) to true, you enable an
internal process by which WebLogic Server switches its UNIX user ID (UID) after
it binds to port 80. The companion properties,
weblogic.system.nonPrivUser and
weblogic.system.nonPrivGroup, identify a non-privileged UNIX user
account (and optionally a groupname) under which WebLogic Server will run after
startup.
● You can switch to the UNIX account "nobody," which is the least privileged user on
most UNIX systems. If desired, you may create a UNIX user account expressly for
running WebLogic Server. Make sure that files needed by WebLogic Server, such
as log files and the WebLogic classes, are accessible by the non-privileged user.
Once ownership of the WebLogic process has switched to the non-privileged user,
WebLogic will have the same read, write, and execute permissions as the non-
privileged user.

Configuring the Listen Port
● Use the Administration Console to set the listen port to port 80.
● If the machine hosting WebLogic Server is running Windows, skip to step 8.
● Use the Administration Console to create a new Unix Machine.
● Select the Enable Post-Bind UID field.
● Enter the user name you want WebLogic Server to run as in the Post-Bind UID
field.
● Select the Enable Post-Bind GID fields.
● Enter the group name you want WebLogic Server to run as in the Post-Bind
GID field.
● Click Save.
● To activate these changes, in the Change Center of the Administration Console,
click Activate Changes.

Weblogic Persistent Store
The persistent store provides a built-in, high-performance storage solution for
WebLogic Server subsystems and services that require persistence.
For example, it can store persistent JMS messages or temporarily store messages
sent using the Store-and-Forward feature.
The persistent store supports persistence to a file-based store or to a JDBC-
enabled database.

Steps to Configure Persistent Store
In the left pane of the console, expand Services and select Persistent
Stores. On the Summary of Persistent Stores page, click New. Select the
store type from the drop-down box:
• ··Create file stores
• ··Create JDBC stores

Weblogic Cluster configuration

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Weblogic Cluster configuration

Similaire à Weblogic Cluster configuration (20)

Plus de Aditya Bhuyan

Plus de Aditya Bhuyan (20)

Dernier

Dernier (20)

Weblogic Cluster configuration