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.

- 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.
- 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.

- 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 requester is waiting for it. This can result in the reply message not being received.

- 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 requester to consume messages from all queue points simultaneously.
Consider the advantages and disadvantages of each option and the requirements of your application, before you choose an approach.
Summary
- 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 your application and has the best performance and scalability.
- 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.