Introduction
In this tutorial, we go over some basic MQ concepts while demonstrating how IBM MQ sends message from one queue manager to another queue manager without clustering. Communication between different queue managers can happen over different means like distributed queuing or through queue manager clustering.
Here in this example, we will create two queue managers, create two queues (one in each queue manager). We’ll show how we can send a message from the source queue in one queue manager to target queue in another queue manager (without clustering) using distributed queuing mechanism.
Scope
We’ll demonstrate the concepts in two parts series. In this first part, we’ll go over the concepts and in the second part, we’ll actually create these components and demonstrate the messages moving from source queue manager to the target queue manager.
Required Objects
In order to achieve this use case of distributed queuing, we need following objects to be created –
- Queue Managers:In Websphere MQ system, a queue manager is the main fundamental object that owns/manages almost every other component or object. It manages storage of data in a queue. It also co-ordinates with reader or writer applications that connects and interacts with queues.In this example, we’ll create following two queue managers –
- QM1; Sender Queue Manager
- QM2; Receiver Queue Manager
- Local Queue: A local queue physically stores a message. It’s the only component in IBM MQ system that can store messages. Here in this example we’ll create QL.TARGETQ in QM2. This queue will hold the messages sent from QM1.
- Remote Queue: We’ll create a remote queue QR.TARGETQ in the sending queue manager QM1. A remote queue in itself doesn’t hold any data of its own. It effectively describes a queue on another queue manager. As remote queue does not have capacity to store any data of its own, applications can’t read from a remote queue either. In this example QR.TARGETQ is a remote queue that mirorrs QL.TARGETQ in the target queue manager. Our goal is to send a message to QL.TARGETQ from QM1 using QR.TARGETQ.
- Transmission Queue: Transmission queue is actually a local queue. Only different attribute that it has than a normal local queue is –> USAGE(XMITQ). Transmission queues are abstracted from the application. When an application opens a connection to the remote queue to put a message; the queue manager, behind the scene, creates a reference to the transmission queue or XMITQ. When the application puts a message in the remote queue, queue manager actually puts the message to the XMITQ. In this example, we will create a XMITQ named QX.TARGET.
- Channel: Channels are of two types predominantly. Here, we will talk about message channel. Henceforth, in this article channels and messages channels are used interchangeably. A message channel connects two queue manger through message channel agents. Message channels are unidirectional. You can’t use a single channel to send message both ways. There are several sub types of messages channel. Here we’ll look at two of them
- SENDER channel – A sender channel is one that retrieves the messages from the XMITQ/Transmission Queue and sends across the other system; in our case, we will create sender channel QM1.TO.QM2 to send message from QM1 to QM2.
- RECEIVER channel – A RECEIVER channel is one that receives the message sent by SENDER channel and puts to the target queue. In our case we’ll create a receiver channel QM1.TO.QM2 that will receive that message put the target local queue.
NOTE:- The sender and receiver channel must have the same name.
- Message Channel Agent (MCA): Message channel agent is a program that manages the sending and receiving of the messages by the channels.
- Channel Initiator: Transmission of messages are done through channels and MCA takes care of putting the message into or reading the message from the channel.
- But who notifies/starts the MCA? Answer:- It is Channel Initiator that starts the MCA.
- There may be a question in your mind on who/what triggers Channel Initiator? Answer:- IBM MQ has a system generated queue called initiation queue. When an application puts a messages into the (as in this example) remote queue, the queue manager actually puts the message the associated transmission queue. At the same time the queue manager also puts another message into channel initiation queue. This queue is monitored by channel initiator.
- How about in the receiving end; how the channel initiator is started in target Queue Manager? Answer:- In MQ, there is a concept called listener (Explained below). Whenever a queue manager is started, in general, the listener will also start and listen to the port assigned to the queue manager. It starts the the receiving MCA when an inbound requests is received. The receiving MCA receives the message from receiving channel and puts it into the target queue.
- Listener: In a Queue Manager, a listener listens for inbound communication request on a protocol like TCP and starts MCA whenever an inbound request is received.
So far we have spoken about a lot of concepts and communication links. Got confused as to how all these subsystems and components altogether? Let’s look at the below distributed queuing architecture.
Queuing Architecture (Sequence Diagram)
IBM MQ Distributed Queueing QM to QM connection
