In Part 1 of this article series we discussed the fundamental aspects of clustering JMS resources in a WebLogic cluster. In Part 2 we will discuss JMS clustering in the context of design and configuration strategies that demonstrate how to create efficient JMS architectures.

Clustering Concepts
Enterprise applications come is a variety of sizes. For small-scale deployments, a J2EE application might be deployed on a single WebLogic server. Such a configuration, for example, would call for little consideration to the location of JMS and JDBC resources since clients that need to access those resources would, in most cases, reside on the same physical server. In contrast, mid- or large-scale J2EE deployments are most likely clustered across many physical servers to provide the application with high availability and load balancing capabilities. A clustered application, however, is more complex and network-demanding. Server instances in a cluster provide services to other server instances, sometimes across remote connections. It is important to consider the location of clients in an application cluster with respect to the resources they need to access. In some cases you may prefer to minimize remote connections by placing clients and resources on the same physical server; this is known as collocation. In other cases, however, you may want to distribute the work load among the physical servers in a cluster to utilize all available processing power; this is known as distributed load balancing.

The concept of collocation is important to consider in any clustered application. The idea behind collocation is simple: target your application server resources, such as JMS and JDBC, to physical server instances where clients are located and need access to those resources. For example, a JMS message producer first must find a connection factory, and then establish a connection to a JMS server for accessing a specific destination. If the JMS client uses a connection factory located on a remote server instance, a remote connection will be created. Additionally, if the connection factory and JMS server hosting the destination are located on separate physical servers, a remote JMS connection is created. While there is nothing preventing the JMS client from using remote connection factories and JMS resources, a more efficient approach is to collocate the JMS client with the connection factory and JMS resources it needs, thereby avoiding the use of remote connections and reducing network traffic.

With distributed load balancing, WebLogic allocates the work load to all server instances in the cluster to provide uniform use of available resources.

In a JMS cluster configuration, for example, messages sent to a distributed queue are load balanced among the destination members hosted by JMS servers on separate server instances. This approach helps to ensure accurate contribution of processing capacity from all physical servers in the cluster based on the preconfigured load balancing scheme for the distributed destination.

Collocation and distributed load balancing in the context of JMS are key concepts in this article. The next series of architectures illustrate different configurations and how they affect the behavior of clustered JMS applications.

Internal JMS Clients
Figure 1 illustrates a typical WebLogic cluster with distributed JMS resources. The cluster consists of three physical server instances. The WebLogic server instances each hosts its own JMS server with persistent file store (FS1, FS2, and FS3). A distributed queue (DQ) consists of two physical queue members, MQ1 and MQ2, which are deployed to WebLogic server instances 1 and 3, respectively. A connection factory (CF1) is targeted to the cluster making it available to each WebLogic server instance as a local JNDI object. The JMS clients, including message producers MP1, MP2, and message-driven beans MDB1, MDB2, reside on the WebLogic instances that host their desired destination, DQ.

Let's first look at the location of the connection factory, CF1. By targeting CF1 to the cluster, WebLogic first attempts to load balance consumers and producers on the same physical server instance. As depicted on WebLogic Servers 1 and 3, the JMS clients first connect locally to CF1. The connection factory then creates a JMS connection to the local JMS server on that WebLogic instance, connecting the clients with a local member destination of DQ. In this case, local JMS connections are created for the JMS clients.

It should be clear from Figure 1 that all JMS clients, including the connection factories, JMS servers, and distributed destination members, are collocated. This is ideal for WebLogic as it avoids the cost of load balancing across the remote member destinations of DQ while routing messages to collocated destinations instead.

To ensure WebLogic will first load balance locally, enable Server Affinity from the WebLogic Administration console for any connection factory collocated with JMS resources. In Figure 1, we enabled this option on CF1, and then targeted the connection factory to the entire cluster. Note that connection factories are clients to JMS servers, so it is good practice to collocate these types of administered objects as well, not just JMS producers and consumers.

WebLogic Server 2 does not host any queue members for DQ, so we don't target JMS clients to that server instance to avoid routing messages to remote destinations members. This architecture is suitable for systems that prefer increased performance at the cost of some distributed load balancing. This expense is attributed to the preference of local resources over remote resources. Even the persistent stores configured for the JMS servers use a local file resource. The file stores may be configured for superior performance by setting the Synchronous Write Policy to Disabled (configurable from the Administration console for each file store), which completes transactions once they are stored in memory. In terms of reliability, however, this is the least desirable policy, and is not recommended for applications that cannot afford to lose messages. The default policy Cache-Flush, which forces all writes to disk before transactions are complete, is a good trade-off between performance and transactional reliability.

External JMS Clients
The WebLogic cluster depicted in Figure 2 is similar to Figure 1, except here the message producers MP1, MP2, and MP3 are external JMS clients. These types of clients may represent batch processes executed throughout the day to perform specific message-based tasks. The connection factory CF1 is targeted to the cluster with Server Affinity enabled. The message-driven beans MDB1 and MDB2 connect with the collocated CF1 on their respective WebLogic server instances to access DQ without the need for remote JMS connections, just as in Figure 1.

The external JMS clients may also use CF1 to access DQ, but this may cause unnecessary remote connections and remote routing of message traffic. As depicted in the illustration, MP2 connects to CF1 on WebLogic Server 2. The connection factory must now connect MP2 with a physical queue member of DQ. Connection factory CF1 is enabled with Server Affinity, so it first attempts to connect MP2 with a local member destination of DQ. Since JMSServer2 does not host a collocated queue member, CF1 is forced to create a remote JMS connection to MQ1 on WebLogic Server 1, which effectively routes all message traffic from MP2 across that remote connection. This can create an undesirable network-intensive process if MP2 is generating hundreds, if not thousands, of messages per day, such as in a financial trading application that publishes stock prices nonstop to trader desks throughout the daily trading session.