In a nutshell, WebSphere MQ is an assured delivery mechanism, which consists of queues managed by Queue Managers. We can put messages onto, and retrieve messages from queues, and the movement of messages between queues is facilitated by components called Channels and Transmission Queues.
There are a number of fundamental points that we need to
know about WebSphere MQ:
- All objects in WebSphere MQ are case sensitive
- We cannot read messages from a Remote Queue (only from a Local Queue)
- We can only put a message onto a Local Queue (not a Remote Queue)
It does not matter at this stage if you do not understand the above points, all will become clear in the following sections.
There are some standards regarding WebSphere MQ object
names:
- Queue names, processes and Queue Manager names can have a maximum length of 48 characters
- Channel names can have a maximum length of 20 characters
- The following characters are allowed in names: A-Z,a-z,0-9, and . / _ % symbols
- There is no implied structure in a name — dots are there for readability
Now let's move on to look at MQ queues in a little more
detail.
MQ queues
MQ queues can be thought of as conduits to transport messages between Queue Managers.
There are four different types of MQ queues and one related
object. The four different types of queues are: Local Queue (QL), Remote
Queue (QR), Transmission Queue (TQ), and Dead Letter Queue,
and the related object is a Channel (CH).
One of the fundamental processes of WebSphere MQ is the ability to move messages between Queue Managers. Let's take a high-level look at how messages are moved, as shown in the following diagram:
When the application Appl1 wants to send a message to
application Appl2, it opens a queue - the local Queue Manager (QM1)
determines if it is a Local Queue or a Remote Queue. When Appl1 issues
an MQPUT command to put a message onto the queue, then if the queue is
local, the Queue Manager puts the message directly onto that queue. If the
queue is a Remote Queue, then the Queue Manager puts the message onto a
Transmission Queue.
The Transmission Queue sends the message using the Sender Channel on QM1 to the Receiver Channel on the remote Queue Manager (QM2). The Receiver Channel puts the message onto a Local Queue on QM2. Appl2 issues a MQGET command to retrieve the message from this queue.
Now let's move on to look at the queues used by Q replication and in particular, unidirectional replication, as shown in the following diagram. What we want to show here is the relationship between Remote Queues, Transmission Queues, Channels, and Local Queues. As an example, let's look at the path a message will take from Q Capture on QMA to Q Apply on QMB.
Note that in this diagram the Listeners are not shown.
Q Capture puts the message onto a remotely-defned queue on QMA (the local Queue Manager for Q Capture). This Remote Queue (CAPA.TO.APPB.SENDQ.REMOTE) is effectively a "place holder" and points to a Local Queue (CAPA.TO.APPB.RECVQ) on QMB and specifes the Transmission Queue (QMB.XMITQ) it should use to get there. The Transmission Queue has, as part of its defnition, the Channel (QMA.TO.QMB) to use. The Channel QMA.TO.QMB has, as part of its defnition, the IP address and Listening port number of the remote Queue Manager (note that we do not name the remote Queue Manager in this defnition—it is specifed in the defnition for the Remote Queue).
The defnition for unidirectional Replication Queue Map (circled queue names) is:
SENDQ: CAPA.TO.APPB.SENDQ.REMOTE on the source
RECVQ: CAPA.TO.APPB.RECVQ on the target
ADMINQ: CAPA.ADMINQ.REMOTE on the target
We'll see
till then.....
njoy the simplicity.......
