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
Restricting reply messages to the queue point that is local to the requesting application
When a JMS queue identifies a service integration bus queue as the reply queue, and that service integration bus queue has multiple queue points, you can configure a JMS queue to restrict the messages to the queue point that is local to the application that referenced the JMS queue. You 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). The local queue point is the queue point on the messaging engine to which the application is connected.
Example: A JMS queue called Reply is configured to identify the service integration bus queue that is to be used as the reply queue. The JMS queue is configured to restrict the messages to the local queue point (see the related tasks for more details). Figure 1. A requesting JMS application connects to one of the messaging engines in the cluster bus member
The bus member also owns the service integration bus queue used as the reply queue, so each messaging engine has a queue point of the reply queue configured.
The requesting application creates a JMS message and sets the JMSReplyTo destination to the JMS queue named Reply. The requesting application sends the request message to the queue for the service by using another JMS queue, called Service. (Service requires no special configuration.) By default, this message might be delivered to any of the queue points that belong to Service, although it would usually go to the local queue point. However, to fully illustrate this example, the system sends the message to the other queue point.
When the application that sent the request message is connected to a messaging engine that also has a queue point for the underlying service integration bus reply queue configured to it, and the option is enabled, the identity of that single queue point of the reply queue is added to the information in the JMSReplyTo queue in the message. Figure 2. The requesting application sends the request message to the queue for the service by using another JMS queue
The request message is delivered to the queue for the service, Service, and processed by the service. On completion, the service sends a JMS message to the reply queue identified in the request message (obtained using the JMS Message.getJMSReplyTo method). At this point, the messaging system would by default send the reply message to any one of the queue points of Reply but, as the requestor scoped the reply queue to its local queue point, the reply is sent to the single queue point on the messaging engine to which the requestor was connected. Figure 3. The message is sent to the requesting application local queue point even when the replying application has a local queue point for the reply queue
The system behaves as if the service integration bus queue has only one queue point. If the queue point that the reply is scoped to is not available, the message is not sent to any other queue point.
This approach has the following advantages:
- Reply messages are always sent back to the queue point that is local to the requesting application. This reduces the message route.
- Request applications connected to different messaging engines in the bus member can use the same JMS queue definition. This allows dynamic workload balancing across the cluster.
This approach has the following disadvantages:
- If the requesting application intends to disconnect and reconnect before receiving the reply message, the application must know which messaging engine it is connecting to, and must connect to the same one when it reconnects. This is achieved in the JMS connection factory by targeting a messaging engine and using the JMS connection factory to reconnect. This configuration excludes workload balancing.
- The requesting application must be connected to a messaging engine in the bus member that owns the service integration bus reply queue. Otherwise, there is no local queue point to scope reply messages to and the system follows default message routing behavior.
Refinement
To achieve workload balancing of multiple requesting applications across all messaging engines in the bus member, while allowing applications to disconnect and reconnect, requires the following configuration:
- Multiple connection factories, each targeting a different messaging engine.
- The requesting applications to be spread across connection factories.
JMS request and reply messaging with cluster bus members
Configure a queue for the default messaging provider Configure a queue connection factory for the default messaging provider