Celdas no adyacentes o rangos de celdas

A WebLogic Server cluster is a group of servers in a domain that work together to provide a more scalable, more reliable application platform than a single server. A cluster appears to its clients as a single server but is in fact a group of servers acting as one.

4.1.1 Advantages of JMS Clustering

The advantages of clustering for JMS include the following:

■ Load balancing of destinations across multiple servers in a cluster

An administrator can establish load balancing of destinations across multiple servers in the cluster by:

– Configuring multiple JMS servers and targeting them to the configured WebLogic Servers.

Note: JMS clients depend on unique WebLogic Server names to successfully access a cluster—even when WebLogic Servers reside in different domains. Therefore, make sure that all WebLogic Servers that JMS clients contact have unique server names.

Configuring WebLogic JMS Clustering

– Configuring multiple JMS servers and targeting them to a set of migratable targets.

– Configuring a JMS Server and targeting a WebLogic cluster. See Section 5, "Simplified JMS Cluster Configuration."

Each JMS server is deployed on exactly one WebLogic Server instance and handles requests for a set of destinations.

■ High availability of destinations

– Distributed destinations — The queue and topic members of a distributed destination are usually distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use distributed destinations are more highly available than applications that use simple destinations because WebLogic JMS provides load balancing and failover for member destinations of a distributed destination within a cluster. For more information on distributed destinations, see Section 4.5,

"Configuring Distributed Destination Resources."

– Store-and-Forward — JMS modules utilize the SAF service to enable local JMS message producers to reliably send messages to remote queues or topics. 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 destination once it becomes available. For more information, see "Understanding the

Store-and-Forward Service" in Administering the Store-and-Forward Service for Oracle WebLogic Server.

– For automatic failover, WebLogic Server supports migration at the server level—a complete server instance, and all of the services it hosts can be migrated to another machine, either automatically, or manually. For more information, see "Whole Server Migration" in Administering Clusters for Oracle WebLogic Server.

■ Cluster-wide, transparent access to destinations from any server in a cluster

An administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by either using the default connection factories for each server instance in the cluster, or by configuring one or more connection factories and targeting them to one or more server instances in the cluster, or to the entire cluster. This way, each connection factory can be deployed on multiple WebLogic Server instances. Connection factories are described in more detail in

Section 3.6, "Connection Factory Configuration."

■ Scalability

– Load balancing of destinations across multiple servers in the cluster, as described previously.

– Distribution of application load across multiple JMS servers through connection factories, thus reducing the load on any single JMS server and enabling session concentration by routing connections to specific servers. – Optional multicast support, reducing the number of messages required to be

delivered by a JMS server. The JMS server forwards only a single copy of a message to each host group associated with a multicast IP address, regardless of the number of applications that have subscribed.

Configuring WebLogic JMS Clustering

WebLogic Server supports migration at the server level—a complete server instance, and all of the services it hosts can be migrated to another machine, either automatically, or manually. For more information, see "Whole Server Migration" in Administering Clusters for Oracle WebLogic Server.

Also, as an "exactly-once" service, WebLogic JMS takes advantage of the service migration framework implemented in WebLogic Server for clustered

environments. This allows WebLogic JMS to respond properly to migration requests and to bring a JMS server online and offline in an orderly fashion. This includes both scheduled manual migrations as well as automatic migrations in response to a WebLogic Server failure. For more information, see Section 4.2, "Migration of JMS-related Services."

■ Server affinity for JMS Clients

When configured for the cluster, load balancing algorithms (round-robin-affinity, weight-based-affinity, or random-affinity), provide server affinity for JMS client connections. If a JMS application has a connection to a given server instance, JMS attempts to establish new JMS connections to the same server instance. For more information on server affinity, see "Load Balancing in a Cluster" in Administering Clusters for Oracle WebLogic Server.

For more information about the features and benefits of using WebLogic clusters, see "Understanding WebLogic Server Clustering" in Administering Clusters for Oracle WebLogic Server.

4.1.2 How JMS Clustering Works

An administrator can establish cluster-wide, transparent access to JMS destinations from any server in a cluster, either by using the default connection factories for each server instance in a cluster, or by configuring one or more connection factories and targeting them to one or more server instances in a cluster, or to an entire cluster. This way, each connection factory can be deployed on multiple WebLogic Servers. For information on configuring and deploying connection factories, see Section 3.6.2, "Connection Factory Configuration Parameters."

The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. If requests for destinations are sent to a WebLogic Server instance that is hosting a connection factory, but which is not hosting a JMS server or destinations, the requests are forwarded by the connection factory to the appropriate WebLogic Server instance that is hosting the JMS server and destinations.

The administrator can also configure multiple JMS servers on the various servers in the cluster—as long as the JMS servers are uniquely named—and can then target JMS queue or topic resources to the various JMS servers. Alternatively, an administrator can target a JMS server at a cluster, and the cluster automatically creates an instance of a JMS server on each server. The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate WebLogic Server instance. For information on configuring and deploying JMS servers, see Section 3.4, "JMS Server Configuration."

4.1.2.1 JMS Clustering Naming Requirements

There are naming requirements when configuring JMS objects and resources, such as JMS servers, JMS modules, and JMS resources, to work in a clustered environment in a

Configuring WebLogic JMS Clustering

single WebLogic domain or in a multi-domain environment. For more information, see

Section 3.3, "JMS Configuration Naming Requirements."

4.1.2.2 Distributed Destination Within a Cluster

A distributed destination resource is a single set of destinations (queues or topics) that are accessible as a single, logical destination to a client (for example, a distributed topic has its own JNDI name). The members of the unit are usually distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use distributed destinations are more highly available than applications that use simple destinations because WebLogic Server provides load balancing and failover for member destinations of a distributed destination within a cluster. For more information, see Section 4.5, "Configuring Distributed Destination Resources."

4.1.2.3 JMS Services As a Migratable Service Within a Cluster

In addition to being part of a whole server migration, where all services hosted by a server can be migrated to another machine, JMS services are also part of the singleton service migration framework. This allows an administrator, for example, to migrate a JMS server and all of its destinations to migrate to another WebLogic Server within a cluster in response to a server failure or for scheduled maintenance. This includes both scheduled migrations as well as automatic migrations. For more information on JMS service migration, see Section 4.2, "Migration of JMS-related Services."

4.1.3 Configuration Guidelines for JMS Clustering

In order to use WebLogic JMS in a clustered environment, follow these guidelines:

1. Configure your clustered environment as described in "Setting Up WebLogic Clusters" in Administering Clusters for Oracle WebLogic Server.

2. Identify targets for any user-defined JMS connection factories using the WebLogic