Channels
IBM® MQ can use three different types of channel: a message channel, an MQI channel, and an AMQP channel.
Do not confuse these three distinct types of channel:
- Message channel
- A message channel is a unidirectional communications link between two queue managers. IBM MQ uses message channels to transfer messages between the queue managers. To send messages in both directions, you must define a channel for each direction.
- MQI channel
- An MQI channel is bidirectional and connects an application (MQI client) to a queue manager on a server machine. IBM MQ uses MQI channels to transfer MQI calls and responses between MQI clients and queue managers.
![[V8.0.0.4 Oct 2015]](ng8004.gif)
AMQP channel- An AMQP channel, which is bidirectional and connects an AMQP client to a queue manager on a server machine. IBM MQ uses AMQP channels to transfer AMQP calls and responses between AMQP applications and queue managers.
When referring to message channels, the word channel is often used as a synonym for a channel definition. It is usually clear from the context whether we are talking about a complete channel, which has two ends, or a channel definition, which has only one end.
Message channels
Message channel definitions can be one of the following types:
| Message channel definition type | Description |
|---|---|
| Sender | A sender channel is a message channel that the queue manager uses to send messages to other queue managers. To send messages using a sender channel, you must also create, on the other queue manager, a receiver channel with the same name as the sender channel. You can also use sender channels with requester channels if you are implementing a "callback" mechanism. |
| Server | A server channel is a message channel that the queue manager uses to send messages to other queue managers. To send messages using a server channel, you must also create, on the other queue manager, a receiver channel with the same name as the server channel. You can also use server channels with requester channels. In that case, the requester channel definition at the other end of the channel requests the server channel definition to start. The server sends messages to the requester. The server can also initiate the communication as long as the server knows the connection name of the partner channel. |
| Receiver | A receiver channel is a message channel that the queue manager uses to receive messages from other queue managers. To receive messages using a receiver channel, you must also create, on the other queue manager, a sender or a server channel with the same name as this receiver channel. |
| Requester | A Requester channel is a message channel that the queue manager uses to receive messages from other queue managers. A Requester channel can request the partner channel defined at the remote end to start. If the partner channel is a Server channel, the Server channel accepts the start request and starts to send messages, from the transmission queue identified in the Server channel definition, to the Requester channel. If the partner channel is a Sender channel, the Sender channel accepts the start request but then closes the connection with the Requester. The Sender channel then starts, negotiates a session with the partner Requester channel and starts to send messages from the transmission queue identified in the Sender channel definition. This latter case essentially provides for a call back mechanism in that the Requester channel requests the Sender channel to call back. |
| Cluster-sender | A cluster-sender (CLUSSDR) channel definition defines the sending end of a channel on which a cluster queue manager can send cluster information to one of the full repositories. The cluster-sender channel is used to notify the repository of any changes to the queue manager's status, for example the addition or removal of a queue. It is also used to transmit messages. The full repository queue managers themselves have cluster-sender channels that point to each other. They use them to communicate cluster status changes to each other. It is of little importance which full repository a queue manager's CLUSSDR channel definition points to. After the initial contact has been made, further cluster queue manager objects are defined automatically as required so that the queue manager can send cluster information to every full repository, and messages to every queue manager. For more information, see Queue manager clusters. |
| Cluster-receiver | A cluster-receiver (CLUSRCVR) channel definition defines the receiving end of a channel on which a cluster queue manager can receive messages from other queue managers in the cluster. A cluster-receiver channel can also carry information about the cluster-information destined for the repository. By defining the cluster-receiver channel, the queue manager indicates to the other cluster queue managers that it is available to receive messages. You need at least one cluster-receiver channel for each cluster queue manager. For more information, see Queue manager clusters. |
For each channel you must define both ends so that you have a channel definition for each end of the channel. The two ends of the channel must be compatible types.
You can have the following combinations of channel definitions:
- Sender-Receiver
- Server-Receiver
- Requester-Server
- Requester-Sender (callback)
- Cluster-sender-Cluster-receiver
Message channel agents
Each channel definition that you create belongs to a particular queue manager. A queue manager can have several channels of the same or different types. At each end of the channel is a program, the message channel agent (MCA). At one end of the channel, the caller MCA takes messages from the transmission queue and sends them through the channel. At the other end of the channel, the responder MCA receives the messages and delivers them to the remote queue manager.
A caller MCA can be associated with a sender, server, or requester channel. A responder MCA can be associated with any type of message channel.
IBM MQ supports the following combinations of channel types at the two ends of a connection:
| Caller | Direction of message flow | Responder | ||
|---|---|---|---|---|
| Channel type | Listener required? | Listener required? | Channel type | |
| Sender | No | Caller to Responder | Yes | Receiver |
| Server | No | Caller to Responder | Yes | Receiver |
| Server | No | Caller to Responder | Yes | Requester |
| Requester | No | Responder to Caller | Yes | Server |
| Requester | Yes | Responder to Caller | Yes | Sender |
MQI channels
MQI channels can be one of the following types:
| MQI channel type | Description |
|---|---|
| Server connection | A server connection channel is a bidirectional MQI channel that is used to connect an IBM MQ client to an IBM MQ server. The server connection channel is the server end of the channel. |
| Client connection | A client connection channel is a bidirectional MQI channel that is used to connect an IBM MQ client to an IBM MQ server. MQ Explorer also uses client connections to connect to remote queue managers. The client connection channel is the client end of the channel. When you create a client-connection channel, a file is created on the computer that hosts the queue manager. You must then copy the client-connection file to the IBM MQ client computer. |
AMQP channels
There is only one type of AMQP channel.
You use the channel to connect an AMQP messaging application with a queue manager, enabling the application to exchange messages with IBM MQ applications. An AMQP channel allows you to develop an application using MQ Light, and then deploy it as an enterprise application, taking advantage of the enterprise-level facilities provided by IBM MQ.
For more information about channels, see Channels in the IBM MQ online product documentation.