\nQueuing<\/strong><\/p>\n
Queuing<\/em> is the mechanism by which messages are held until an application is ready to process them. Queuing allows you to:<\/p>\n A message queue<\/em>, known simply as a queue<\/em>, 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.<\/p>\n Queues reside in and are managed by a queue manager, <\/em>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.<\/p>\n Channels<\/strong><\/p>\n Channels<\/em> are communication links used by distributed applications. There are two categories of channels in MQSeries:<\/p>\n Triggering<\/strong><\/p>\n The queue manager defines certain conditions as trigger events<\/em>. 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<\/em>. 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.<\/p>\n The program that processes the initiation queue is called a trigger-monitor application<\/em>, 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).<\/p>\n If triggering is enabled for a queue, you can create a process-definition object<\/em> 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.<\/p>\n 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.<\/p>\n 2. Scenario<\/strong> The Index page is used by customers to place and track their orders. See Figure 1 below.<\/p>\n Figure 1. When you click Place Your Order<\/strong>, you are presented with an Order page as shown in Figure 2 below.<\/p>\n Figure 2. When you click Submit<\/strong>, 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.<\/p>\n Figure 3. To track an order, click Track Your Order<\/strong> on the main page, enter the order number, and click Submit<\/strong>. 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.<\/p>\n Figure 4. Figure 5 below shows a snapshot of the triggering event for App.OrderQ.<\/p>\n Figure 5. Click Place Your Order <\/strong>four more times and enter four more orders. Then click Track Your Order <\/strong>and enter any one of the order numbers. You should see the message, as shown in Figure 6 below.<\/p>\n Figure 6. This completes the application.<\/p>\n 3. Setting up queues, channels, triggers, and process definitions for the queues in our application<\/strong><\/p>\n 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.<\/p>\n Figure 7.\n
\n
\nTo 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.<\/p>\n![\"image01\"](\"http:\/\/naveenbalani.com\/wp-content\/uploads\/2010\/11\/image01.jpg\" "\\"image01\\"")
<\/a>
\n<\/strong><\/p>\n<\/a>
\n<\/strong><\/p>\n<\/a>
\n<\/strong><\/p>\n<\/a>
\n<\/strong><\/p>\n<\/a>
\n<\/strong><\/p>\n<\/a>
\n<\/strong><\/p>\n\n
<\/a>
\n<\/strong><\/p>\n