Restricting reply messages to the queue point that is local to the requesting application

When a JMS queue identifies a service integration bus queue as the reply queue, and that service integration bus queue has multiple queue points, you can configure a JMS queue to restrict the messages to the queue point that is local to the application that referenced the JMS queue. You do this to ensure that a reply message is sent to the appropriate queue point for a cluster bus member.

A service integration bus queue has multiple queue points if it is owned by a cluster bus member with multiple messaging engines (typically, to provide workload sharing or scalability). The local queue point is the queue point on the messaging engine to which the application is connected.

Example: A JMS queue called Reply is configured to identify the service integration bus queue that is to be used as the reply queue. The JMS queue is configured to restrict the messages to the local queue point (see the related tasks for more details).

Figure 1. A requesting JMS application connects to one of the messaging engines in the cluster bus member
A requesting JMS application connects to one of the messaging engines in the cluster bus member.

The bus member also owns the service integration bus queue that is used as the reply queue, so each messaging engine has a queue point of the reply queue configured.

The requesting application creates a JMS message and sets the JMSReplyTo destination to the JMS queue named Reply. The requesting application sends the request message to the queue for the service by using another JMS queue, called Service. (Service requires no special configuration.) By default, this message might be delivered to any of the queue points that belong to Service, although it would usually go to the local queue point. However, to fully illustrate this example, the system sends the message to the other queue point.

When the application that sent the request message is connected to a messaging engine that also has a queue point for the underlying service integration bus reply queue configured to it, and the option is enabled, the identity of that single queue point of the reply queue is added to the information in the JMSReplyTo queue in the message.

Figure 2. The requesting application sends the request message to the queue for the service by using another JMS queue
The requesting application sends the request message to the queue for the service using another JMS queue.

The request message is delivered to the queue for the service, Service, and processed by the service. On completion, the service sends a JMS message to the reply queue identified in the request message (obtained using the JMS Message.getJMSReplyTo method). At this point, the messaging system would by default send the reply message to any one of the queue points of Reply but, as the requestor scoped the reply queue to its local queue point, the reply is sent to the single queue point on the messaging engine to which the requestor was connected.

Figure 3. The message is sent to the requesting application local queue point even when the replying application has a local queue point for the reply queue
The message is sent to the requesting application local queue point even when the replying application has a local queue point for the reply queue.

The system behaves as if the service integration bus queue has only one queue point. If the queue point that the reply is scoped to is not available, the message is not sent to any other queue point.

This approach has the following advantages:
This approach has the following disadvantages:

Refinement

To achieve workload balancing of multiple requesting applications across all messaging engines in the bus member, while allowing applications to disconnect and reconnect, requires the following configuration:
Concept topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 5:30:17 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-iseries&topic=cjt0022_
File name: cjt0023_.html