+

Search Tips   |   Advanced Search

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, we 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

The bus member also owns the service integration bus queue 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 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 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:


Related concepts

  • JMS request and reply messaging with cluster bus members


    Related tasks

  • Configure a queue for the default messaging provider
  • Configure a queue connection factory for the default messaging provider