IBM WebSphere MQ allows different applications to communicate asynchronously through queues across different operating systems, different processors, and different application systems.
WebSphere MQ includes the Message Queue Interface (MQI), a common low-level application program interface (API). Applications use MQI to read and write messages to the queues.
A queue manager is a system program that provides queuing services, and owns and manages the set of resources that are used by WebSphere MQ. These resources include queues, channels, process definitions, and so on.
A queue is a data structure used to store messages.There are several types of queue objects available in WebSphere MQ:
Local queue object – identifies a local queue belonging to the queue manager to which the application is connected. All queues are local queues in that each queue belongs to a queue manager, and for that queue manager, the queue is a local queue.
Remote queue object – identifies a queue belonging to another queue manager that is a different queue manager from the one to which the application is connected. This queue must be defined as a local queue to the queue manager to which the remote queue object belongs.
Alias queue object – is not a queue, but an object pointer to a local or remote queue.
Model queue object – defines a set of queue attributes that is used as a template to create a dynamic queue.
All types of queue objects can be sent in messages, but messages can be read only from local queue objects.
In addition to the queue object types that are available in WebSphere MQ, there are some other concepts about queues as well:
Remote queue definitions – are definitions for queues that are owned by another queue manager, and not queues themselves.
Remote queue definitions enable an application to put a message to a remote queue without having to specify the name of the remote queue or the remote queue manager, or the name of the transmission queue.
Predefined queues – are created by an administrator using the appropriate MQ Series commands (MQSC) or WebSphere MQ programmable command format (PCF) commands. Predefined queues are permanent, existing independently of the applications that use them, and persisting through WebSphere MQ restarts.
Dynamic queues – are created when an application issues an MQOPEN request specifying the name of a model queue. The queue created is based on a template queue definition, which is called a model queue. The attributes of dynamic queues are inherited from the model queue from which they are created.
Cluster queue objects – are hosted by a cluster queue manager and are made available to other queue managers in the cluster.
A channel is a logical communication link between a WebSphere MQ client and a WebSphere MQ server, or between two WebSphere MQ servers. There are two categories of channel in WebSphere MQ:
Message channels – are one-way links that connect two queue managers via message channel agents.
MQI channels – connect a WebSphere MQ client to a queue manager on a server machine, and are established when you issue an MQCONN or MQCONNX call. An MQ channel is a two-way link used to transfer only MQI calls and responses.
There are two channel types for MQI channel definitions:
Client-connection channel – connects to the WebSphere MQ client.
Server-connection channel – connects to the server running the queue manager, which communicates with the WebSphere MQ application that is running in an WebSphere MQ client environment.
The MQ channel supports the industry-standard Secure Sockets Layer (SSL) protocol. See your WebSphere MQ documentation from IBM for information on whether SSL is available on your platform in version 5.3 or 6.0 of MQ.
A process definition defines a process that executes when incoming messages cause a trigger event.
A WebSphere MQ message consist of two parts:
Message header – message control information that contains a fixed-sized portion and a variable-sized portion.
Message body – application data that contains any type of data (text or binary).
When you use rfhCommand to publish a publication, if the message payload returned by msgrecv is set to:
MQRHRF – the RF header is included in the message body.
MQRHRH – the RF header is not included.
You can obtain the name-value pairs in the RF header by querying @@msgproperties.
If the message body contains characters, code-set conversions are available either through MQ native services, or through user exit handlers. The format of the message body is defined by a field in the message header. MQ does not enumerate all possible message body formats, although some formats are provided in samples. Applications can enter any name of the format. For instance, “MQSTR” contains string data and “MQRHRF” contains topics for MQ pub/sub.
WebSphere MQ message types include:
Datagram – no reply is expected.
Request – a reply is expected.
Reply – reply to a request message.
Report – contains status information from the queue manager or another application.
When messages are sent, various message header properties can be set, such as expiration, persistence, priority, correlation ID, and reply queue.
Message grouping enables you to organize a group of messages into a logically named group. Within a group, each logical message can further be divided into segments. A group is identified by a name, each logical message within a group is identified by a sequence number (starting with 1), and each segment of a logical message is identified by the offset of the message data with respect to the logical message. Segmented messages are not supported by MQ pub/sub, and an attempt to send a segmented message results in an error.
In a queue, messages appear in the physical order in which they were sent to the queue. This means that messages of different groups may be interspersed, and, within a group, the sequence numbers of the messages may be out of order (the latter can occur if two applications are sending messages with the same group ID and partitioned sequence numbers).
When messages are received, the read mode can be either:
Destructive – message is removed, or
Nondestructive – the message is retained. This is known as “browsing,” and allows applications to peruse one or more messages before deciding to remove a particular message from the queue.
Receivers can select particular messages by specifying message header properties such as correlation ID or message ID.
When messages are read—as either destructive or nondestructive—the order in which they are returned can be physical or logical. The order is defined by the queue definition. The queue can be defined as being in priority order or first-in, first-out order.
