mq

Document Sample
mq Powered By Docstoc
					Simplified Introduction Message Queuing, and Websphere MQ
This note is for people who like to have a very brief overview of Message Queuing, and one of the most important implementation
The material presented here is on a very introductionary level , and as such, is also very incomplete .

Version 0.4 - 09/03/2009
Compiled by: Albert van der Sel -- Antapex Technology BV


Connecting MQ systems can be done in several ways. In chapters 1,2, and 3 we first talk about a simple "distributing system", like a
Here we will see how to set up channels, remote queue definitions etc..
In chapter 4, we will talk about a MQ cluster, where the setup will differ significantly from a distributed system.
If you just have a couple of nodes, you can create a distributed system, otherwise, with bigger MQ networks, implementing a cluster


1. What is MQ and why use it?
Websphere MQ, is IBM's middleware that provides for messaging and queuing, which can be used as a means for (indirect) Progra

Ofcourse, allmost all communication is from one sort of program to another kind of program. For example, maybe you use an SQL c
Then, you might write your SQL statement, and send it to the Database, which will send the results of your query back to the client p
Or, you use an order-entry system, and the remote Server responds (almost) instantaneously to your requests.
In all these cases, the systems are "tightly coupled" and the working of "requests and responses" is almost (or should be) instantane

But, there are classes of "program to program communication", where it is necessary to relax tightly coupled communication, by the
In the MQ case, this would be a "queue". Here, the communication between the programs is not direct, in the sense that both partne
They ofcourse may, but it's not needed or required.
In fact, because a storage object is used like a "queue", the target program may even be down. And once up, it can processes the m
So the communication could be really asynchroneous, which means here that Program A can forward (put) it's message in the right
Program B at some later time, can inspect the queue and retrieve (get) the message from that queue.
This type of communication resembles a bit like an email system, where messages flows around, and whenever a communication p
and start processing the messages.
So, imaging that an "API" (application program interface) would be defined, which both Program A and Program B "knows" how to u
"put_message_in_queue" and "get_message_from_queue", then this type of infrastructure is quite easy to grasp.


           Program A                                                                                   Program B
                                                          messages
                                               snd                              rcv
           PUT to Q1                                                                                   GET from Q1

                                                          Channel


           Fig. 1.


                                    remote queue Q1 (definition)                local queue Q1
                                    + associated XMIT queue                     at destination.


                              api

So, message queuing is a method of program to program communication. Programs communicate by writing and retrieving applicat
to and from queues, without having the need of a dedicated logical link between them.
If the target program is not available, the messages stay in the queue and get processed later.

If we now focus on "Websphere MQ", and take a quick look on how such a system is implemented, it is like this:
The "engine" of MQ is the "Queue Manager". It's job is to manage queues and the messages in those queues.
In MQ commands, it's mostly abrieviated to "mqm", so whenever you want to create a "queue manager", you will use
a command like "crtmqm", which means something like "create a new mq manager".

Two programs could reside on the same Host, and if they want to communicate trough MQ, they will use a local queue.
Now suppose the two programs reside on different Hosts. Both Hosts will have their own queue managers and queues.
If now messages needs to be transported, it will be from one queue manager to the other. The queue managers will use "channels"
receiving and sending channel, for the actual transport. So you might expect that when you define a channel, you will also define ne
for example, the Hostname (or even the IP address) and the portnumber on which the receiving queue manager will listen.
So a channel is a sort of "Websphere MQ term", for a definition of network parameters, all put together in one "set", known by the n
When you know that a queue manager, with it's queue, will receive messages, a receiving channel must be set up, as well as a "li
The listener signals the queue manager, and a special module called the "Message Channel Agent", that receiving messages must
Note that on the Sending server, the Message Channel Agent was responsible for placing the message on the sender channel.
Take a look at figure 2, which will show you how things are arranged.

Again, lets take a look when Program A wants to send messages to a remote Program B. At Host A, there might exists local queues
But in this case, we need to tell the local queue manager at A, the definition of the queue at location B. That's why a "remote queu
corresponds to the (local) queue at B.
So, a remote queue (definition) represents a queue on another queue manager. They define the destination queue.
Also at A, we tell the queue manager, which channel and type is involveld.
So at A, we create the definition of the queue of B, and call it a "remote queue". Implicitely, it will be associated with a XMIT queue,
However, on a sending system, you still need to create this XMIT queue as a local queue.

