Geronimo 叛逆者: Apache Geronimo 的 JMS 實現：ActiveMQ

獲得消息

Java™ 2 Platform, Enterprise Edition（J2EE）應用服務器并不是一個簡單的軟件。它有許多必須相互通信的組件。它還必須支持應用程序中的 Enterprise JavaBeans（EJB）相互通信。還必須考慮到，當需要創建集群解決方案（涉及多個位置的多臺計算機上的多個實例）時，會發生什么情況。在 Geronimo 叛逆者專欄 中已經對集群進行了相當多的討論，現在要注意的一個領域是系統中的消息傳遞。

顯然，不具備消息傳遞解決方案的應用服務器是沒什么用的。實際上，根本不可能存在不具備消息傳遞解決方案的 J2EE 應用服務器；JMS 標準的實現是 J2EE 規范的要求之一。在 Apache Geronimo 技術中，這是通過集成來自 ActiveMQ 項目的軟件而實現的。

在走了幾次彎路之后，包括一個糟糕的 Internet Relay Chat（IRC）客戶機，我最終與 Apache Geronimo 和 ActiveMQ 的創建者之一 James Strachan 談到了這個軟件 —— 它是什么，它起什么作用，以及它對 Geronimo 項目的意義。由此，我在面向消息的中間件（MOM）方面上了一課，而且看到了面向服務體系結構（SOA）的未來發展。

回頁首

進入 ActiveMQ

“我并不是說 ActiveMQ 由 Apache Geronimo 項目發展而來，” 當我建議談談 ActiveMQ 時 James 說，“但 Geronimo 項目的啟動促使我們進行 ActiveMQ 的開發。” J2EE 規范要求有符合 JMS 1.1 的消息傳遞提供者，“所以我參與創建了 ActiveMQ 項目。”

許多人沒有意識到：盡管可以從 Sun Microsystems 站點下載 JMS 1.1，但是這只是一個參考實現。如果想在自己的項目（尤其是開放源碼項目）中支持這個消息傳遞框架規范，很可能需要編寫自己的 JMS 1.1 規范實現。

這就是這個團隊所做的。實際上，ActiveMQ 是一個獨立于 Geronimo 的項目，盡管有許多人同時參與了這兩個項目，包括 James、Dain Sundstrom、Geir Magnusson、Hiram R. Chirino、Greg Wilkins、David Jencks、Alan Cabrera 和 Aaron Mulder。不但可以在其他應用服務器中使用 ActiveMQ，而且即使根本沒有應用服務器，也可以使用它。例如，如果要開發一個需要來回傳遞消息的應用程序，那么可以使用 ActiveMQ 而不是 JMS 參考實現。James 指出，“許多人將 ActiveMQ 用在 Spring 和 Tomcat 上。”

目前，ActiveMQ 還在 Apache Incubator 中，這意味著它還沒有被 Apache Software Foundation 正式接受，但是正在向這個目標發展。“這是進入 Apache 的過渡階段，” James 解釋道，“就像是氣密艙，項目可以進入其中，遷移到 Apache 基礎設施，并學習如何成為 Apache 的一部分。” 這涉及到理解投票過程、建立項目管理委員會和其他活動。

Incubator 還要為項目建立一個活躍的社區，所以團隊的多樣性是很重要的。“Apache 不希望成為廠商推廣產品的地方，” James 說，“他們希望有一個活躍的由各種人員組成的社區。”

社區也是 ActiveMQ 選擇作為 Apache Incubator 的一部分的原因，因為它的社區實際上是 Geronimo 項目的一部分。“另外，” James 補充說，“我們發現各個公司開始自愿地向 Apache 捐獻軟件授權、許可協議和 IP 策略。”

但是，ActiveMQ 究竟是做什么用的呢？我與 James 談了相當長一段時間之后，吃驚地發現，我們甚至沒有提到集群。所以，這時我意識到 ActiveMQ 一定不只是為集群服務的。實際上，ActiveMQ 在 Geronimo 的 MOM 中處于中心位置。

回頁首

什么是面向消息的中間件？

顧名思義，面向消息的中間件就是通過使用消息（而不是直接命令）將企業內的組件連接起來的系統。“它們是原始的 SOA 之一，” James 指出，“MOM 在許多年前就流行了，它作為使用高性能異步消息交換將松散耦合的系統連接在一起的方式。例如，庫存系統可能會與工資和會計系統進行通信。如果使用 MOM 將它們連接在一起，就可以在任何時候關閉任何系統，發送到這個系統的消息會放在隊列中，直到系統恢復工作。這樣，就可以在平臺、語言、API 和（最重要的）時間方面對系統進行松散耦合。”

我問 James，除了簡單地提交和接收消息之外，MOM 還有什么作用。他解釋說，它提供了兩個基本服務：發布/訂閱和隊列功能。

在發布/訂閱 系統中，消費者告訴系統它正在尋找關于某一主題的任何信息。這個主題可以是很明確的，比如某只股票的價格更新，也可以是比較寬泛的，比如來自數據庫的事件。當生產者產生這種消息時，客戶機就會收到它們。通常，消息不是從生產者直接發送給消費者，而是由一個代理來管理消息，代理確保正確地對消息進行分發。

在隊列 系統中，無法立即提交的消息會保存在隊列中，當適當的時候再提交。按照這種方式，如果消費者不在線，消息也不會丟失。“MOM 通常使用持久性消息傳遞，” James 解釋說，“一些消息被寫到硬盤上，這樣就不會丟失了。例如，如果一個消息是 please deduct $1000 from bank aclearcase/" target="_blank" >ccount foo。您肯定不希望丟失這個消息或者由于意外發送它兩次。”

這就是 MOM 的作用：精確地按照您希望的次數，將消息可靠地提交到準確的位置。

回頁首

MOM 與 Web 服務

在 10 多年時間里，已經使用 Common Object Request Broker Architecture（CORBA）、Remote Procedure Call（RPC）或 EJB 等技術構建了這些系統。這些技術的問題是，它們對于單一系統工作得非常好，但是它們通常是同步的（這意味著在發送和接收消息時所有其他處理都會停止），而且依賴于位置。另外，系統通常涉及組件之間的緊密耦合。

當然，近來緊密耦合問題已經解決了，SOA 出現了。人們常常將 SOA 與 Web 服務混為一談，但是這兩者不是同義詞。Web 服務，比如基于 Simple Object Access Protocol（SOAP）和其他 XML 協議的 Web 服務，對于跨越組織邊界的應用程序是很合適的。“Web 服務的目標是成為一種開放式連接協議，” James 說，“而 MOM 通常對連接的每一端都進行控制。”

SOA 的開放性使得它得到了迅速發展。通常只有大型且先進的公司才使用 MOM，Web 服務大大擴展了這個市場。

但是，這兩者并不是相互排斥的。通過 MOM 系統發送 SOAP 消息并不少見，有的 MOM 系統還實現了 WS-* 標準。實際上，ActiveMQ 已經實現了 WS-Notification，這是發布/訂閱范型的 Web 服務版本。

另一方面，作為一種成熟得多的技術，在遇到其他需求（比如可靠的消息傳遞）時，MOM 比 Web 服務有優勢。James 說，“HTTP 沒有可靠性或正好一次 提交語義。”

他給我看了他寫的一些關于 WS-ReliableMessaging 與 MOM 問題的博客，他在其中指出，“在 JMS/OpenWire/MOM 中，有辦法指定每次消息交換的服務質量。” 換句話說，可以決定服務質量或需求，包括有保證的提交、消除重復提交，等等。James 接著說道，“WS-RM 基本上只處理消息確認（以及傳遞的次序和重復的次數是否正確），所以現在仍然需要有某種 WS-* 規范來控制其他各種服務質量，從而可以在使用 WS-RM 提供者時作為策略指定，而這些在 MOM 中早就存在了。”

另一個問題是性能。“如果您控制連接的兩端，” James 解釋道，“那么由于各種原因，使用 JMS/MOM/[Microsoft Message Queuing] MSMQ 提供者一般來說總是比 WS-RM 快，MOM 是基于連接的，不需要分析 XML 標記，而且多年來消息傳遞問題已經經過了充分的研究，廠商提供的實現已經很完善了。另一個好處是，MOM 可以與組織中遺留的非 WS 應用程序很好地配合。（大多數組織目前還擁有大量的 MOM 應用程序。）

“但是，WS-RM 的主要目的是在不同的消息傳遞系統之間建立橋梁，比如 Windows Communication Foundation（WCF）和其他 JMS/WS/[Enterprise Service Bus] ESB 棧，所以它不必比已經建立的 MOM 更出色。它的設計目的不一樣，它尋求的是消息傳遞系統之間的互操作性，而不是最好的消息傳遞系統。”

同樣，ActiveMQ 是 Geronimo 在嘗試解決這些互操作問題過程中的成果。

回頁首

ActiveMQ 和 Geronimo？

ActiveMQ 用在 Apache Geronimo 應用服務器中的許多地方，其中一些比較明顯。我們已經大量討論了消息傳遞和集群，所以就不著重討論了。

ActiveMQ 使用 Java Connector Architecture（JCA）與 Geronimo 集成起來，這是一個 “用于 J2EE 的連接和線程池體系結構，可以處理任何協議，比如 JMS、JDBC（Java Database Connectivity）等等，” James 說。“它還處理異常處理和事務等問題，” 他補充說，“它是將 JMS 提供者這樣的東西干凈地與應用服務器集成起來的好方法。” 為了支持這樣的集成，ActiveMQ 被包裝在一個資源適配器中。這個資源適配器使任何應用服務器都能夠對 ActiveMQ 發送和接收信息。

這種方法使 Geronimo 能夠將 ActiveMQ 用于多種用途。除了進行集群之外，ActiveMQ 還作為 JMS 代理。這個代理是 JMS 解決方案的服務器端組件，負責路由、持久化、恢復，等等。它還包含一個 JMS 客戶機，這個客戶機使用戶能夠創建使用消息驅動 bean（message-driven bean，MDB）的應用程序，MDB 是一種只用來處理這些消息的 EJB。

“例如，” James 說，“您可能接收到一個向站點進行注冊的 HTTP 請求；開發人員往往不在 servlet 中檢驗電子郵件地址，而是向一個隊列中發送一個消息，讓另一個服務來執行注冊。同樣，EJB 可能決定將處理工作委托給其他組件，這時就可以使用 JMS 發送一個請求。

“JMS 的常見用途是：(1) 可靠地異步處理負載平衡、故障轉移和集群；(2) 對緩存/狀態進行分布；(3) 實現實時 GUI，比如實時顯示價格變動。”

回頁首

在不使用 Java 技術的情況下在 Geronimo 中訪問 JMS

換句話說，Geronimo 的 ActiveMQ 實現讓您能夠構建一個 GUI 應用程序，讓它使用 JMS 客戶機與應用服務器進行通信，所以不需要 Web 頁面。ActiveMQ 還支持 Stomp 項目，這是一種與 JMS 代理進行交互的方式，非常簡單而且獨立于語言。因為它只要求打開一個套接字（比如使用 telnet），所以使用任何語言的客戶機都能夠與 JMS 代理進行通信。這樣的 “交談” 可能就像 清單 1 這樣。

CONNECT
            login: myUsername
            passcode: myPassword
            ^@
            CONNECTED
            session:<someuniquevalue>
            ^@
            SEND
            destination:/queue/thingsIllDoToday
            Make sure to receive any changes to the weather in Toledo.
            ^@
            SUBSCRIBE
            destination:/topic/weatherChanges
            ^@
            MESSAGE
            destination:/topic/weatherChanges
            message-id:<someuniqueidentifier>
            Temp: 62
            ^@
            MESSAGE
            destination:/topic/weatherChanges
            message-id:<someuniqueidentifier>
            RainChance: 60
            ^@
            MESSAGE
            destination:/topic/weatherChanges
            message-id:<someuniqueidentifier>
            Temp: 60
            ^@
            

每個消息（即幀）以一個命令開頭，以一個表示 null 字符的 ASCII 符號結束。在這個例子中，我將從服務器發送到客戶機的消息顯示為斜體，以便區分。在這里可以看到，一個客戶機連接到這個系統，它將一個消息發送到隊列 thingsIllDoToday，然后訂閱 weatherChanges 隊列。代理每當接收到屬于這個隊列的消息時，就把消息發送給這個客戶機。

