Remote queue resolution involves connection definitions and network resolution. We require a setup where there are two queue managers, one of which is the local queue manager that we use to put the message, and the other is the queue manager to which we want the message to go. Furthermore, we require that the remote queue manager has a listener, and that the local queue manager has a connection definition describing the listener, see Figure 53.
Figure 53. Local and remote queue managers with a definition and listener pair.
The connection definition/listener pair allows WebSphere MQ Everyplace to establish the network communications necessary to flow the message. The connection definition contains information about communicating with a single queue manager. The connection definition is named for the queue manager to which it defines a route. So in this example the connection definition is called TargetQM, and contains the information necessary to establish connection with (QueueManager)TargetQM. This information includes the address of the machine upon which the queue manager resides (remote host in this example), the port upon which the queue manager is listening (8081 in this example), and the protocol to use when conversing with the queue manager (FastNetwork in this example).
We need a remote queue reference on LocalQM representing the destination queue TargetQueue which resides on TargetQM. There are therefore two entities called TargetQueue@TargetQM. One is the 'real' queue, that is a local queue, and one is a reference to the real queue, a remote queue reference. Refer to Figure 54.
Figure 54. A remote queue reference.
The message resolution for a put on LocalQM to TargetQueue@TargetQM works as follows, see Figure 55.
Figure 55. Message resolution for a put.
The message route is as follows:
Although the connection definition and listener are vital to the message resolution they do not affect the routing in this example, and so we can omit them for the sake of clarity. See Figure 56.
Figure 56. Message resolution for a put
In later examples the connection definitions play a more important role and we will need to show them explicitly. For now we will assume the presence of the logical link formed by the listener and not show them in the diagrams. It is often much more convenient to use a simplified view of the message route. We can do this by thinking of the four elements that contribute to this message resolution as a single, composite, entity. This entity is a Message Route, see Figure 57.
Figure 57. A message route entity.
Here we see the message route that indicates that all messages put to LocalQM and addressed to TargetQueue@TargetQM will be moved directly to the destination. A Message Route is valid only if all the necessary components (Connection Definition, Listener, Remote Queue Definition, and destination queue) are present and correctly configured.
The Message Route is defined as a Push Message Route because messages are pushed from the source queue to the destination queue, by LocalQM.
We can use aliases on the remote queue, as the last step is simply queue resolution performed on TargetQM. The Queue Alias on the target queue appears to the local system as if it were a queue. The remote queue definition on the local system is therefore named for the Queue Alias, rather than the target queue. The diagram makes this clear (note that we have hidden the connection definition and the listener), see Figure 58.
Figure 58. Using aliases on the remote queue.
Here we have defined a remote queue reference which actually refers to an alias for a queue on TargetQM. When we perform a put on LocalQM addressed to QueueAlias@TargetQM the resolution works as follows, see Figure 59.
Figure 59. Message resolution for a put to a remote queue, using a Queue alias defined on TargetQM
Note that the destination name for the message remains QueueAlias@TargetQM until queue resolution on TargetQM. The Remote queue definition completes the requirements for another message route, see Figure 60.
Figure 60. Message route entity of messages put to TargetQueueAlias on TargetQM
The use of aliases described in the previous section allows the creation of parallel routes between a source and a destination. This is sometimes desirable where we wish to send messages synchronously if possible, but asynchronously if the remote end is not currently connected. We can do this with the following setup, see Figure 61.
Figure 61. Creating parallel routes between source and destination.
Here we have defined two aliases on the target queue. One alias will be used to route synchronous traffic to the target queue, one will be used to route asynchronous traffic.
On LocalQM we have defined two remote queue definitions, one pointing at each alias. We can create an asynchronous Remote Queue Definition called Async@TargetQM, and a synchronous Remote Queue Definition called Sync@TargetQM. By choosing the name of the queue that we put to (Sync@TargetQM or Async@TargetQM) we can choose the route that the message follows, even though the destination is the same. First, the resolution of the synchronous route by putting a message to Sync@TargetQM, see Figure 62.
Figure 62. Resolving the synchronous route.
And secondly the asynchronous resolution using AsyncAlias@TargetQM, see Figure 63.
Figure 63. Resolving the asynchronous route.
We could choose to view this as a pair of Push Message Routes, see Figure 64.
Figure 64. A pair of push message routes.
Remote queue references can be chained together to form a longer route. This requires the use of 'Via' connections, and so the technique is described later in this document.