Reply-to queue

We can create a complete remote queue processing loop using a 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 loop 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 is 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. The application always chooses QR for this particular class of service. We have the opportunity to change the class of service with the reply-to queue definition QR.

We 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:

  • Receive 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, we can change the class of service as necessary, without involving the application. You change 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. 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'. The message is put with the physical name of the reply-to queue by the replying application.

The applications must be aware 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. However, the applications actually expect messages to appear in queues 'C1' for 'C1_alias' and 'C2' for 'C2_alias'.

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.

Parent topic: IBM MQ distributed queuing techniques


Related concepts