JMS can create a temporary queue dynamically for use as
a reply queue. You can use this to ensure that a reply message is
sent to the appropriate queue point for a cluster bus member.
This temporary JMS queue uses a temporary service integration bus
queue. Temporary service integration bus queues have only one queue
point, irrespective of the number of messaging engines in the bus
member. This queue point is created on the messaging engine to which
the creating JMS application is connected.
Figure 1. Temporary queue point on the local messaging
engine for the requesting application
Therefore, for a cluster bus member with multiple messaging engines
(typically, to provide workload management or scalability), you can
use a temporary queue to avoid situations where reply messages are
sent to the wrong queue point.
This approach has the following advantages:
- It is simple to use.
- No further configuration of the service integration bus or JMS
system is required.
- If the JMS connections of a number of requesting applications
are workload balanced across the messaging engines in a cluster bus
member, the temporary queues are workload balanced across these messaging
engines.
This approach has the following disadvantages:
- The reply queue is temporary. When the creating application closes
the JMS connection, or the messaging engine is stopped, the reply
queue, any messages on it, and any messages on their way to it, are
deleted. Therefore, when the JMS application disconnects, it cannot
reconnect later to receive the reply message.
Therefore, it is appropriate to use a temporary queue for a cluster
bus member with multiple messaging engines only if it is acceptable
to lose the reply messages if the application or system stops. If
this approach is not acceptable, the following options allow applications
to reconnect and process reply messages: