rednight

轉自http://www.lrsolution.com/docs/MQvsWLJMS.html


比較IBM MQSeries和BEA WebLogic JMS Server

劉睿
2005年7月

在面向消息的中間件(MOM)這個領域，IBM MQSeries (又稱WebSphere MQ)一直是當仁不讓的超級大哥，其它還有一些小兄弟，比如SwiftMQ、SonicMQ之類。但近年來隨著J2EE中的JMS規范的建立，完備地支持JMS的服務器如雨后春筍般地出現，比如BEA WebLogic Server的JMS Server就是其中一個佼佼者。

僅僅就JMS規范來說，MQSeries與WebLogic JMS沒有什么不同之處。但JMS規范僅僅定義了消息服務器的一個開發接口，而且還忽略了許多細節，所以不同之處就在JMS規范之外的這些內容，很多也是非常重要的?？偟膩碚f，MQSeries的功能和性能方面明顯占優，而WebLogic JMS的某些JMS配置更加簡單易行。

在本文中，我盡量試圖從客觀的角度分析兩種產品的差異，如有不妥之處，請讀者不吝賜教。

1. 產品體系架構不同造成的差異

WebLogic JMS是一個純Java實現的支持C-S架構的實現JMS規范的服務器產品；而MQSeries是使用本地語言(比如在UNIX和Windows上的C語言)編寫的既支持C-S架構，又支持對等訪問的實現完備MOM(包括JMS規范)的產品。于是就產生出以下的不同點：

1.1 MQSeries支持真正的異步數據傳輸；而WebLogic JMS不支持。

異步發送數據到遠端的消息服務器，是MQSeries等完備的MOM的特色。JMS規范規定了一個C-S架構，定義了JMS客戶機與JMS服務器的開發接口，并沒有定義JMS服務器與JMS服務器的規范，而客戶機方面沒有任何隊列，所以只能說是規范了消息的存取，而沒有規范消息數據的傳輸。因為JMS客戶機并不擁有存放數據的隊列，所以所有發送的操作都要由應用程序來控制，JMS服務器本身并不代理傳輸，也不保證數據在遠程隊列間傳輸的可靠性。WebLogic JMS就是這樣的體系。

這種體系結構有時候是不能直接滿足應用的要求的。首先，為了充分利用資源和提高效率，許多應用需要采用異步消息的機制。其次，許多需要快速返回的應用也必須使用異步傳輸。比如電話自動語音應答(IVR)的程序，某個操作需要把數據傳輸到遠程的服務器上，但是必須立即返回，接受客戶的下一個按鍵。

MQSeries通過通道與傳輸隊列和遠程隊列來完成這一任務。能充分利用網絡的帶寬，甚至支持斷網續傳，保證數據傳輸的可靠性。當然，雖然應用程序不必作任何工作，但配置方面確實還要多學一些概念。

1.2 MQSeries支持多種語言的開發；而WebLogic JMS基本上只支持JAVA

MQSeries支持的語言包括C, C++, COBOL, JAVA, PL/1, REXX, RPG, Visual Basic (使用COM/ActiveX)等。老板本的MQSeries支持JAVA是通過一個叫MA88的SupportPac來實現，雖然經過廣泛的使用和驗證，但給人的感覺是不太方便。好在從5.3版起(目前最新的是6.0版)，JAVA支持已經內置在MQSeries中。

WebLogic JMS一般只支持JAVA開發。但BEA也在dev2dev.bea.com網站上提供了一套免費的C的支持，稱作“JMS C API”。參見http://dev2dev.bea.com/utilitiestools/environment.html?highlight=utilitiestools。但這個工具與老的MA88也是不能相提并論的，因為BEA并不真正支持它，因此也基本沒有什么用戶。參見BEA網站上關于“JMS C API”的警告：

1.3 純JAVA實現的利與弊

MQSeries是用本地語言實現的，因此帶來的好處是高性能和高并發的支持能力。MQSeries相對WebLogic JMS等產品的性能優勢是非常明顯的，所以MQSeries非常適于企業級的大數據量和高并發的數據傳輸業務。誰也無法想象一個企業級的數據應用會采用一個純Java實現的數據庫，因為其性能無法滿足要求，對較大的數據傳輸應用也是一樣的，純Java實現的JMS服務器例如WebLogic JMS無法滿足其性能的要求。

純JAVA實現的JMS服務器也有其好處，就是與其它的J2EE服務完美地集成在一起。所以WebLogic的JMS配置顯得更簡潔。WebSphere+MQSeries也配合得很好，但總是能感覺到是這兩個產品。WebLogic JMS的對象體系完全符合JMS的概念體系。而MQSeries要通過WebSphere Application Server或者一個叫JMSAdmin的工具，借助于目錄服務來完成MQSeries概念體系到JMS概念體系的映射。應該是看到了這件事造成的麻煩，所以IBM在WebSphere v6也提供了一套純JAVA實現的、與MQSeries可以互操作的JMS服務器。另外一點是WebLogic不需要WebSphere以及MQSeries那樣的冗長的CLASSPATH等環境變量的設置，這點對開發人員有吸引力。