In normal distributed processing, a program sends messages to a specific queue owned by a specific queue manager. All message
are placed in a transmission queue on the sender's side.
The messages are moved through a channel, and are placed in the destination queue, which is the target's local queue.



HOSTA                      program A     program B
                       MQPUT             MQGET        MQPUT

                MQI API

                                                                  Message Channel
                                                                  Agent MCA
                queue
                manager       definition of the remote            sender channel "X"
                "saturn"      queue "orange" & XMIT queue         channel



            Fig. 2.                                                     HOSTA
                                                                        192.168.1.10

Notice from figure 2, that the programs use the Message Queue Interface (MQI), which is the api to MQ. The programs use the func
to place and retreive messages from a queue.

Not always is it needed to define a remote queue. In case of "MQ clustering", things will be a bit different. If we were indeed dealing
a Host located in a certain branch, will just use a "cluster queue", and no further remote queue definitions are necessary. This Host
the messages to the correct receiver. It would be absurd if you would need to define endlessly all remote queue definitions, in a pos
So, figure 2 actually scetch a system of two MQ servers that can communicate using the messaging infrastructure. Such a system c
However, you more likely will encounter MQ networks with clusters, Servers, and MQ clients.

But it's nice to give you an impression on how a 2 Node system, as shown in figure 2, could be setup. This is what we will do in chap


2. Example of a Quick and Dirty Setup of a 2 Node messaging system.
Let's try to setup a system as shown in figure 2. The setup presented here, only serves as a quick example on how to configure a si
We want to let Program B (on HostA) to send messages to Program C (on HostB).
Let's start with the configuration on HostB. In this example, we will work on unix (e.g. Solaris, Linux, AIX etc..) but it could just as we

Let's assume that "Websphere MQ" is fully installed on both systems, that is, HostA and HostB.

>>> On HostB:
Command                                                                                       Remark:
$ crtmqm -q venus.queue.manager                                                               create the queue manager "venus.queue.manager". You
$ strmqm                                                                                      start the queue manager
$ runmqsc                                                                                     This is a special tool, and you will enter a "prompt" which

             define qlocal (orange.queue)                                                     Define a local queue "orange.queue"
             define listener (listener1) trptype (tcp) control (qmgr) port (1414)             Define a listener which will listen on the default port 1414
             start listener (listener1)                                                       Now startup the listener.
             define channel (first.channel) chltype (rcvr) trptype (tcp)                      Define a receiver channel
             end                                                                              End the "runmqsc" session

>>> On HostA:
Command                                                                                       Remark:
$ crtmqm -q saturn.queue.manager                                                              create the queue manager identified by the name "saturn
$ strmqm                                                                                      start the queue manager
$ runmqsc                                                                                     This will enter a "prompt" which enables you to create qu
            define qlocal (transmit1.queue) usage (xmitq)                                     Define a transmit queue.
            define qremote (local.def.of.remote.queue) rname (orange.queue)                   Define a local definition of the remote queue
            rqmname ('venus.queue.manager') xmitq (transmit1.queue)                           Note how the names of the queue manager, and
            define channel (first.channel) chltype (sdr)                                      Define sender channel (default port 1414)
            conname ('HOSTB(1414)') xmitq (transmit1.queue) trptype (tcp)
            end

$ strmqm
$ runmqsc                                                                                     Maybe the mqm was down, so let's start it again.
             START CHANNEL(FIRST.CHANNEL)                                                     Startup the channel as well.

At this point HostA is ready to send messages to HOSTB.

Note 1:
Above, you see that the utility "runmqsc" is used. If you want to enter commands interactively, just start up this utility.
After typing your commands, you end your "runmqsc" session by entering the "end" command.

Note 2:
On most systems a GUI is available, "MQ Explorer", to setup all objects. This can be used if you don't want to use commandline operations.

Note 3:
If you would like to test to send a message from HostA to Host B, and you have Websphere MQ installed on both nodes, you can use a couple of
On the sender server, HostA, change into the /usr/mqm/samp/bin directory, which contains the sample programs.
To put a message on the local definition of the remote queue (which in turn specifies the name of the remote queue),
use the following command:

./amqsput LOCAL.DEF.OF.REMOTE.QUEUE

