Interoperation with IBM MQ: Key IBM MQ concepts
If we are not familiar with basic IBM MQ concepts, read about the objects in IBM MQ that are important for interoperation with WebSphere Application Server.
Queues and topics
A queue is a data structure used to store messages. Application programs can use JMS or IBM MQ API calls to put messages on IBM MQ queues. Other applications can get the messages from the queues.
A topic is the subject of the information that is published in a publish/subscribe message. Instead of putting a message on a specific queue, application programs can publish a message to a topic. Other applications obtain the messages by subscribing to the topic to receive all the messages published to that topic.
When an application puts a message on a queue, only one copy of the message exists. Even if more than one application can get messages from the queue, only one consumer can receive each message. However, when an application publishes a message to a topic, any number of subscribers can receive a copy of the message.
Queue managers and queue-sharing groups
Each IBM MQ queue is owned by a queue manager. The queue manager is responsible for maintaining the queues it owns, and for placing all the messages it receives onto the appropriate queues. Application programs connect to a queue manager when they want to put messages on queues. Queue managers can also put messages on queues as part of their normal operation.
From IBM MQ v7, each topic in IBM MQ is also owned by a queue manager. The queue manager receives messages from publishers, and subscriptions from subscribers. The queue manager is responsible for routing the published messages to the subscribers that have registered an interest in the topic of the messages. In earlier versions of IBM MQ, publish/subscribe messaging is handled by a publish/subscribe broker, not by queue managers.
In IBM MQ for z/OS, we can set up shared queues that can be accessed by several queue managers in a sysplex. Messages that are put onto shared queues are stored in list structures in a zSeries Coupling Facility, and large messages have their message data held in a shared DB2 table.
The queue managers that can access the same set of shared queues form a group called a queue-sharing group. Each member of the queue-sharing group connects to a DB2 system to access shared definitions for IBM MQ objects, including queues and channels. Any queue manager in the group can retrieve the messages held on a shared queue. An application that wants to access one of the shared queues can therefore connect to any of the queue managers within the queue-sharing group, so the application does not depend on the availability of a specific queue manager.
Local queues, remote queues, and clusters
In an IBM MQ network, intercommunication is achieved by sending messages from one queue manager or (for IBM MQ for z/OS) queue-sharing group to another.
IBM MQ application programs can put messages onto a local queue, which is a queue on the queue manager to which the application is connected. A queue manager has a definition for each queue that it owns. A queue manager can also have definitions for the queues that other queue managers own. From the perspective of the local queue manager to which the application is connected, these other queues are remote queues, and the queue managers that own them are remote queue managers.
As well as putting messages onto a local queue, IBM MQ application programs connected to a local queue manager can put messages targeted at remote queues. IBM MQ must then transmit the messages to the remote queue managers that own the remote queues. When messages are destined for an IBM MQ queue on a remote queue manager, the local queue manager holds them in a transmission queue until it is ready to forward 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.
IBM MQ queue managers can be connected to form a cluster, using any of the communications protocols available on the IBM MQ platform. When we group queue managers in a cluster, the queues are still hosted by the queue managers (so they are not shared queues). However, by connecting into the cluster, queue managers can send a message to any other queue manager in the cluster, and make some or all of the queues that they host available to every other queue manager in the cluster as cluster queues. We do not have to set up explicit definitions on each queue manager for each remote queue and for the connection to each remote queue manager. Each queue manager in the cluster also uses a single cluster transmission queue to hold messages for any of the other queue managers, so we do not have to set up a transmission queue for each remote queue manager.
From IBM MQ v7, we can also connect together IBM MQ queue managers that own topics for publish/subscribe messaging. We can group queue managers that own topics into a publish/subscribe cluster, with links between all members, or into a publish/subscribe hierarchy, with parent and child relationships between the connected queue managers. Publications and subscriptions to topics can be shared between all the queue managers in the cluster or hierarchy.
Message channels
IBM MQ messages, whether they are put onto queues or published to topics, are transmitted between queue managers through message channels. A message channel is a one-way communication link between two queue managers. It can carry messages destined for any number of queues or topics that the remote queue manager hosts, or for any number of target queue managers.
We can define the following types of message channel in IBM MQ:
- Sender-receiver channel
- Requester-server channel
- Requester-sender channel
- Server-receiver channel
- Cluster-sender channels
- Cluster-receiver channels
For example, to define the type of message channel called a sender-receiver channel, we define a sender channel at the sending end, which could be the local queue manager. Then we use the same name to define a receiver channel at the receiver end, which could be the remote queue manager. A message channel is unidirectional, so if we want messages to flow in both directions, define a second message channel in the opposite direction between the queue managers.
For queue managers in a cluster, we do not have to define message channels between each pair of queue managers. Instead, we define two message channels to connect each queue manager into the cluster: one cluster-receiver channel for receiving messages, and one cluster-sender channel by which the queue manager introduces itself and learns about the cluster. The queue manager can then send a message to any other queue manager in the cluster.
Do not confuse message channels with MQI channels. The MQI is the Message Queue Interface in IBM MQ, which applications use to interact with queue managers. An QI channel is a type of connection used by an IBM MQ client application to connect to a queue manager running on another system, and to issue MQI calls to the queue manager.