1.4 MQSeries的通信功能更加強大，WebLogic JMS也有自己的一些特色

JMS對通信功能的要求很少，所以對二者對通信支持能力還是有很大的差別的?？偟膩碚f，歷史更悠久的MQSeries占優，但WebLogic JMS也有自己的特色。

• MQSeries支持支持真正的遠程異步數據傳輸，甚至支持消息的路由，可以“多級跳”；WebLogic JMS不支持。
• MQSeries支持消息的分組和分段傳輸，對于大消息傳輸和不穩定的網絡非常有意義。WebLogic JMS沒有這方面的功能。
• 二者都支持SSL、持久性、優先級、超時等功能。除了完備的SSL實現之外，MQSeries的安全體系 遭到了一些批評，使用通道的安全出口程序顯得很麻煩，而使用用戶名稱但無須口令保護的遠程數據通信，如何能令人滿意？但在這一點上WebLogic JMS也很難說就好一些，因為WebLogic JMS僅僅支持C-S的操作，系統本身并不支持遠程的數據傳輸(需要應用實現)。
• WebLogic JMS支持IP多播會話，能顯著地提高 局域網內廣播通信的性能，但這種方式不保證數據接收的可靠性，只適于某些特定的應用。MQSeries本身不提供此功能，但在Event Broker和Message Broker等MQSeries的升級產品中提供IP多播的支持。

1.5 MQSeries的管理功能更加強大

JMS對管理功能的要求很少，在這方面MQSeries也有比較明顯的優勢。

• JMS對事務處理的支持包括的對XASession和XAConnection實現，這一點對MQSeries和WebLogic JMS是相同的。MQSeries本身還可以作為事務管理器，協調兩階段提交。
• MQSeries和WebLogic JMS都支持Message Driven Bean作為觸發新的應用的一種方式。WebLogic JMS還支持一種稱作Session Pool的類似的觸發機制。但這類觸發機制過于簡化，也就是每個消息都觸發一個新的線程的應用。MQSeries的觸發機制更豐富，不但包括這種被稱作Every的方式，還包括First和Depth等方式。另外MQSeries還可以觸發各種執行程序或者MQSeries的通道。
• MQSeries擁有一套完備的日志系統，可以進行獨立的系統備份和恢復，因此適于高規格的數據/消息傳輸的應用。WebLogic JMS沒有這方面的支持。

　

2. 產品歷史的不同造成的差異

MQSeries是個歷史悠久的產品，而WebLogic JMS是個新兵，因此會有以下的差異：

2.1 MQSeries支持更多的系統平臺

支持30多種系統平臺。當然值得注意的是某些平臺的MQSeries是由合作伙伴實現的。

WebLogic JMS是個新產品，支持的平臺數與WebLogic Server一樣，只有常用的幾個。有人說所有支持JDK的平臺都能跑WebLogic JMS的客戶機，這是不正確的說法。因為JMS是J2EE規范的一種，J2SE的SDK并不包括JMS的支持，更不要說支持WebLogic的J2EE了。

2.2 MQSeries支持更多的 通信協議

MQSeries支持很多通信協議，但目前在實踐中常用的是TCP/IP協議和SNA協議。

WebLogic JMS僅支持TCP/IP協議。

有些人對MQSeries的單向通道的概念提出了異議，認為增加了配置的復雜性，僅僅是SNA協議的需要，而不是TCP/IP協議的需要。我個人認為這點也不無一些道理。但是在有防火墻的TCP/IP網絡上，不同的方向還是有差異的。

　

3. 群集實現的差異

MQSeries與WebLogic JMS在支持群集時，差異比較大，應該說各有各的特點。

• MQSeries的群集建立在配置庫和群集通道基礎之上，可以定義“共享隊列”；WebLogic JMS的群集建立在WebLogic群集基礎之上，可以定義“分布式隊列”。
• MQSeries在寫共享隊列時，如果發現本地有，就只寫本地的隊列(這稱作本地優先)；如果本地沒有，就會輪流寫到所有定義了此共享隊列的隊列管理器。MQSeries在讀共享隊列時，只能從本地取。WebLogic JMS在讀寫分布式隊列時，不受本地影響，總是進行輪流或權重選擇。聽起來似乎WebLogic JMS的群集更靈活，其實也不盡然。當取得了JMS的對象QueueSender或QueueReceiver后，WebLogic實際上已經綁定了一個JMS服務器的實例。如果每次寫或讀一個消息，都重新生成QueueSender或QueueReceiver，雖然比較好地支持了負載均衡，但勢必造成很大的性能損失。而MQSeries在輪流寫共享隊列時，沒有這方面的問題。
• WebLogic JMS的分布式隊列有一個叫做Forward Delay的有意思的屬性，定義了一個時間的長度。系統一旦發現超過這個時間長度，還沒有人讀這個隊列，就把它的消息轉送給群集中有消費者的隊列。有了這個屬性，應用程序就可以只從一個JMS服務器的實例讀消息了。