You will see the following messages:

Sample amqsput0 start
target queue is LOCAL.DEF.OF.REMOTE.QUEUE

Type some message text on one or more lines, followed by a blank line. You will see the following message:
Sample amqsput0 end

Your message is now on the queue and the command prompt is displayed again.

On the receiver server, HostB, change into the /usr/mqm/samp/bin directory, which contains the sample programs.
To get the message from the queue at the receiver, enter the following command:

./amqsget ORANGE.QUEUE

The sample program starts, and your message is displayed. After a pause, the sample ends and the command prompt is displayed again.




3. More on MQ objects and terminology:
3.1 Message format.
What is actually the structure of a MQ message?

Fig. 3
         MESSAGE HEADER (MQMH)


         DATA (payload).
         This can be txt, an XML document,
         or binary, or a SQL statement, a
         command etc.., or anything that the
         programs want to exchange.




Message DATA:
First, take a look at the possible "payload" of the message. In other words: what constitutes the message data? This is really up to t
information between them. So the data could be txt, an XML document, binary, a command, …., or whatever.
The messaging infrastructure, the MQ Network, does not need to know and interpreted the message data. That's up to the program

Message DESCRIPTOR, or Message HEADER:
The descriptor contains control information like:
- the message ID
 -message type
- persistant or non persistant message
- expiry time
- priority
- correlation
- name of the reply queue
- segmenting information (if a message get's split up)

It's possible that a message is split up in fragments, and gets re-assembled at the destination. This could be done because of sizing

You might distinguish several types of messages, depending on how applications react to a message:

1. Datagram:               Is a message containing information for which no response is required.
2. Request:                Is a message for which a reply is requested.
3. Reply:                  Is a reply to a request
4. Report                  Can be an acknowledge of an arrival, or an error message.

Another way to distinguish messages, is wether they are persistant or non-persistant.
Persistant messages are guaranteed to be delivered, even after system crashes. They will be additionally logged to some logging d

3.2 What is a queue?

In some Message Qeueuing systems, a queue is a "memory mapped file". It's an object residing in memory, designed to store mess
So, in that case, it's not a storage object on disk. But, in most MQ systems, you will find specific ".q" "files" (or sometimes queuing d
meant to temporarily store messages.
Also, in some implementations, a queue is even a (hidden) "table" in an associated database system.

Anyway, everybody would like the storage of messages to "survive" a system crash. So, you need a form of persistent storage.
(If you would scan the filesystem, you might find several ".q" files, representing the queues).

Queues are under the control of a queue manager.

In Websphere MQ, there are several types of queue's. The type of queue we have seen sofar, might be called an local (message) q
Here is a (incomplete) list of the main types of queue's:

local queue                             real queue used to store messages
remote queue                            definition describing a target's local queue.
transmission queue (xmit)               local queue used to store messages which are ready to be put on a sending channel
initiation queue                   special purpose local queue
dynamic queue                      local queue that can be created on the fly
alias queue                        refers to a queue using a other name. It's only a definition, pointing to the real queue.
repository queue                   holds the repository for a cluster
reply-to-queue                     the queue name in a request, where the target is supposed to send a response to.
dead-letter queue                  a queue manager uses this queue for messages which cannot be handled further
cluster queue                      a local queue known by all queue managers in the cluster

A queue manager, manage it's local queues. A remote queue is managed by a remote queue manager.
A (local) remote queue definition, corresponds to a target's local queue.
A transmission queue is used for communication with a remote queue manager. It is the last step before placing a message on a se
The remote queue definition is associated with a transmission queue.
You do not need a remote queue definition for a cluster queue.

A "dead-letter queue" is used by a queue manager, if for some reason a message cannot be delivered or handled.
One reason could be that the destination queue does not exists, or that a destination queue is full, or that a message is too large etc

3.3 Queue Manager.

The main job of the queue manager is to manage queues and the messages in those queues.
It also provide for the MQI interface that applications use to communicate with MQ (such as MQGET).
Queue managers communicate with other queue managers, using a structure called a "channel", which is a definition using network

3.4 Queue Manager Cluster.

It's possible to "join" queue managers together in clusters. Those queue managers can run on different system, using different platfo
They share a repository that contain information about all queue managers and queue's in the cluster.
The queue managers use special cluster channels to exchange information.

3.5 Review of 2 Node communication.

This is what we have seen in chapters 1 and 2. Let's take a look again what happens in this situation.

Fig. 4.




The Sender has defined a "remote queue" definition (not a real queue but only a representation of a target's local queue), along with
This remote queue definition, corresponds to the target's local queue. The MCA on the Sender's side, puts the message on the "sen
"unidirectional", that is: for two-way communication, a sender channel and a receiving channel must be established.
At the target, the listener "listens" on incoming requests (a message) and signals the MCA to put the message in the target's local q
Although figure 4 does not add much more information, as to what you can view in figure 2, it's always nice to have a few "perspecti

3.6 Channel types.

- Messaging channels:
When messages flow from one server to another server, there exists a channel between the queue managers on those hosts.
Let's call those type of channels, the "normal" messaging channels. On both sides, a MCA is involved in placing or retrieving the me
There must be a sending channel on HostA and a receiving channel on HostB. If you want two-way messaging, you need to define
on both Hosts.
In chapter 2, we have setup a simple 2 Node system. Note how the sending channel, named "first.channel" on HostA, corresponds
on HostB, also named "first.channel".
If you also want to have the situation where HostB can send to HostA, you have to create another "pair" of channels, say, a receivin
and a sending channel named "second.channel" on HostB.
Also, every receiving channel needs a listener as well.

- MQI channel.
A "light weight MQ client", only needs a Message Queueing Interface (MQI) channel, to the Server that's hosting the queue manage
The clients just uses the api provided by the client software.
Normally, true clients use the queue manager on a Server. They don't have a local queue manager.
So, a MQI channel connects a client to a queue manager on a Server.
The api offers functions to connect to a queue manager on a Server, for example the following api calls are available:

MQCONN                 Connect to a queue manager on a Server
MQDISC                 Disconnect from a queue manager
MQOPEN                 Open a specific queue
etc..

- Cluster channels (cluster-receiver and cluster-sender channels).
Is used by clustered queue managers to exchange information.

3.7 Special queue: initiation queue.

Although you haven't seen an "initiation queue" in the figures presented up to now, an "initiation" queue is implictely present at any q
It is used to store triggering messages. Such a triggering message, will "put something in motion".
Even in "normal" message processing, it is used. Suppose a message is put in a transmission queue. Now the system needs to put
on a sending channel. Even in this case, a trigger message in the initiation queue, was the cause that the system reacted to this eve
message was placed on the channel.
More specifically, a component called the "channel initiator", reads a trigger message in the initiazion queue, and knows that a me
It notifies the MCA which will handle the message further.

There are other components that react to trigger messages in initiazion queues. On a receiving Node, the "trigger monitor"
may notify an application, if a message has arrived in a destination queue.

Why didn't we need to create or start a channel initiator in chapter 2 ? This is because the system (on most platforms) will automatic


3.8 Another view on 2 Node (Server) communication, and this time with respect to triggering events.

The information you have seen in figures 2 and 4 is good, but now we show the flow of events from another perspective.
We want to see how a new message in de xmit queue will "trigger" the channel initiator, which on it's turn will notify the local MCA
to put the message on the sending channel.
On the receiving node, once a message has entered a local queue, a trigger monitor may notify an application, which will start proce
So from an "event based perspective" we might view the messaging infrastructure as shown in figure 5:

                                               HOST A
           Program A
                       MQPUT
           MQI




                       Remote queue definition "Q1"



                          channel initiation
                                  queue
                                                     Channel
                                                     Initiator
                                                   Initiator
                                     triggers

                                                         starts
                      XMIT
                      queue                        MCA


                                                         starts

                                                     snd Channel



           Fig 5.



3.9 MQ Processes.

Suppose you are working on a Unix machine where MQ is installed. You might like to know which processes belong to MQ, and wha
On Unix, you can see a list of processes with the "ps -ef" command, which you can "grep" (search/filter) on mq processes.
Suppose the MQ processes are running under the credentials (the account that owns MQ) of mqm. Then you could try the following

$ ps -ef | grep mqm

which might produce a process list similar to:

mqzmur0 -m UQASWG0
amqzxma0 -m UQASWG0
amqzmuc0 -m UQASWG0
amqzlaa0 -mUQASWG0 -fip0
/usr/mqm/bin/amqzmgr0 -m UQASWG0
/usr/mqm/bin/amqrrmfa -m UQASWG0 -t2332800 -s2592000 -p2592000 -g5184000 -c3600
/usr/mqm/bin/runmqlsr -t tcp -p 21414 -i starboss -m UQASWG0
/usr/mqm/bin/amqzdmaa -m UQASWG0
/usr/mqm/bin/amqpcsea UQASWG0
/usr/mqm/bin/amqrmppa -m UQASWG0
/usr/mqm/bin/amqzfuma -m UQASWG0
/usr/mqm/bin/runmqchi -m UQASWG0 -r

All those processes have some function within the framework of MQ. Following is a limited list of processes and their main purpose

AIX:
ProcName            Process Function
amqhasmx            logger
amqharmx            log formatter,used only if the queue manager has linear logging selected
amqzllp0            checkpoint processor
amqzlaa0            queue manager agent(s)
amqzxma0            processing controller
runmqsc             MQ Command interface
amqpcsea            PCF command processor
amqcrsta            Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SEN
amqcrs6a            Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,S
runmqchl            Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
runmqlsr            listener process
runmqchi            channel initiator


iSeries:
ProcName            Process Function
AMQHIXK4            Storage Manager (Housekeeper)
AMQMCPRA            Data Store (Object Cache)
AMQCLMAA            Listener
AMQALMP4            Check Point Process
AMQRMCLA            Sender channel
AMQPCSVA            PCF command processor
AMQRIMNA            Channel initiator (trigger monitor to start channel)
AMQIQES4            Quiesce (forces user logoffs - for upgrades)
AMQIQEJ4            Quiesce (without user logoffs - for daily use if desired)
AMQCRSTA            Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SEN
AMQCRS6A            Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUS


SOLARIS
ProcName            Process Function
amqhasmx            logger
amqharmx            log formatter, used only if the queue manager has linear logging selected
amqzllp0            checkpoint processor
amqzlaa0            queue manager agents
amqzxma0            processing controller
amqcrsta            Any remotely started channel over TCP/IP - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SEN
amqcrs6a            Any remotely started channel over LU62/SNA - Could be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,S
runmqchl            Any locally started channel over any protocol - Could be SENDER,SERVER,CLUSSDR,REQUESTER
runmqlsr            listener process
runmqchi            channel initiator
runmqsc             MQ Command interface
amqpcsea            PCF command processor




4. Clustered MQ:
In a "clustered" QM network, the setup will be different from what we have seen in "distributed queueing", as shown in chapters 1,2,

4.1 Overview clustered MQ

In general terms, your MQ network, is implemented as:

- distributed queueing:
This means that if a queue manager wants to send messages to another queue manager, it must have defined:
. A transmission queue
. A channel (or pair of channels) to the remote queue manager
. A remote queue definition for every queue it wants to send messages to.

In fact, all that we have seen above, deals with distributed queueing.

- cluster (clustered queue managers)

If you would group queue managers into a cluster, the queue managers can make the queues that they host , available to every oth
Any queue manager can send a message to any other queue manager in the same cluster, without the need for explicit channel def
or transmission queues for each destination.

Some queue managers will hold the "repository" of the QM network. That is the information describing all queue managers and qu
These queue managers are called "repository queue managers". The other queue managers are called "cluster queues"
If you make or alter a queue on some queue manager, those changes will be send to the repository.
Normally, only two repository queue managers are defined, and which will hold a full repository.
The other (regular) queue managers in the network, will frequently query the repository, and thus themselves will build up a partial li
These queue managers have created subsets of information, about other queue managers and queues, of which they have exchan


4.2 Channels, and xmit queue, in a clustered MQ network.

In a cluster, the queue managers will use special channels to communicate.

- A "cluster-receiver channel" definition, CLUSRCVR, defines the receiving end of a channel on which a cluster queue manager c
from other queue managers in the cluster. It can also carry information about the cluster, that is, information from the repository.

- A "cluster-sender channel" definition, CLUSSDR, defines the sending end of a channel on which a cluster queue manager can s
to other queue managers. It is also used to send cluster information to the full repositories, for example, when a queue is added or r

In addition, every queue manager in the cluster, has only one cluster transmission queue (xmit queue), called
SYSTEM.CLUSTER.TRANSMIT.QUEUE
which transmits all messages from the queue manager to any other queue manager that is in the same cluster.

All queue managers in the cluster "work together" in such a way, that any change in a configuration (like addition of a queue) is sen
Also, any queue manager can retrieve information of any other cluster member.

Here are a few very important (and amazing) remarks about queue managers in a cluster, with respect to the channels.
1. When you first define the cluster-receiver channel at a queue manager, that information is also stored in the repository, so all me
2. A cluster queue manager needs a cluster-sender channel to make the contact to the repository.
3. Whenever remote queue manager "B" in the cluster, want to communicate to queue manager "A" in the cluster, "B" can automat
   definitions for the cluster-sender end of the channel as needed . The Administrator is not involved in this process, since it's an au

Especially, if you let remark 3 sink in, you will realize how much a cluster will ease administration in a large MQ network.
There is no need for creating remote queue definitions and associated xmit queues.
Ofcourse, any queue manager may hold several local queues, which still need to be defined. This is not different from a distributed

Any MQ client can connect to a queue manager that is part of the cluster. The cluster will sort out, how to get the messages to the d


4.3 Example setup of a small cluster.

Let's try to setup the simplest possible cluster, consisting of just 2 queue managers, as shown in figure 6.
Only the queue manager "LONDON", will host one queue, which is called "INVENTQ".



                                   TO.LONDON

                                                           TO.AMSTERDAM
           Fig. 6.


                                  listenerA                                                listenerB


                                   queue                                                      queue manager
                                   manager                                                    AMSTERDAM
                                   LONDON




                                   INVENTQ



                       HOSTA                                                      HOSTB

Before we type the commands needed, let's first think about the items we need.

- Let's suppose thate HOSTA is located in London, while HOSTB is located in Amsterdam.

- We have two queue managers here, one called LONDON, the other is called AMSTERDAM. Remember, we can name objects as
  So, it will be quite descriptive if we name our queue managers accordingly.

- Each queue manager will need a cluster-receiver channel (CLUSRCVR), and a cluster-sender (CLUSSDR) channel.
 In this case, it's wise to call the channels "TO.LONDON" and "TO.AMSTERDAM" because that would be very descriptive. Remem
 choosing objectnames, just as we did in chapter 2, where we choose names like "FIRST.CHANNEL".

- Also, for "receiving" channels to work, a listener must be defined.

- Also, a cluster needs a name which identifies the cluster on the network, and that will also make sure, that queue managers will kn
  of that cluster. Let's assume that our applications have to do with inventory, so let's call our cluster INVENTORY.

- As you have seen above, a cluster also need queue managers which will hold the full repository, even in as system as small as in
  So, we decide to let both our queue managers to hold the full repository.

We already have seen some commandline examples in chapter 2, when setting up a simple 2 Node system.
This time, we need a couple of other MQSC commands (MQSeries Commands) as well as some commands you will recognize from

So, the commands that the Administrator has to produce, in order to create this small cluster, could be of the following form:

On HOSTA:

Command:                                                                                     Remark:

ALTER QMGR REPOS('INVENTORY')                                                                With ALTER QMGR you can change an

DEFINE QLOCAL('INVENTQ') CLUSTER('INVENTORY')                                                Define a local queue

DEFINE CHANNEL('TO.LONDON') CHLTYPE(CLUSRCVR) +                                              Define the cluster-reciever channel
   TRPTYPE(TCP) +
   CONNAME('HOSTA(14141)') +
   CLUSTER('INVENTORY')

DEFINE CHANNEL('TO.AMSTERDAM') CHLTYPE(CLUSSDR) +                                            Define the cluster-sender channel
   TRPTYPE(TCP) +
   CONNAME('HOSTB(14142)') +
   CLUSTER('INVENTORY')

DEFINE LISTENER('LISTENERA') +                                                               Define the listener
   TRPTYPE(TCP) +
   PORT(14141)

on HOSTB:

ALTER QMGR REPOS('INVENTORY')

DEFINE CHANNEL('TO.AMSTERDAM') CHLTYPE(CLUSRCVR) +
   TRPTYPE(TCP) +
   CONNAME('HOSTB(14142)') +
   CLUSTER('INVENTORY')

DEFINE CHANNEL('TO.LONDON') CHLTYPE(CLUSSDR) +
   TRPTYPE(TCP) +
   CONNAME('HOSTA(14141)') +
   CLUSTER('INVENTORY')

DEFINE LISTENER('LISTENERB') +
   TRPTYPE(TCP) +
   PORT(14142)
Found a bug? Found incorrect info?
Please report to:
albertvandersel@zonnet.nl
Thanks !
 ing, and one of the most important implementations of MQ, which is Websphere MQ.
 also very incomplete .




 first talk about a simple "distributing system", like a 2 node system.

 ly from a distributed system.
e, with bigger MQ networks, implementing a cluster is advisable.




which can be used as a means for (indirect) Program to Program communication.

of program. For example, maybe you use an SQL client program, which you use to talk to a remote Database.
 l send the results of your query back to the client program.
antaneously to your requests.
 and responses" is almost (or should be) instantaneously.

sary to relax tightly coupled communication, by the introduction of an intermediary component.
 rograms is not direct, in the sense that both partners do not need to response right away.

even be down. And once up, it can processes the messages from the queue.
ogram A can forward (put) it's message in the right queue, and forget about it.

es flows around, and whenever a communication partner is ready for it, it can inspect it's queue (postbox),

 both Program A and Program B "knows" how to use, and which offers functions like
astructure is quite easy to grasp.


                       Program B


                       GET from Q1




 ms communicate by writing and retrieving application specific data (that is, messages)



m is implemented, it is like this:
he messages in those queues.
ate a "queue manager", you will use


 ough MQ, they will use a local queue.
eir own queue managers and queues.
he other. The queue managers will use "channels", that is a
 when you define a channel, you will also define network characteristics, like
h the receiving queue manager will listen.
 eters, all put together in one "set", known by the name of the channel.
receiving channel must be set up, as well as a "listener" object.
ge Channel Agent", that receiving messages must be placed in the receiving queue.
r placing the message on the sender channel.


 gram B. At Host A, there might exists local queues.
he queue at location B. That's why a "remote queue" at A is defined, which

 They define the destination queue.

mplicitely, it will be associated with a XMIT queue, that is, a "transmission" queue.


owned by a specific queue manager. All messages destined for that queue manager

ueue, which is the target's local queue.



                                                                          HOSTB
                                                                                            program C


                                                                                    MQI

                                                   other channel                     queue
                        network
                                                   receiver channel "X"              "orange"
                                                                          MCA       queue manager
                                                                                    "venus"


                                                                         HOSTB
                                                                         202.115.39.20



which is the api to MQ. The programs use the functions MQPUT and MQGET


ngs will be a bit different. If we were indeed dealing with a large MQ network,
emote queue definitions are necessary. This Host can leave it up to the MQ network, to send
ne endlessly all remote queue definitions, in a possible ever changing network.
ing the messaging infrastructure. Such a system could be used in reality.


e 2, could be setup. This is what we will do in chapter 2.




erves as a quick example on how to configure a simple, but working concept.

e.g. Solaris, Linux, AIX etc..) but it could just as well be any other platform
 reate the queue manager "venus.queue.manager". You can call the manager whatever you like, within the boundaries of naming conventions of MQ.

 his is a special tool, and you will enter a "prompt" which enables you to create queues, channels and listeners.

Define a local queue "orange.queue"
Define a listener which will listen on the default port 1414

Define a receiver channel
 nd the "runmqsc" session



 reate the queue manager identified by the name "saturn.queue.manager".

 his will enter a "prompt" which enables you to create queues, channels and listeners.

Define a local definition of the remote queue
Note how the names of the queue manager, and queue, as used at HostB are used.
Define sender channel (default port 1414)




Maybe the mqm was down, so let's start it again.
 tartup the channel as well.




 ely, just start up this utility.



 if you don't want to use commandline operations.


e MQ installed on both nodes, you can use a couple of test programs as follows:
ns the sample programs.
ame of the remote queue),




 ins the sample programs.




