Understanding Channels in WebSphere MQ

Channel

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)
• Cluster-receiver

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

Messages  

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

• Reference Lines and Bands in Tableau
• Inspecting Data in Tableau
• IBM Websphere ESB Training in Hyderabad
• Session Configuration