Stomp 項目已經開發了 Ruby、Python、Perl、PHP、C、C# 和 Java 語言的客戶機。還可以使用二進制連接格式 OpenWire，這實際上是 ActiveMQ 的默認連接協議。它比較快，但是比較難實現。

回頁首

消費者端的負載平衡

James 還告訴我，他最欣賞的 ActiveMQ 特性之一是可以在消費者端進行負載平衡。消息組是一種不太為人所知的 JMS 可選特性。“它有點兒像 Web 應用程序的負載平衡，但是應用于消息傳遞，” 他說。假設您將來自 Amazon 站點的訂單放進一個隊列中，希望盡可能快地處理它們。JMS 提供者會在消費者之間根據負載平衡原則分配這些消息。但是，如果希望按照次序處理消息，就會遇到一個問題：只能使用一個消費者來處理消息，這樣才能保證次序的完整性，才能正確地處理訂單。

“所以，如果我們的集群有 1,000 個消費者，可以將 JMSXGroupID 字符串添加到每個消息中，表示它屬于哪個組，這樣就可以維持消息的次序。例如，可以使用 Books 作為 ID。這樣就由一個消費者來處理所有圖書，而 Electronics 和其他類別的商品仍然進行負載平衡。還可以使用圖書的 ISBN 號作為 ID，這樣所有 Getting Things Done 圖書由一個消費者處理，JMS Essentials 圖書由另一個消費者處理。所以，它是一種有親和性的可定制的負載平衡，可以支持故障轉移。如果一個消費者停止工作了，那么另一個消費者會替代它。甚至可以將當前擁有的圖書數量緩存在消費者中，因為在整個集群中只有這一個線程處理這種書的訂單，所以其他消費者不會修改數據庫。所以可以進行超高效率的緩存，避免鎖定和爭用問題。這是一種對應用程序進行劃分，從而使吞吐量最大化的好方法。”

回頁首

Geronimo 和消息傳遞的未來發展

現在，似乎尋找通用的消息傳遞解決方案更容易了，這種想法既正確也不正確。即使在這個 Web 服務大肆流行的世界中，實現消息傳遞的方式仍然日益增多。JMS、CORBA、SOAP、Remote Method Invocation（RMI）、EJB，我可以一直列舉下去。這種不斷復雜化的局面讓我這樣的開發人員覺得害怕，但是 James 認為不需要如此擔心。

“重要的是，開發人員往往把 JMS 和 EJB 這些東西想得太復雜了，” James 告訴我，“所有中間件工作的實際操作正在隱藏在 Plain Old Java Object（POJO）后面。這方面的嘗試包括 EJB 3、Spring Remoting 和 Service Component Architecture（這可以在 Apache Tuscany 中看到）。所以，開發人員不必選擇使用 JMS API、EJB API、RMI、CORBA 或 SOAP，他們只需部署自己的 POJO 并在容器中啟用中間件。

“甚至可能將中間件完全隱藏起來，這樣應用程序開發人員只需編寫業務邏輯，而讓容器來處理中間件的瑣碎工作。”

目前，Apache Geronimo 還有另一個涉及 ActiveMQ 的方便特性：ServiceMix。ServiceMix 是一個依賴于 ActiveMQ 的 ESB，但是它允許集成來自所有類型的環境的消息。啟用 ServiceMix 中的 Java Business Integration（JBI），這樣系統就可以接收來自各種來源的消息，比如文件、電子郵件、Jabber、SOAP、來自其他啟用 JCA 的組件的消息等等，并讓它們一起工作。ServiceMix 將是 Geronimo 1.2 版本的一部分。

回頁首

結束語

我們處于面向服務的環境中，在這種環境中消息傳遞并不是錦上添花的東西，而是必需的。Geronimo 用來提供消息傳遞服務的 ActiveMQ 實現本身就是一個有用的項目（在 Geronimo 內外都是），感謝 James Strachan 花時間與我們對它進行了討論。