Network Deployment (Distributed operating systems), v8.0 > Applications > Service integration > High availability and workload sharing > Workload sharing > Workload sharing with queue destinations

JMS request and reply messaging with cluster bus members

A typical JMS messaging pattern involves a requesting application that sends a message to a JMS queue for processing by a messaging service, for example, a message-driven bean.

When the requesting application sends the request message, the message identifies another JMS queue to which the service should send a reply message. After sending the request message, the requesting application either waits for the reply message to arrive, or it reconnects later to retrieve the reply message. Figure 1. Typical JMS messaging pattern

The request and reply pattern requires the following conditions:

• The requesting application can identify, in the requesting message, where the service must send the reply message.
• The requesting application can consume the reply message from the reply location.

A JMS queue can refer to a service integration bus destination that is defined on a server bus member or cluster bus member.

• If the bus member is a server (which can have only one messaging engine), or a cluster with a single messaging engine, a JMS queue identifies a single service integration bus queue point.

• If the bus member is a cluster with multiple messaging engines (typically, to provide workload sharing or scalability), a JMS queue identifies multiple queue points; one on each messaging engine in the bus member.

Figure 2. A service integration bus queue destination defined to an application server bus member

The following behavior occurs by default:

• The queue point that an application sends messages to, or receives messages from, is determined by the messaging system.
• During its lifetime, a consumer, in this case a JMS message consumer, consumes from only one queue point.

This request and reply behavior allows a reply message to be sent to a different queue point from the one on which the requestor is waiting for it. This can result in the reply message not being received. Figure 3. A service integration bus queue destination that is defined to a cluster bus member with two messaging engines
two messaging engines." />

To overcome this situation, there are various options when you configure the service integration bus system or the JMS applications:

• Use a temporary queue as the reply queue.

• Use a scoped service integration bus alias destination to restrict messages to a single queue point.

• Restrict reply messages to the queue point that is local to the requesting application.

• Configure the requestor to consume messages from all queue points simultaneously.

Consider the advantages and disadvantages of each option and the requirements of the application, before you choose an approach.

Summary

Use the simplest solution that satisfies the requirements of the request/reply scenario. For example:

• If reply messages are required only while the requesting application is initially connected, use non-persistent messages and temporary queues. Also consider setting a timeToLive of the initial request message, if the requesting application will wait for a reply for only a finite time.

• If a single queue point (and its messaging engine) can handle all the reply message traffic for the requesting applications, but a cluster bus member with multiple messaging engines is required for other messaging traffic (for example, the request messages), use a service integration bus alias destination to scope the messages to that single queue point.

If necessary, you can combine these options to achieve the solution that best satisfies the requirements of the application and has the best performance and scalability.

For example, if requesting applications typically receive their reply messages during the initial connection but under certain rare conditions (for example, a failure) they have to reconnect to receive the reply, the following approach might be suitable:

• Enable the scopeToLocalQP option of the JMS queue, and allow the requesting application to connect to any of the messaging engines in the cluster bus member (that is, target the JMS connection factory at the bus member). This allows the connections to be workload balanced but restricts reply messages to the local queue point. The result is that reply messages can be found while using the same connection to receive the reply that was used to send the request.

• When re-connecting after a failure, enable the Message gathering option on the JMS queue so that the reply message can be received from wherever it is held.

This approach enables dynamic workload balancing of the requesting applications and minimizes the performance implications of message gathering by reducing its use to failure scenarios.

Workload sharing with queue destinations Use a temporary queue as a reply queue Use a scoped service integration bus alias destination to restrict messages to a single queue point Restricting reply messages to the queue point that is local to the requesting application Configure the requestor to consume messages from all queue points simultaneously

+

Search Tips   |   Advanced Search

+

Search Tips   |   Advanced Search