Reply-to queue alias definitions

 

Overview

When an application needs to reply to a message it may look at the data in the message descriptor of the message it received to find out the name of the queue to which it should reply. It is up to the sending application to suggest where replies should be sent and to attach this information to its messages. This has to be coordinated as part of your application design.

 

What is a reply-to queue alias definition?

A reply-to queue alias definition specifies alternative names for the reply information in the message descriptor. The advantage of this is that you can alter the name of a queue or queue manager without having to alter your applications. Queue name resolution takes place at the sending end, before the message is put to a queue.

Note that this is an unusual use of queue-name resolution. It is the only situation in which name resolution takes place at a time when a queue is not being opened.

Normally an application specifies a reply-to queue and leaves the reply-to queue manager name blank. The queue manager fills in its own name at put time. This works well except when you want an alternate channel to be used for replies, for example, a channel that uses transmission queue 'PARIS_relief' instead of the default return channel which uses transmission queue 'PARIS'. In this situation, the queue manager names specified in transmission-queue headers do not match "real" queue manager names but are re-specified using queue manager alias definitions. In order to return replies along alternate routes, it is necessary to map reply-to queue data as well, using reply-to queue alias definitions.

  1. The application puts a message using the MQPUT call and specifying the following in the message descriptor: 
    ReplyToQ='Reply_to'
ReplyToQMgr=''

    Note that ReplyToQMgr must be blank in order for the reply-to queue alias to be used.

  2. You create a reply-to queue alias definition called 'Reply_to', which contains the name 'Answer', and the queue manager name 'PARIS_relief'. 
    DEFINE QREMOTE ('Reply_to') RNAME ('Answer')
       RQMNAME ('PARIS_relief')

  3. The messages are sent with a message descriptor showing ReplyToQ='Answer' and ReplyToQMgr='PARIS_relief'.

  4. The application specification must include the information that replies are to be found in queue 'Answer' rather than 'Reply_to'.

To prepare for the replies you have to create the parallel return channel. This involves defining:

  • At LONDON, the transmission queue named 'PARIS_relief' 
    DEFINE QLOCAL ('PARIS_relief') USAGE(XMITQ)

  • At PARIS, the queue manager alias PARIS_relief' 
    DEFINE QREMOTE ('PARIS_relief') RNAME() RQMNAME(PARIS)

    This queue manager alias terminates the chain of parallel return channels and captures the messages for PARIS.

If you think you might want to do this at sometime in the future, arrange for your applications to use the alias name from the start. For now this is a normal queue alias to the reply-to queue, but later it can be changed to a queue manager alias.

 

Reply-to queue name

Care is needed with naming reply-to queues. The reason that an application puts a reply-to queue name in the message is that it can specify the queue to which its replies will be sent. But when you create a reply-to queue alias definition with this name, you cannot have the actual reply-to queue (that is, a local queue definition) with the same name. Therefore, the reply-to queue alias definition must contain a new queue name as well as the queue manager name, and the application specification must include the information that its replies will be found in this other queue.

The applications now have to retrieve the messages from a different queue from the one they named as the reply-to queue when they put the original message.