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 requester 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
To overcome this situation, there are various options when you
configure the service integration bus system or the JMS applications:
Consider the advantages and disadvantages of each option and the
requirements of your 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 your 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.