应用WebSphere MQ V6 来构建企业信息总线的行业示例.doc

　　应用WebSphere MQ V6 来构建企业信息总线的行业示例 　　引言 　　IBM Q 是目前应用最多的消息中间件产品， 它采用了消息队列（Message Queue）这种应用程序间的通信方法， 让不同的应用程序通过读写和检索出入队列中的数据（消息）来通信， 而无需直接面对网络易变、系统异构、数据协同等各种问题和风险。 Q 同时也支持简单的 Publish/Subscribe（发布 / 订阅）消息传递机制， 每个队列管理器中有唯一的 Broker 代理来处理所有的订阅和发布。 　　Q 支持 Cluster（簇或集群），即多个队列管理器（Queue Manager 以下简称 QM） 的集合，这些队列管理器可以分布在不同的机器上。 本文中的例子采用了上述的 Queue 和 Pub/Sub 两种方式， 并创建了一个 MQ Cluster 来简化数据传输的配置和 MQ 对象的管理， 采用 MQ Cluster 的理由基于其如下特点： 　　1) Cluster 中的队列管理器之间的数据传输通道是自动建立的， 使得数据传输配置变得更简单； 　　2) 队列管理器中的队列可以被指定为 Cluster 共享队列， 对 Cluster 中的所有的队列管理器都是可见的； 不同队列管理器中定义的同名 Cluster 共享队列自动实现针对该队列的传输负载均衡； 　　3) 不同队列管理器的 Broker 代理之间可以指定主从关系， 这样就可以在 Cluster 内很方便地实现树状的 Pub/Sub 结构。 　　在根据需要配置好 Q 之后， 就可以在 Q， 以及 ove Record，以下简称 MR）, 这些清关数据需要被传送到 HQ 上汇总；各个 CP 在处理清关操作的时候需要的监控列表 （Q 来实现， HQ 和每个 CP 都有自己的队列管理器（QM），这些 QM 被配置为同处于一个 MQ Cluster 中。 MR 的数据传输是 CP 到 HQ 单向点到点的数据传输， 在本例中用定义在 HQ 端的队列管理器中的 Cluster 共享队列（MR2HQ.Q）来实现。 Q 自带的 Broker 服务用于支持简单的 Pub/Sub 功能， 每个队列管理器中有唯一的 Broker 代理来处理所有主题的订阅和发布。 在单一队列管理器上启用 Broker 代理时， 主题的发布者和订阅者都直接访问这同一个队列管理器，在其上可以定义多个主题。 多个队列管理器之间也可以做父子级联， 前提是要建立双向的发送 / 接收通道以及相应的传输队列， 当然如果两个队列管理器都在同一个 MQ Cluster 里也行。 父子级联的效果就是子节点成为订阅代理， 订阅者向子节点发出的订阅都会代理成向父节点的订阅。 由此形成了一个发布 / 订阅的分布式树形结构， 在父节点上发布的主题消息可以被其所有子节点上的订阅者消费。 这种方式的好处就是可以消除对单一 Broker 服务的依赖，本文的例子就是采用这一方式， HQ1 为父节点，所有的 CP 都是子节点。 　　图 1.3 MQ Pub/Sub 示意图 　　Q 自带的 Broker 服务只支持简单的 Pub/Sub 功能，不支持集群功能。 比如本文的例子，只有 HQ1 为父节点，不能把 HQ1 和 HQ2 的 Broker 服务配置成一个集群父节点； 子节点只能指定一个父节点，而且也不能把多个子节点配置成一个集群子节点。 在复杂的应用环境下，Q 自带的 Broker 服务不能满足要求时， 就只能采用功能更全面的 essage Broker 了。 　　Control Point 　　为了简化说明，我们在这里只描述 HQ 和一个单一的 CP 之间的情况。首先看 CP 端（见图 1.2）。 我们假设这个 CP 的名字就叫 CP1，它配置了一个队列管理器 CP1.QM， 这个队列管理器与 HQ 端的队列管理器同在一个 Cluster 中（BCP_CLUSTER）。 由于定义在 HQ 端的 Cluster 共享队列 MR2HQ.Q 对 CP1.QM 是可见的， 这样 CP1 就可以直接向本地队列管理器 CP1.QM 中的 MR2HQ.Q 队列发送 MR 数据， 这些数据也将会被自动地传送到 HQ 端。 注意：CP1 本地的队列管理器并没有定义该 MR2HQ.Q 队列。 　　由于本地的 Broker 服务已经被配置为 HQ Broker 服务的子节点， 这样 CP1 对本地 Broker 服务某一主题的订阅（Subscribe）将被本地 Broker 服务代理成向 HQ 的 Broker 服务的订阅。 当 HQ 向其 Broker 服务发布该主题的消息时，该消息将被 CP1 本地的 Broker 服务代理消费， 进而可以被 CP1 消费。这个消费