ds and the command prompt is displayed again.
 onstitutes the message data? This is really up to the programs that want to exchange
 command, …., or whatever.
preted the message data. That's up to the programs.




e destination. This could be done because of sizing requirements.




 They will be additionally logged to some logging directory, or some journal.



 object residing in memory, designed to store messages.
 ill find specific ".q" "files" (or sometimes queuing directories),



sh. So, you need a form of persistent storage.




e seen sofar, might be called an local (message) queue.




 ready to be put on a sending channel
a definition, pointing to the real queue.

 is supposed to send a response to.
es which cannot be handled further


mote queue manager.

t is the last step before placing a message on a sending channel.



e cannot be delivered or handled.
 ion queue is full, or that a message is too large etc..




led a "channel", which is a definition using network services.



 s can run on different system, using different platforms.




epresentation of a target's local queue), along with a transmission queue.
n the Sender's side, puts the message on the "sender" channel. Such a channel is normally
ving channel must be established.
the MCA to put the message in the target's local queue.
n figure 2, it's always nice to have a few "perspectives" on how something works.
etween the queue managers on those hosts.
s, a MCA is involved in placing or retrieving the messages on or from the channel.
you want two-way messaging, you need to define the other type of channels

nel, named "first.channel" on HostA, corresponds to the receiving channel

