應用WebSphere MQ V6 來構建公司資訊匯流排的行業樣本

引言

IBM WebSphere MQ 是目前應用最多的訊息中介軟體產品， 它採用了訊息佇列（Message Queue）這種應用程式間的通訊方法， 讓不同的應用程式通過讀寫和檢索出入隊列中的資料（訊息）來通訊， 而無需直接面對網路易變、系統異構、資料協同等各種問題和風險。 WebSphere MQ 同時也支援簡單的 Publish/Subscribe（發布 / 訂閱）訊息傳遞機制， 每個隊列管理器中有唯一的 Broker 代理來處理所有的訂閱和發布。

WebSphere MQ 支援 Cluster（簇或叢集），即多個隊列管理器（Queue Manager 以下簡稱 QM） 的集合，這些隊列管理器可以分布在不同的機器上。 本文中的例子採用了上述的 Queue 和 Pub/Sub 兩種方式， 並建立了一個 MQ Cluster 來簡化資料轉送的配置和 MQ 對象的管理， 採用 MQ Cluster 的理由基於其如下特點：

1) Cluster 中的隊列管理器之間的資料轉送通道是自動建立的， 使得資料轉送配置變得更簡單；

2) 隊列管理器中的隊列可以被指定為 Cluster 共用隊列， 對 Cluster 中的所有的隊列管理器都是可見的； 不同隊列管理器中定義的同名 Cluster 共用隊列自動實現針對該隊列的傳輸負載平衡；

3) 不同隊列管理器的 Broker 代理之間可以指定主從關係， 這樣就可以在 Cluster 內很方便地實現樹狀的 Pub/Sub 結構。

在根據需要配置好 WebSphere MQ 之後， 就可以在 WAS 上進行相應配置並在應用程式中整合這些資源了。 下文將會詳細介紹如何根據本文執行個體的需要來配置 WebSphere MQ， 以及 WAS 和應用代碼、配置上的細節。

執行個體描述

這是一個出入境清關係統的例子（見圖 1.1）。這個系統由一個管理中心 （Headquarter，以下簡稱 HQ）和多個子控制中心（Control Point，以下簡稱 CP）構成。 其中每個 CP 會產生大量清關資料（Move Record，以下簡稱 MR）, 這些清關資料需要被傳送到 HQ 上匯總；各個 CP 在處理清關操作的時候需要的監控列表 （Watch List，以下簡稱 WL）則由 HQ 定製並不定期向各個 CP 分發。

圖 1.1 系統示意圖一

這裡 CP 和 HQ 之間的資料轉送採用 WebSphere MQ 來實現， HQ 和每個 CP 都有自己的隊列管理器（QM），這些 QM 被配置為同處於一個 MQ Cluster 中。 MR 的資料轉送是 CP 到 HQ 單向點到點的資料轉送， 在本例中用定義在 HQ 端的隊列管理器中的 Cluster 共用隊列（MR2HQ.Q）來實現。 WL 的資料則是 HQ 向各個 CP 的廣播，這就需要採用 Pub/Sub 的模式。 執行個體中是選擇 HQ 的一個隊列管理器啟動 Broker 服務， 然後每個 CP 的隊列管理器也都啟動 Broker 服務並作為 HQ 的 Broker 子結點。

圖 1.2 系統示意圖二

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 了。