Industry example of using WebSphere MQ V6 to build enterprise information bus

Introduction

IBM WebSphere MQ is currently the most widely used messaging middleware product, using Message Queuing, a communication method between applications that enables different applications to communicate by reading and writing and retrieving data (messages) in and out of the queue without directly facing the network's variable, System heterogeneity, data coordination and other problems and risks. WebSphere MQ also supports a simple publish/subscribe (publish/subscribe) Messaging mechanism with a unique broker agent in each queue Manager to handle all subscriptions and publications.

WebSphere MQ supports Cluster (clusters or clusters), a collection of multiple queue managers (QM), which can be distributed across different machines. The examples in this article use the above Queue and pub/sub two ways, and create an MQ Cluster to simplify the configuration of data transfer and the management of MQ objects, the reason for using MQ Cluster is based on the following features:

1 The data transmission channel between the queue managers in Cluster is automatically established, making the data transmission configuration simpler;

2 queues in the queue Manager can be specified as Cluster shared queues, visible to all queue managers in Cluster, and Cluster shared queues defined in different queue managers automatically implement load balancing for the queue;

3 a master-slave relationship can be specified between broker agents of different queue managers, so that tree-like pub/sub structures can be conveniently implemented in Cluster.

Once you have configured WebSphere MQ as needed, you can configure it and integrate those resources into your application. The following details how to configure WebSphere MQ based on the needs of this article instance, as well as was and application code, configuration details.

Instance Description

This is an example of an immigration clearance system (see Figure 1.1). This system consists of a central management Center (headquarter, hereinafter referred to as HQ) and multiple child control centers (controlling point, hereinafter referred to as CP). Each CP produces a large number of clearance data (move record, hereinafter referred to as MR), these clearance data need to be transferred to the HQ rollup; the monitoring list (Watch list, hereinafter referred to as WL) required by each CP in handling the clearance operation is not periodically addressed to each CP Distribute.

Fig. 1.1 System schematic One

This data transfer between CP and HQ is implemented using WebSphere MQ, and the HQ and each CP has its own Queue Manager (QM), which is configured to be in the same MQ Cluster. MR data transmission is a one-way point-to-point transfer of CP to HQ, and is implemented in this example with the Cluster Shared Queue (MR2HQ.Q) in the Queue Manager defined at the HQ end. The WL data is the HQ to each CP broadcast, this needs to adopt the Pub/sub mode. The instance is a queue manager that selects HQ to start the broker service, and then the queue manager for each CP also initiates the broker service and acts as the broker child node for HQ.

Fig. 1.2 System schematic Two

The WebSphere MQ self-contained broker service is used to support simple pub/sub functionality, and each queue Manager has a unique broker agent to handle subscriptions and publications for all topics. When broker proxies are enabled on a single queue manager, both the Publisher and subscriber of the topic directly access the same queue manager, on which multiple topics can be defined. A parent-child cascade can also be made between multiple queue managers, provided that a two-way send/receive channel and corresponding transmission queue are established, if two queue managers are in the same MQ Cluster. The effect of a parent-child cascade is that a child node becomes a subscription agent, and a subscription to a child node is represented as a subscription to the parent node. This creates a distributed, publish-and-subscribe tree structure in which topic messages posted on parent nodes can be consumed by subscribers on all of their child nodes. The advantage of this approach is that it eliminates the reliance on a single Broker service, as the example in this article is in this way, HQ1 is the parent node, and all the CP is a child node.

Figure 1.3 MQ Pub/sub schematic

The WebSphere MQ self-brought Broker service supports only simple pub/sub functionality and does not support cluster functionality. For example, the example of this article, only HQ1 as the parent node, the HQ1 and HQ2 Broker services can not be configured as a cluster parent node, child nodes can only specify a parent node, and can not configure multiple child nodes as a cluster child node. In a complex application environment, a more full-featured WebSphere message Broker can only be used when the WebSphere MQ self-contained Broker service does not meet the requirements.