JMS Binding Component Clustering

Mission-critical enterprise systems need to be fast, reliable, and scalable. In a world of JMS systems that require near-zero downtime, the messaging architecture must support the clustering of JMS resources such as queues and topics, while accounting for the load-balancing of distributed JMS message traffic.

The JBI Runtime Environment supports clusters of JMS Binding Components and JMS brokers. The clustering of JMS binding components requires deploying one instance of a JMS binding component to each JBI runtime in a clustered JBI Runtime Environment. The availability and method of configuring a cluster of JMS brokers depends on the JMS provider. The Enterprise Edition of Sun Java System Message Queue supports clustering of JMS brokers.

Clustering is supported for queues only. Clustering is not supported for topics.

Clustering and the JMS Binding Component is described in the following categories:

• JMS High Availability

• JMS Load Balancing

• JMS Performance

JMS High Availability

High availability (or failover) clusters are designed to improve availability of services by removing any single points of failure. Nodes in the cluster also provide failover and redundancy capabilities. If one node in a cluster fails, then another node ensures that there is no loss of availability of the service. A logical front-end is responsible for configuring two or more nodes to act as redundant services.

To achieve high availability of JMS services, the JMS Binding Component is available in every instance of JBI runtime. Each instance of JBI runtime is also associated with one application server running in a clustered environment. The deployment of a service assembly is replicated to each JMS Binding Component instance. As a result, multiple consumers or producers are created on connections established by the JMS Binding Component instances to the same JMS broker. The JMS broker can be a standalone broker or a broker in a high-performance cluster of brokers.

Because JMS Binding Component instances are replicated, a crash to one instance does not result in a loss of service. The JMS message acknowledgement protocol guarantees at least once delivery of messages (no loss of messages). In conjunction with XA, exactly once semantics can be achieved. A crash to the JMS Binding Component during message delivery results in the JMS broker detecting a connection loss (lacking of message acknowledgement) and redelivering the message to the next available JMS Binding Component receiving from the same queue. With XA, a crash that leaves behind any in-doubt transactions can be recovered when the JMS Binding Component performs XA recovery in coordination with the JBI runtime and the transaction manager. Therefore, the combination of JMS acknowledgement protocol and XA protocol can support failover and recovery.

JMS Load Balancing

Load balancing clusters are designed to distribute the workload across multiple nodes in the cluster. The clusters accomplish this by having one logical front-end to the cluster that distributes any requests for work to any node in the cluster. The main purpose of this type of cluster is to provide improved performance, although they often include some high-availability features.

JMS supports load balancing by allowing multiple receivers on a queue. Replication of deployed service assemblies results in multiple JMS Binding Component instances receiving from the same queue. Messages are delivered in a point-to-point fashion, with only one receiver getting one message at a time. The JMS broker balances the load by delivering messages from the queue to any available receivers on that queue. The algorithm used for load balancing depends on the JMS provider.

Load balancing is only valid if queues are used, not topics.

JMS Performance

High-performance clusters are a special type of load balancing cluster. A logical front-end to the cluster partitions the work into tiny chunks and distribute each chunk to nodes in the cluster. When the work is done, the logical front-end reassembles the result and then returns the completed result to the client of the cluster.

Replication of a JMS Binding Component results in multiple receivers on a queue in a clustered or nonclustered broker setup. Load is distributed across the JBI instances as a result of having multiple receivers on one or more queues.

To achieve even higher performance, the JMS brokers should be clustered. Broker clusters enable a message server to scale its operations with the volume of message traffic by distributing client connections among multiple brokers. For Sun Java System Message Queue, in a clustered broker environment, each broker within a cluster is directly connected to all the others. Each client (JMS Binding Component consumer or producer) has a single home broker with which it communicates directly, sending and receiving messages as if that broker were the only one on the server.

Behind the scenes, the home broker works with the other brokers in the cluster to share the load of providing delivery services for all connected clients. One broker within the cluster can be designated as the master broker. The master broker maintains a configuration change record in which changes to the cluster’s persistent entities (destinations and durable subscriptions) are recorded. This record is used to propagate such change information to brokers that were offline at the time the changes occurred.

For detailed information about clustering for Sun Java System Message Queue, see the Sun Java System Message Queue documentation.

The following diagram illustrates how a cluster of JBI/JMS Binding Components and a cluster of Sun Java System Message Queue brokers appears.