Reply-to queue
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, you 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
This example illustrates the use of a reply-to alias to select a different route (transmission queue) for returned messages The use of this facility requires the reply-to queue name to be changed in cooperation with the applications.
This example is for requester applications at 'PARIS' that send messages to server applications at 'LONDON'. The servers' messages are to be returned through an alternative channel using transmission queue 'PARIS_relief' (the default return channel would be served with a transmission queue 'PARIS').
The reply-to queue alias is a particular use of the remote queue definition named 'Answer_alias'. Applications at PARIS include this name, 'Answer_alias', in the reply-to field of all messages that they put on queue 'Inquiry'.
Reply-to queue definition 'Answer_alias' is defined as 'Answer at PARIS_relief'. Applications at PARIS expect their replies to appear in the local queue named 'Answer'.
Server applications at LONDON use the reply-to field of received messages to obtain the queue and queue manager names for the reply messages to the requester at PARIS.
Definitions used in this example at PARIS
The WebSphere MQ system administrator at PARIS must ensure that the reply-to queue 'Answer' is created along with the other objects. The name of the queue manager alias, marked with a '*', must agree with the queue manager name in the reply-to queue alias definition, also marked with an '*'.
Object Definition Local transmission queue LONDON Remote queue definition Object name Inquiry Remote queue manager name LONDON Remote queue name Inquiry Transmission queue name LONDON (DEFAULT) Queue manager alias Object name PARIS_relief * Queue manager name PARIS Queue name (blank) Reply-to queue alias Object name Answer_alias Remote queue manager name PARIS_relief * Remote queue name Answer
Definitions used in this example at LONDON
The WebSphere MQ system administrator at LONDON must ensure that the local queue exists for the incoming messages and that the correctly named transmission queue is available for the reply messages
Object Definition Local queue Inquiry Transmission queue PARIS_relief
Put definition at PARIS
Applications fill the reply-to fields with the reply-to queue alias name, and leave the queue manager name field blank.
Field Content Queue name Inquiry Queue manager name (blank) Reply-to queue name Answer_alias Reply-to queue manager (blank)
Put definition at LONDON
Applications at LONDON retrieve the reply-to queue name and queue manager name from the original message and use them when putting the reply message on the reply-to queue.
Field Content Queue name Answer Queue manager name PARIS_relief
How the example works
In this example, requester applications at PARIS always use 'Answer_alias' as their reply-to queue in the relevant field of the put call, and they always retrieve their messages from the queue named 'Answer'.
The reply-to queue alias definitions are available for use by the PARIS system administrator to change the name of the reply-to queue 'Answer', and of the return route 'PARIS_relief'.
Changing the queue name 'Answer' is normally not useful because the PARIS applications are expecting their answers in this queue. However, the PARIS system administrator is able to change the return route (class of service), as necessary.
How the queue manager makes use of the reply-to queue alias
Queue manager PARIS retrieves the definitions from the reply-to queue alias when the reply-to queue name, included in the put call by the application, is the same as the reply-to queue alias, and the queue manager part is blank.
The queue manager replaces the reply-to queue name in the put call with the queue name from the definition. It replaces the blank queue manager name in the put call with the queue manager name from the definition.
These names are carried with the message in the message descriptor.
Field name Put call Transmission header Queue name Answer_alias Answer Queue manager name (blank) PARIS_relief
Reply-to queue alias walk-through
To complete this example, let us take a walk through the process, from an application putting a message on a remote queue at queue manager 'PARIS', through to the same application removing the reply message from the alias reply-to queue.
- The application opens a queue named 'Inquiry', and puts messages to it. The application sets the reply-to fields of the message descriptor to:
Reply-to queue name Answerable Reply-to queue manager name (blank) - Queue manager 'PARIS' responds to the blank queue manager name by checking for a remote queue definition with the name 'Answer_alias'. If none is found, the queue manager places its own name, 'PARIS', in the reply-to queue manager field of the message descriptor.
- If the queue manager finds a remote queue definition with the name 'Answer_alias', it extracts the queue name and queue manager names from the definition (queue name='Answer' and queue manager name= 'PARIS_relief') and puts them into the reply-to fields of the message descriptor.
- The queue manager 'PARIS' uses the remote queue definition 'Inquiry' to determine that the intended destination queue is at queue manager 'LONDON', and the message is placed on the transmission queue 'LONDON'. 'LONDON' is the default transmission queue name for messages destined for queues at queue manager 'LONDON'.
- When queue manager 'PARIS' puts the message on the transmission queue, it adds a transmission header to the message. This header contains the name of the destination queue, 'Inquiry', and the destination queue manager, 'LONDON'.
- The message arrives at queue manager 'LONDON', and is placed on the 'Inquiry' local queue.
- An application gets the message from this queue and processes the message. The application prepares a reply message, and puts this reply message on the reply-to queue name from the message descriptor of the original message. This is:
Reply-to queue name Answer Reply-to queue manager name PARIS_relief - Queue manager 'LONDON' carries out the put command, and finding that the queue manager name, 'PARIS_relief', is a remote queue manager, it places the message on the transmission queue with the same name, 'PARIS_relief'. The message is given a transmission header containing the name of the destination queue, 'Answer', and the destination queue manager, 'PARIS_relief'.
- The message is transferred to queue manager 'PARIS' where the queue manager, recognizing that the queue manager name 'PARIS_relief' is an alias, extracts from the alias definition 'PARIS_relief' the physical queue manager name 'PARIS'.
- Queue manager 'PARIS' then puts the message on the queue name contained in the transmission header, 'Answer'.
- The application extracts its reply message from the queue 'Answer'.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.