Accessing Non-Local Queue Managers and Non-Local Queues

When used with alias queues and remote queues, the WebSphere MQ Adapter functions with several restrictions.

Alias queues and remote queues with local queue definitions may be accessed in the same way as actual local queues, through the use of the Adapter OTD’s accessQueue(String) method. Remote queues without local queue definitions need to use the accessQueue(String, String) method instead.

Also, when alias queues or remote queues are used, the Adapter cannot proactively verify the connection (and reconnect, if necessary) before each OTD operation. This is because the Adapter verifies connections by querying queue objects, and it is not possible to query alias queues and remote queues. This means that when alias queues or remote queues are used with the Adapter, the Collaboration is responsible for recovering connection failures itself, including reestablishing the queue manager and queue connections as needed.

For more information, refer to the WebSphere MQ Adapter Javadoc.

To Connect to a Remote WebSphere MQ Queue.

When an Adapter connects to a local queue manager and accesses one of its queues, that queue is a local queue. When an Adapter connects to a remote queue manager and accesses one of its queues, then that queue, is also a local queue. In WebSphere MQ terms, a remote queue is a queue that is managed by a queue manager other than the one to which the application (in this case, the Adapter) is connected.

For example, say that there are two queue managers, QM1 and QM2. QM1 manages a queue (Q1) and runs on Host1. QM2 manages a queue (Q2) and runs on Host2.

Furthermore, say that need to send messages to Q2, but the Adapter may only communicate with Host1 (that is, Host2 is unreachable from the system in which the Adapter is executing). By creating the appropriate channels and a remote queue definition (R1 on QM1), messages sent to R1 can be shuttled automatically to Q2 on QM2.

For this example, the Queues and the Adapter are configured as follows:

1. If either QM1 or QM2 do not have a transmission queue defined, create one. Both queue managers require one transmission queue each. In this example, assume that both queue managers have the transmission queue ’xmit’.
2. Create a Sender Channel for QM1 that points to Host2 and transmission queue xmit. The name of the channel must match the Receiver Channel created in the next step.
3. Create a Receiver Channel for Q2. The name of the channel must match the Sender Channel created in the previous step.
4. In QM1, create a Remote Queue Definition (R1). Designate Q2 as its remote queue, QM2 as its remote queue manager, and xmit as its transmission queue.
5. Configure the MQ Adapter to connect to Host1, QM1, and have it put messages into queue R1.

   ---

   Note - Messages cannot be read/GET from remote queues, only PUT. In the example situation above, to read the messages placed in QM2:Q2 through R1, an Adapter needs to connect directly to QM2 (Host2), thereby interacting with Q2 as a local queue.

   ---