webMethods client-side clustering for JMS is made possible through a webMethods extension to the JMS API. The extension allows you to define one or more policy based cluster connection factories. A cluster connection factory is similar to a normal JMS connection factory, except that it defines a template for creating connections to a group of Brokers, rather than to a single Broker.

The cluster connection factory is associated with a cluster and a load balancing policy that determines the message distribution logic during the publish operation. Based on the governing policy in the cluster connection factory, the message is published to one or more Brokers in the cluster. For more information about load balancing policies, see Cluster Load Balancing Policies.

webMethods clustering for JMS offers only client-side failover. When a Broker in a cluster is not available for processing the messages, the messages get stuck in a queue and cannot reach a subscriber until that Broker restarts. The remaining Brokers in the cluster continue to share the message distribution load. Conventional HA solution (server-side failover) is still required to back up each server on the list.

Once-and-only once delivery is not guaranteed for the multisend best effort and multisend guaranteed policies if any of the Broker goes down during publishing or subscription. For more information, see Cluster Load Balancing Policies.

C# API clients will continue to use the publisher reconnect feature if they want a rudimentary publisher-side failover support.

JMS priority messaging is supported in client-side clustering for JMS. The individual Broker in a cluster will conform to the message priority, and the queue will contain messages ordered by priority, but, the subscriber could receive messages randomly from any Broker. The Brokers in the cluster will not coordinate with each other to ensure that the subscriber receives the message from a queue that has the highest priority message. Message priority will be strictly enforced on a single Broker, but would only be loosely followed across Brokers in a cluster.