What is intercommunication?

In WebSphere MQ, intercommunication means sending messages from one queue manager to another. The receiving queue manager could be on the same machine or another; nearby or on the other side of the world. It could be running on the same platform as the local queue manager, or could be on any of the platforms supported by WebSphere MQ. This is called a distributed environment. WebSphere MQ handles communication in a distributed environment such as this using Distributed Queue Management (DQM).

The local queue manager is sometimes called the source queue manager and the remote queue manager is sometimes called the target queue manager or the partner queue manager.

How does distributed queuing work?

Figure 1 shows an overview of the components of distributed queuing.

Figure 1. Overview of the components of distributed queuing

1. An application uses the MQCONN call to connect to a queue manager.
2. The application then uses the MQOPEN call to open a queue so that it can put messages on it.
3. A queue manager has a definition for each of its queues, specifying information such as the maximum number of messages allowed on the queue.
4. If the messages are destined for a queue on a remote system, the local queue manager holds them in a message store until it is ready to forward them to the remote queue manager. This can be transparent to the application.
5. Each queue manager contains communications software called the moving service component; through this, the queue manager can communicate with other queue managers.
6. The transport service is independent of the queue manager and can be any one of the following (depending on the platform):
   • Systems Network Architecture Advanced Program-to Program Communication (SNA APPC)
   • Transmission Control Protocol/Internet Protocol (TCP/IP)
   • Network Basic Input/Output System (NetBIOS)
   • Sequenced Packet Exchange (SPX)
   • User-Datagram Protocol (UDP)

What do we call the components?

1. WebSphere MQ applications can put messages onto a local queue, that is, a queue on the queue manager the application is connected to.
2. A queue manager has a definition for each of its queues. It can also have definitions for queues that are owned by other queue managers. These are called remote queue definitions. WebSphere MQ applications can also put messages targeted at these remote queues.
3. If the messages are destined for a remote queue manager, the local queue manager stores them on a transmission queue until it is ready to send them to the remote queue manager. A transmission queue is a special type of local queue on which messages are stored until they can be successfully transmitted and stored at the remote queue manager.
4. The software that handles the sending and receiving of messages is called the Message Channel Agent (MCA).
5. Messages are transmitted between queue managers on a channel. A channel is a one-way communication link between two queue managers. It can carry messages destined for any number of queues at the remote queue manager.

Components needed to send a message

If a message is to be sent to a remote queue manager, the local queue manager needs definitions for a transmission queue and a channel.

Each end of a channel has a separate definition, defining it, for example, as the sending end or the receiving end. A simple channel consists of a sender channel definition at the local queue manager and a receiver channel definition at the remote queue manager. These two definitions must have the same name, and together constitute one channel.

There is also a message channel agent (MCA) at each end of a channel.

Each queue manager should have a dead-letter queue (also known as the undelivered message queue). Messages are put on this queue if they cannot be delivered to their destination.

Figure 2 shows the relationship between queue managers, transmission queues, channels, and MCAs.

Figure 2. Sending messages

Components needed to return a message

If your application requires messages to be returned from the remote queue manager, you need to define another channel, to run in the opposite direction between the queue managers, as shown in Figure 3.

Figure 3. Sending messages in both directions

Cluster components

An alternative to the traditional WebSphere MQ network is the use of clusters. Clusters are supported on WebSphere MQ for AIX, iSeries, HP-UX, Solaris, z/OS, and Windows, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp only.

A cluster is a network of queue managers that are logically associated in some way. You can group queue managers in a cluster so that queue managers can make the queues that they host available to every other queue manager in the cluster. Assuming you have the necessary network infrastructure in place, any queue manager can send a message to any other queue manager in the same cluster without the need for explicit channel definitions, remote-queue definitions, or transmission queues for each destination. Every queue manager in a cluster has a single transmission queue that transmits messages to any other queue manager in the cluster. Each queue manager needs to define only one cluster-receiver channel and one cluster-sender channel.

Figure 4 shows the components of a cluster called CLUSTER:

Figure 4. A cluster of queue managers

• CLUSTER contains three queue managers, QM1, QM2, and QM3.
• QM1 and QM2 host full repositories of information about the queue managers and queues in the cluster.
• QM2 and QM3 host some cluster queues, that is, queues that are accessible to any other queue manager in the cluster.
• Each queue manager has a cluster-receiver channel called TO.qmgr on which it can receive messages.
• Each queue manager also has a cluster-sender channel on which it can send information to one of the repository queue managers.
• QM1 and QM3 send to the repository at QM2 and QM2 sends to the repository at QM1.

As with distributed queuing, you use the MQPUT call to put a message to a queue at any queue manager. You use the MQGET call to retrieve messages from a local queue.

For further information about clusters, see the WebSphere MQ Queue Manager Clusters book.