What is the difference between a message channel and the message queue itself?

Question

What is the difference between a message channel and a message queue itself?

They're different things. The queue actually holds messages which will be processed (pushed to the listener) in FIFO manner.

A channel is a medium through which messages are transmitted.
What does that mean exactly? In a book "Enterprise Integration Patterns" it says:

Connect the applications using a Message Channel, where one application writes information to the channel and the other one reads that information from the channel.

Does this mean that this message channel actually abstracts the queue away from the producer and consumer of the message? But it really doesn't right? When a producer has to place a message into a queue, it actually specifies the queue manager and queue names it want's to connect to.

There's also the concept of different protocols in channels and different data formats in channels where you have a separate channel for each protocol you're using maybe and maybe a separate channel for each data format (XML, JSON etc). This would facilitate the different queues to pick up from different channels. But why not directly call different queues for different data formats? What exactly is the role of the channel? Is it just a connection?

I'm a completely new at MQM. I've just been assigned to this project which involves producing and consuming messages and I'm trying to wrap my mind around this.

Answer 1

To expand a bit on Shashi's answer, please keep in mind that the EIP book referenced talks about high level messaging patterns. In that context the authors needed a generic term for the medium by which messages are transferred between two points and chose the word "channel".

For purposes of the book the a channel connects any two endpoints that move messages, for any message transport vendor. In this case a channel has attributes that are classes of service and support the various patterns. It may be 1-1, 1-many, many-1, many-many, etc.

So for example if it is ZeroMQ, the endpoints are two peer-to-peer nodes and there's no messaging engine between them. For IBM MQ one endpoint is always the queue manager (a type of messaging engine) and the other is an application or another queue manager.

Based on this example, it should be obvious that channel as used in the book and channel as defined by any messaging transport are at different levels of abstraction. As used by MQ, a channel is a specific set of configuration parameters that define a communication path and includes such attributes as CONNAME, MAXMSGL, tuning parameters, SSL parameters, etc. Once an MQ channel is successfully started, you can see a running instance of it by displaying the channel status. In the case of CLUSRCVR, SVRCONN, and (less commonly) RCVR or RQSTR channels, you may see multiple instances of the same channel active simultaneously.

If you are still with me, you may have noticed that the MQ usage of the term channel always describes one or more point-to-point network connections whereas the EIP book's usage of the term channel is roughly translated as "the thing that moves messages between application endpoints." Consider that two applications connected directly to the queue manager using shared memory would be using a channel as defined in EIP but not as the term is defined by IBM MQ.

Based on that example, it should be clear that the EIP version of the term channel includes the queue manager and any MQ connections between the queue manager and application endpoints.

To sum up:

• The EIP book's channel is all messaging infrastructure that isn't one of the application endpoints, and in an MQ context it includes the queue manager and any MQ channels.
• The IBM MQ channel is a specific configuration defining network connectivity between the queue manager and another queue manager or a client application.

I hope this clarifies the terminology rather than confusing things further. I will update based on any comments if needed.

Answer 2

A message queue stores messages sent by producers so that they can be delivered to consumers. A channel is the media or communication link for transmitting messages from producer to queue, queue to consumer, or one queue in a queue manager to another queue in another queue manager.

There are two types of channels:

1) A Message channel is a unidirectional communications link between two queue managers. Message channels are used to transfer messages between the two queue managers.

2) A MQI channel connects an application (producer or consumer) to a queue manager on a server machine. MQI channels are required to transfer MQ API calls and responses between MQ client applications and queue managers.

So, in simple terms, channel is a communication media between a client application and a queue manager (or between queue managers) for sending and/or receiving messages.

MQ uses a proprietary protocol to transmit messages from client applications to queue managers and between queue managers. The format of the data contained in the message does not matter, it can be anything including bytes, XML, or JSON. Any type of data can be sent over the same channel.

Hope this helped.

Answer 3

WebSphere MQ queues

A queue is a container for messages. Business applications that are connected to the queue manager that hosts the queue can retrieve messages from the queue or can put messages on the queue. A queue has a limited capacity in terms of both the maximum number of messages that it can hold and the maximum length of those messages.

Reference

Channels

WebSphere® MQ uses two different types of channels:

• A message channel, which is a unidirectional communications link between two queue managers. WebSphere 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.
• An MQI (Message Queue Interface) channel, which is bidirectional and connects an application (MQI client) to a queue manager on a server machine. WebSphere MQ uses MQI channels to transfer MQI calls and responses between MQI clients and queue managers

Reference