o create another "pair" of channels, say, a receiving channel named "second.channel" on HostA,




nel, to the Server that's hosting the queue manager.



 the following api calls are available:




w, an "initiation" queue is implictely present at any queue manager's subsystem.

transmission queue. Now the system needs to put the message
, was the cause that the system reacted to this event, and the

ssage in the initiazion queue, and knows that a message entered the xmit queue.


On a receiving Node, the "trigger monitor"


ause the system (on most platforms) will automatically create and start the initiator with the strmqm command.


ith respect to triggering events.

 ow of events from another perspective.
nitiator, which on it's turn will notify the local MCA

itor may notify an application, which will start processing the message.
e as shown in figure 5:

                                      HOST B



                                                                                                      trigger
                                                                     Program B

                                                                                   MQGET

                                                                      MQI



                                                                                     triggers                    Trigger
                                    rcvr Channel
                                                                                                                 Monitor
                                            starts                 local queue Q1   initiation queue

                                     MCA


                                            starts

                                    Listener




e to know which processes belong to MQ, and what their main purpose is.
n "grep" (search/filter) on mq processes.
wns MQ) of mqm. Then you could try the following:




a limited list of processes and their main purpose on some platforms:




inear logging selected




e RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
 be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
uld be SENDER,SERVER,CLUSSDR,REQUESTER
e RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
 be RECEIVER,REQUESTER,CLUS




