What is the difference between a message channel and the message queue itself?
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
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.