Basics of IBM Websphere MQ (Part 1)

IBM WebSphere MQ is a family of network software products launched by IBM in March 1992.

It allows independent and potentially non-concurrent applications on a distributed system to communicate with each other.

IBM WebSphere MQSeries allows different applications to communicate asynchronously through queues across different operating systems, different processors, and different application systems.

Queue Manager: The primary component of a WebSphere MQ installation is the Queue Manager. The queue manager handles storage, timing issues, triggering, and all other functions not directly related to actual movement of data.Queue managers communicate with the outside world.

Naming convention for Queue Managers: Naming convention of Queue Manager includes Name of the MQ Manager, Server on which Queue Manager is hosted and Port of the server.

For example: MQUPPAQM on 235.21.108.25(1414)

Queues: These transmit data in FIFO order. These are of following types:

Local Queues: Local queues represent the location in which data is stored awaiting processing.

Remote Queues: Remote queues represent a queue on another queue manager. They define the destination queue, which is one element of the routing mechanism for messages.

Transmission Queue: connects Local Queue to Remote Queue.

Channels: Communication between queue managers relies on channels. Each queue manager uses one or more channels to send and receive data to other queue managers. A channel is unidirectional. A second channel is required to return data.

In a TCP/IP based network, a channel will send or receive data on a specific port. A sending channel has a defined destination and is associated with a specific transmission queue, the mechanism by which messages are queued awaiting transmission on the channel; a receiving channel will receive data from any other queue manager with a sending channel of the same name. When a receiving channel receives a message, it is examined to see which queue manager and queue it is destined for. In the event of a communications failure, MQ can automatically re-establish a connection when the problem is resolved.

Listener: The "listener" has the function of detecting connections from incoming channels and manages the connection of the sending to the receiving channels.

MQ Messages are made up of two parts:

1. MQMD (MQ Message Descriptor / Header)

2. Application Data (Message Body)

1. Message Descriptor: It contains the control information about the message data like type of message, persistence and non-persistence of message, msgID, corrleationID etc.

2. Application Data

The application data section contains the actual data sent from one program to another, and its content and structure are defined by the applications that use it. Generally, the application data only contains information that is meaningful to the applications, since the control information in the message descriptor is sufficient.

Types of Messages:

1. Datagram: Use a datagram when you do not require a reply from the application that receives the message (that is, gets the message from the queue).

An example of an application that could use datagrams is one that displays flight information in an airport lounge. A message could contain the data for a whole screen of flight information. Such an application is unlikely to request an acknowledgement for a message because it probably does not matter if a message is not delivered. The application sends an update message after a short period of time.

2. Request: Use a request message when you want a reply from the application that receives the message.

An example of an application that could use request messages is one that displays the balance of a checking account. The request message could contain the number of the account, and the reply message would contain the account balance.

3. Reply: Use a reply message when you reply to another message.

When you create a reply message, respect any options that were set in the message descriptor of the message to which you are replying. Report options specify the content of the message identifier (MsgId) and correlation identifier (CorrelId) fields. These fields allow the application that receives the reply to correlate the reply with its original request.

4. Report: Report messages inform applications about events such as the occurrence of an error when processing a message. They can be generated by:

A) A queue manager,

B) A message channel agent (for example, if they cannot deliver the message), or

C) An application (for example, if it cannot use the data in the message).

Persistent and Non-Persistent Messages: Persistent messages are written to logs and queue data files. If a queue manager is restarted after a failure, it recovers these persistent messages as necessary from the logged data. Messages that are not persistent are discarded if a queue manager stops, whether the stoppage is as a result of an operator command or because of the failure of some part of your system.

Correlation ID: Whenever a message is put in the queue, if it is successfully put, an ID is generated called Correlation ID. Any reply to that message will be matched with that correlation ID.