linear logging selected



e RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
 be RECEIVER,REQUESTER,CLUSRCVR,SVRCONN,SENDER,SERVER
uld be SENDER,SERVER,CLUSSDR,REQUESTER




n "distributed queueing", as shown in chapters 1,2, and 3.




manager, it must have defined:




 e the queues that they host , available to every other queue manager in the cluster.
me cluster, without the need for explicit channel definitions, remote queue definitions,


 nformation describing all queue managers and queues in the network.
eue managers are called "cluster queues"


sitory, and thus themselves will build up a partial list of the repository.
managers and queues, of which they have exchanges messages with.




 of a channel on which a cluster queue manager can receive messages
cluster, that is, information from the repository.

 channel on which a cluster queue manager can send messages
ositories, for example, when a queue is added or removed.

on queue (xmit queue), called

ger that is in the same cluster.

 in a configuration (like addition of a queue) is send to the repository.


a cluster, with respect to the channels.
 formation is also stored in the repository, so all members can be aware of that.

ueue manager "A" in the cluster, "B" can automatically create the corresponding
ator is not involved in this process, since it's an automatic feature.

e administration in a large MQ network.

be defined. This is not different from a distributed system.

ster will sort out, how to get the messages to the destination queue.




rs, as shown in figure 6.




           queue manager
           AMSTERDAM




MSTERDAM. Remember, we can name objects as we like.


cluster-sender (CLUSSDR) channel.
M" because that would be very descriptive. Remember, that we are relatively free in




at will also make sure, that queue managers will know that they are member
et's call our cluster INVENTORY.

he full repository, even in as system as small as in our example.


 p a simple 2 Node system.
as well as some commands you will recognize from chapter 2.

mall cluster, could be of the following form:




           With ALTER QMGR you can change an existing queue manager

           Define a local queue

           Define the cluster-reciever channel




           Define the cluster-sender channel




           Define the listener
ries of naming conventions of MQ.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:43
posted:8/28/2011
language:English
pages:47