Understanding Channels in WebSphere MQ
A channel provides a communication path between Queue Managers. There are two types of channels - Message Channels and MQI channels (also called Client channels).
Message channels - provide a communication path between two queue managers on the same, or different, platforms.
A message channel can transmit messages in one direction only. If two-way communication is required between two queue managers, two message channels are required.
There are six types of message channels
- Sender - initiates connection to Receiver
- Server - Accepts request to start from requester, then becomes Sender
- Receiver - Passive; waits for initiation sequence form Sender
- Requester - Active at start, then becomes Receiver
- Cluster-sender (used amongst Cluster Queue Managers)
The Sender side of the session is the “transaction coordinator”.
Message channels implement a protocol that includes a commitment protocol. Channels recover from failure by agreement: they must agree on the last committed unit of work [would this be harder if channels were bi- directional??]
MQI channels - connect an MQSeries client to a queue manager on a server machine (where a queue manager is defined). Used for transfer of MQI calls and responses only and is bi-directional.
Sender - Receiver Channel
Requestor - Server Channel
A message any arbitrary data that one program wants to send to another. This data is called the application data. A message needs to include other information, such as its destination and possibly a return address. This type of data is called the message descriptor
There are four types of messages:
- A request message is used by one program to ask another program for something (usually data). A request message needs a reply.
- A reply message is used in response to a request message.
- A one-way message, as you would expect, doesn’t need a reply, though it can carry data.
A report message is used when something unexpected occurs. For example, if the data in a reply message is not usable, the receiving program might issue a report message.
Most useful report messages are generated by the Queue Manager. For example, Delivery confirmation.
Messages can have a “time-to-live”, called Expiry. A message that has not been delivered before its expiration is removed (not given to an app)
What to do with undeliverable messages? Each queue manager can have a dead-letter queue. Messages, continued
Messages can be individually designated persistent or non-persistent (persistent messages are logged to enable recovery)
Message Correlator - select which message to get from queue
Message Priority - retrieve messages in different order of put
Segmented Messages - allows ending of VERY LARGE messages (> 100 MB)
A message can contain a “reply to” address (the name of a Queue Manager and Queue). This tells the receiving application where any response should be sent. • Messages are added and removed from queues in Units of Work • The smallest Unit of Work is one message.
Units of work are atomic.
When an app reads a message from a queue, a message “appears” to have been removed, but in fact, it is still in storage until the app “commits” the unit of work.
Check out our Popular Articles