In this blog , I would provide an introduction to MQSeries messaging and triggering concepts.
1. Basic MQSeries messaging concepts
Queuing
Queuing is the mechanism by which messages are held until an application is ready to process them. Queuing allows you to:
- Communicate between programs (which may be running in different environments) without having to write communication code.
- Select the order in which a program processes messages.
- Balance loads by arranging for more than one program to service a queue when the number of messages exceeds a threshold.
A message queue, known simply as a queue, is a named destination to which messages can be sent. Messages accumulate on a queue until they are retrieved by a program that services that queue. The physical nature of a queue depends on the operating system on which the queue manager is running.
Queues reside in and are managed by a queue manager, which is a system program that provides queuing services to applications. It provides an application programming interface so that programs can put messages on queues and get messages from them.
Channels
Channels are communication links used by distributed applications. There are two categories of channels in MQSeries:
- Message channels, which are unidirectional, and transfer messages from one queue manager to another.
- MQI channels, which are bi-directional, and transfer calls from an MQSeries client to a queue manager, and responses from a queue manager to an MQSeries client.
Triggering
The queue manager defines certain conditions as trigger events. If triggering is enabled for a queue and a trigger event occurs, the queue manager sends a trigger message to a queue called an initiation queue. The presence of the trigger message on the initiation queue indicates that a trigger event has occurred. Trigger messages generated by the queue manager are not persistent.
The program that processes the initiation queue is called a trigger-monitor application, and its function is to read the trigger message and take appropriate action based on the information in the trigger message. Normally this action is to start some other application to process the queue that generated the trigger message. From the point of view of the queue manager, there is nothing special about the trigger-monitor application — it is simply another application that reads messages from a queue (the initiation queue).
If triggering is enabled for a queue, you can create a process-definition object associated with it. This object contains information about the application that processes the message that caused the trigger event. If the process definition object is created, the queue manager extracts this information and places it in the trigger message, for use by the trigger-monitor application. The name of the process definition associated with a queue is given by the ProcessName local-queue attribute. Each queue can specify a different process definition, or several queues can share the same process definition.
To a queue manager, a trigger monitor is like any other application that serves a queue, except that it serves only initiation queues. A trigger monitor is usually a continuously running program. When a trigger message arrives on an initiation queue, the trigger monitor retrieves that message. It uses information in the message to issue a command to start the application that processes the messages on the application queue.
2. Scenario
To get the concepts clear, we will build a sample application that takes orders from customers and then, when the number of orders reaches a maximum value, the system processes and dispatches the order. Users can track their orders using a link on the home page. Using MQSeries as the middleware, the application will store orders on a queue (App.OrderQ), then trigger a predefined event (a Java program) to process the orders and update the process queue (App.ProcessQ), which enables customers to track their orders. This kind of application can be used for asynchronous processing.
The Index page is used by customers to place and track their orders. See Figure 1 below.
Figure 1.
When you click Place Your Order, you are presented with an Order page as shown in Figure 2 below.
Figure 2.
When you click Submit, the order servlet populates the order object (order bean), places it on the order queue, and generates an order number, which is displayed in Figure 3 below. The order number is used to track the order.
Figure 3.
To track an order, click Track Your Order on the main page, enter the order number, and click Submit. If the order placed on the order queue has not yet been triggered, you will receive the message shown in Figure 4 below. This is because the application specifies a Trigger Type of Depth and Trigger Depth of five in the properties associated with the App.Orderq queue, and therefore the trigger will not fire and update App.ProcessQ queue until there are five messages in the order queue.
Figure 4.
Figure 5 below shows a snapshot of the triggering event for App.OrderQ.
Figure 5.
Click Place Your Order four more times and enter four more orders. Then click Track Your Order and enter any one of the order numbers. You should see the message, as shown in Figure 6 below.
Figure 6.
This completes the application.
3. Setting up queues, channels, triggers, and process definitions for the queues in our application
You could set up queues using the MQSeries Explorer, which you can access via the MQSeries Program Menu or through MQ Commands. I have provided a setup file for our application.
- Extract the zip file mqapp.zip to a temporary location and run mqsetup.bat to set up queues, channels, triggers, and process definitions for our application.
- Add the path where MQSeries in installed (C:\MQSeries\bin) to your environment variable.
- Use MQSeries Explorer to see the queues and channels that have been created. You will see that a queue manager named Application.QManager has been created along with four queues: App.ErrorQ,App.InitiateQ, App.OrderQ, and App.ProcessQ, as shown in Figure 7 below.
Figure 7.
Expand the Advanced option of Application.QManager and click Channels to explore APP.Channel. Clients communicate to MQSeries through this channel. Click Process Definitions to see that the entry PERFORM.PROCESS has been created. Click PERFORM.PROCESS and select Properties and the window below opens. The Application Identifier specifies the Java program that we want to execute when the trigger fires. This process definition is associated with App.OrderQ.
Figure 8.
Click on Queues and select App.OrderQ. Click on it, select Properties, and then select the Triggering menu. The entries are described below.
- Trigger Control: On — Triggering is enabled.
- Trigger Type: Depth — Trigger will fire when Trigger Depth is reached.
- Trigger Depth: 5 — Trigger will fire when five messages are placed on the queue.
- Initiation Queue Name — Queue for temporarily holding the queued messages as described above under Triggering.
- Process Name: PERFORM.PROCESS — Process definition to execute when the trigger is fired.
We have now set up the required queues, channels, and process definitions for our queue. In this application, the trigger fires only once when the trigger depth is reached. The trigger control is then automatically set to Off. The next step is to set up the Web interface for our application. In my next blog, we would go through setting up web interface for the application. This Tutorial of mine was first published by IBM developerWorks. All Rights reserved.
