As q wps Developer we need to have basic knowledge on MQ, so this post helps you littile bit on MQ Overview.
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:
o
Client-connection channel – connects to the
WebSphere MQ client.
o
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:
o
MQRHRF – the RF header is included in the
message body.
o
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.