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.

JDBC DataSource

●

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 Architecture

●

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. Not all changes take effect immediately—some require a restart

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 page, select a message provider from the drop-down box.


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. Not all changes take effect immediately—some require a restart

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. Not all changes take effect immediately—some require a restart

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

by using the NetworkAccessPointMBean.

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

Technology