Use a scoped service integration bus alias destination to restrict messages to a single queue point
Use a service integration bus alias destination to target a service integration bus queue that has multiple queue points. We can 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).
To restrict messages to a single queue point in this way, configure the alias destination to scope the targeted queue down to a single queue point.
If we configure a JMS queue to use such an alias destination, all messages sent to the JMS queue are sent to, or received from, the single queue point. Using such a JMS queue as a reply queue to avoid situations where reply messages are sent to the wrong queue point.
Figure 1. Using a scoped service integration bus alias destination to restrict messages to a single queue point
It is good practice to make the messaging engine that owns the queue point to which the alias destination is scoped, highly available.
This approach has the following advantages:
- It is simple to configure.
- A requesting application can reconnect to any messaging engine (even a messaging engine that is not on the bus member that owns the reply queue) and locate its reply messages.
- All messages are sent to the same queue point, simplifying monitoring of the system.
This approach has the following disadvantages:
- Sending all reply messages to the same queue point removes any workload balancing advantages of the cluster bus member for this message traffic (see Refinement).
- Reply messages received by applications that are not connected to the messaging engine that owns the scoped queue point must be transferred between messaging engines. This increases the message route.
Refinement
We can improve the workload balancing of the system by configuring a scoped alias destination (and accompanying JMS queue) for each queue point of the reply queue, and then sharing requesting applications across these alias destinations. If the requesting application intends to disconnect and reconnect before receiving the reply message, it must use the JMS queue/alias destination that it set as the JMSReplyTo destination in the request message.
Related:
Foreign destinations and alias destinations JMS request and reply messaging with cluster bus members