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

Sender - Receiver Channel

server_request_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