Home
Reply-to queue
Figure 1. Reply-to queue name substitution during PUT call
A complete remote queue processing loop using a reply-to queue is shown in Figure 1. This applies in both a distributed-queuing environment and a clustering environment. The details are as shown in Table 3.
The application opens QA at QMB and puts messages on that queue. The messages are given a reply-to queue name of QR, without the queue manager name being specified. Queue manager QMA finds the reply-to queue object QR and extracts from it the alias name of QRR and the queue manager name QMA_class1. These names are put into the reply-to fields of the messages.
Reply messages from applications at QMB are addressed to QRR at QMA_class1. The queue manager alias name definition QMA_class1 is used by the queue manager to flow the messages to itself, and to queue QRR.
This scenario depicts the way you give applications the facility to choose a class of service for reply messages, the class being implemented by the transmission queue QMA_class1 at QMB, together with the queue manager alias definition, QMA_class1 at QMA. In this way, we can change an application’s reply-to queue so that the flows are segregated without involving the application. That is, the application always chooses QR for this particular class of service, and you have the opportunity to change the class of service with the reply-to queue definition QR.
You must create:
- Reply-to queue definition QR
- Transmission queue object QMB
- Channel_out definition
- Channel_back definition
- Queue manager alias definition QMA_class1
- Local queue object QRR, if it does not exist
The complementary administrator at the adjacent system must create:
- Receiving channel definition
- Transmission queue object QMA_class1
- Associated sending channel
- Local queue object QA.
Your application programs use:
- Reply-to queue name QR in put calls
- Queue name QRR in get calls
In this way, you may change the class of service as necessary, without involving the application, by changing the reply-to alias ‘QR’, together with the transmission queue ‘QMA_class1’ and queue manager alias ‘QMA_class1’.
If no reply-to alias object is found when the message is put on the queue, the local queue manager name is inserted in the blank reply-to queue manager name field, and the reply-to queue name remains unchanged.
Name resolution restriction
Because the name resolution has been carried out for the reply-to queue at ‘QMA’ when the original message was put, no further name resolution is allowed at ‘QMB’, that is, the message is put with the physical name of the reply-to queue by the replying application.
Note that the applications must be aware of the naming convention that the name they use for the reply-to queue is different from the name of the actual queue where the return messages are to be found.
For example, when two classes of service are provided for the use of applications with reply-to queue alias names of ‘C1_alias’, and ‘C2_alias’, the applications use these names as reply-to queue names in the message put calls, but the applications will actually expect messages to appear in queues ‘C1’ and ‘C2’, respectively.
However, an application is able to make an inquiry call on the reply-to alias queue to check for itself the name of the real queue it must use to get the reply messages.
- Reply-to queue alias example
- How the example works
- How the queue manager makes use of the reply-to queue alias
- Reply-to queue alias walk-through
Parent topic:
WebSphere MQ distributed-messaging techniques
ic10950_
Home