WebSphere MQ 自带的 Broker 服务用于支持简单的 Pub/Sub 功能， 每个队列管理器中有唯一的 Broker 代理来处理所有主题的订阅和发布。 在单一队列管理器上启用 Broker 代理时， 主题的发布者和订阅者都直接访问这同一个队列管理器，在其上可以定义多个主题。 多个队列管理器之间也可以做父子级联， 前提是要建立双向的发送 / 接收通道以及相应的传输队列， 当然如果两个队列管理器都在同一个 MQ Cluster 里也行。 父子级联的效果就是子节点成为订阅代理， 订阅者向子节点发出的订阅都会代理成向父节点的订阅。 由此形成了一个发布 / 订阅的分布式树形结构， 在父节点上发布的主题消息可以被其所有子节点上的订阅者消费。 这种方式的好处就是可以消除对单一 Broker 服务的依赖，本文的例子就是采用这一方式， HQ1 为父节点，所有的 CP 都是子节点。

    图 1.3 MQ Pub/Sub 示意图

    WebSphere MQ 自带的 Broker 服务只支持简单的 Pub/Sub 功能，不支持集群功能。 比如本文的例子，只有 HQ1 为父节点，不能把 HQ1 和 HQ2 的 Broker 服务配置成一个集群父节点； 子节点只能指定一个父节点，而且也不能把多个子节点配置成一个集群子节点。 在复杂的应用环境下，WebSphere MQ 自带的 Broker 服务不能满足要求时， 就只能采用功能更全面的 WebSphere Message 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 消费。这个消费的具体实现就是在 CP1 端用一个 MDB（Message Driven Bean） 侦听（即订阅）本地 Broker 服务上的指定主题（本例中为 BCP.WL.Topic）。

    Headquarter

    MQ Cluster 一般都至少需要两个 Full Repository，为了简化， 在本文的实例中把 HQ 的两个队列管理器（HQ1.QM 和 HQ2.QM）都设置为 Full Repository。 Cluster 共享队列 MR2HQ.Q 在两个队列管理器上都有定义，Broker 服务则只在 HQ1.QM 上启动。

    HQ 上对每个队列管理器都需要一个 MDB 来处理发送到该队列管理器的 MR 数据； 而当需要发布 WL 数据到各个 CP 时，只需要向 HQ1.QM 上的 Broker 服务针对主题 BCP.WL.Topic 发布即可。

    经过如上配置，无论是 CP 还是 HQ 上的应用程序都只需要和本地的队列管理器打交道。 在 CP 端，MR 同步消息直接发送到本地队列管理器，MQ 会负责把消息发送到 HQ。 如果 CP 和 HQ 之间的网络中断，这些消息将缓存在 CP 端，等到网络重新联通后就会继续发送。 在 HQ 端，应用程序只侦听本地队列管理器的队列， MR 同步消息到达后就会触发相应的 MDB 来处理这些消息。这样， 网络不稳定不可靠因素由 WebSphere MQ 处理，对应用程序完全透明。 由于 CP 和 HQ 之间不直接交互，既消除了它们之间的性能依赖， 同时可以让其更专注于其各自的业务。