How to get to the remote queue manager

You might not always have one channel between each source and target queue manager. There are a number of other ways of linking between the two, including multi-hopping, sharing channels, using different channels and clustering.

Multi-hopping

If there is no direct communication link between the source queue manager and the target queue manager, it is possible to pass through one or more intermediate queue managers on the way to the target queue manager. This is known as a multi-hop.

You need to define channels between all the queue managers, and transmission queues on the intermediate queue managers. This is shown in Figure 1.
Figure 1. Passing through intermediate queue managers
The figure shows three queue managers. In order to send messages to the destination queue on queue manager three (QM3), an intermediate queue manager, QM2, is used. Messages are sent from QM1 to the transmision queue on QM2, and then on to the destination queue on QM3. Channel definitions exist between QM1 and QM2, and between QM2 and QM3.

Sharing channels

As an application designer, you have the choice of forcing your applications to specify the remote queue manager name along with the queue name, or creating a remote queue definition for each remote queue. This definition holds the remote queue manager name, the queue name, and the name of the transmission queue. Either way, all messages from all applications addressing queues at the same remote location have their messages sent through the same transmission queue. This is shown in Figure 2.
Figure 2. Sharing a transmission queue
The figure shows message flow from a queue manager, QM1, to another queue manager, QM2. Remote queue definitions on QM1 enable QM1 to put messages to a remote queue manager. Messages are sent using the transmission queue on QM1.

Figure 2 illustrates that messages from multiple applications to multiple remote queues can use the same channel.

Using different channels

If you have messages of different types to send between two queue managers, you can define more than one channel between the two. There are times when you need alternative channels, perhaps for security purposes, or to trade off delivery speed against sheer bulk of message traffic.

To set up a second channel you need to define another channel and another transmission queue, and create a remote queue definition specifying the location and the transmission queue name. Your applications can then use either channel but the messages are still delivered to the same target queues. This is shown in Figure 3.
Figure 3. Using multiple channels
The figure shows multiple channels between two queue managers. The sending queue manager, QM1, has two channels defined, with a transmission queue for each channel. Messages are sent to the receiving queue manager, QM2, using both channels.

When you use remote queue definitions to specify a transmission queue, your applications must not specify the location (that is, the destination queue manager) themselves. If they do, the queue manager does not use the remote queue definitions. Remote queue definitions give you location independence. Applications can put messages to a logical queue without knowing where the queue is located and you can alter the physical queue without having to change your applications.

Using clustering

Every queue manager within a cluster defines a cluster-receiver channel. When another queue manager wants to send a message to that queue manager, it defines the corresponding cluster-sender channel automatically. For example, if there is more than one instance of a queue in a cluster, the cluster-sender channel could be defined to any of the queue managers that host the queue. IBM® MQ uses a workload management algorithm that uses a round-robin routine to select an available queue manager to route a message to. For more information see Clusters.