最近幾年，開發人員可以更廣泛地得到企業消息排隊（MQ）產品。適當地使 用 MQ 技術經常可以改善應用程序的組織、性能和可伸縮性。Java 消息服務 （Java Message Service (JMS)）是集成到 J2EE 中的一部分，它使得 MQ 服務 可以為任何 J2EE 應用程序所用。在本文（也是本專欄系列的第一部分）中， Brian 概述了在 Java 應用程序中使用消息排隊的一些好處，並探討了能夠從 MQ 技術中獲益最大的問題類型。請在 論壇上（或者通過單擊本文頂部或底部的 討論）同作者及其他讀者分享您對本文的想法。
消息排隊（MQ）工具沒有數據庫工具（例如關系（SQL）數據庫）為人所知或 為人理解，數據庫工具是幾乎所有企業應用程序和大量比較簡單的應用程序中的 關鍵組件。開發人員總是可以采用多種類型的數據產品，其范圍包括從廉價的、 只能在台式機上使用的數據庫（例如 dBase 或 Microsoft Access），到工作組 數據庫服務器（例如 Sybase SQL/Anywhere），再到企業數據庫服務器（例如 DB2 或 Oracle）。無論您的項目是什麼樣子的，總有一個價格、性能及功能都 適合的數據庫產品可供您使用。
和數據庫相似，MQ 產品有時被稱為面向消息的中間件（MOM），已經出現相 當一段時間了。然而，直到最近，MQ 服務器還一直是昂貴的、只能被資金最充 足的企業開發人員所用的高端產品。結果，只有非常少的開發人員可以享受在其 應用程序中使用消息傳遞所帶來的好處。
大眾化的消息排隊
幸運的是，這一狀況正在開始改變；現在市場上已經出現了幾種價格較低的 MQ 服務器。1997 年，Microsoft 發布了 MSMQ，它是一個事務性消息排隊產品 ，作為 Windows NT Server 中的集成部分 ― 無需額外的許可費用。Sun 將 JMS API 包括在最初的 J2EE 規范中，這極大地促進了消息傳遞的大眾化。在 J2EE 規范的版本 1.3 中，所有的 J2EE 容器都要求包含 JMS 提供程序 （provider）。
JMS，也就是 Java 消息服務，它是一種允許 Java 應用程序通過標准化的接 口訪問范圍廣泛的 MQ 服務器（或者，按照 JMS 的說法，是提供程序）的 API ，就象 JDBC 允許程序通過一個公共接口訪問許多不同的數據庫服務器一樣。大 多數 J2EE 容器包含 JMS 提供程序；將來，所有 J2EE 容器都將包含 JMS 提供 程序。沒有 J2EE 容器也可以使用 JMS；市場上有幾種獨立的 JMS 提供程序實 現。此外，EJB 2.0 規范引入了一種新的 EJB 類型 ― 消息驅動 bean ― 它使 得創建利用實體和會話 bean 的消息驅動的組件非常容易。
既然我們都可以使用 JMS 服務，我們就應該學會在應用程序中使用消息傳遞 的能力。Willy Farrell 是 IBM 的一名電子商務設計師，他寫了一本優秀的關 於使用 JMS 的介紹性教程（參閱 參考資料）。它涉及創建消息和隊列的基本知 識，以及對消息劃分優先級、檢索消息和編碼消息的所有選項。
消息傳遞和數據庫起了相互補充的作用，在許多情況下，同時使用消息傳遞 和關系數據庫可以產生比只使用它們中的一個好得多的解決方案。
歷史上，曾經將 MQ 服務器用於面向事件的應用程序（例如財務服務應用程 序）或者作為一種與完全不同的系統進行相互操作的方式（例如連接完全不同的 數據庫應用程序或將一個企業同另一個在供應鏈網絡中的企業相連接）。術語“ 面向消息的中間件”經常應用於 MQ 服務器，它強調 MQ 技術主要用途是連接完 全不同的系統。然而，隨著 MQ 產品成本的降低，許多其它應用程序現在也可以 從消息排隊中獲益。
MQ 服務器做什麼？
用 MQ 的說法，消息只是一個字節流（這個字節流可以是一個 XML 文檔、一 個序列化的 Java 對象、一個文本字符串或甚至是一條空消息）。對消息的解釋 留給應用程序域來做；MQ 基礎結構不對消息施加任何語義和結構限制。消息存 儲在隊列裡，MQ 服務器允許您將消息加入到隊列以及從隊列中取走消息。
到目前為止，消息隊列聽起來很象簡單的鏈表。從其最簡單形式來說，的確 是這樣的，但是企業 MQ 服務器通過將一些功能特性封裝進這一鏈表管理而增強 了其功能：
控制誰可以向隊列中寫以及誰可以從隊列中讀的安全性
網絡接口，它允許消息生產者和消費者位於不同的地方
事務性支持，這樣入隊和出隊操作都具有事務特性：原子性、一致性、隔離 性以及可持久性
分布式事務支持，這樣隊列操作可以同其它資源管理器（如 SQL 數據庫）一 起參加分布式事務
持久存儲性
負載均衡
故障轉移
管理
MQ 的長處
MQ 的長處源自消息處理的異步性質所帶來的固有的 松散耦合。一個實體向 隊列發布消息與另一個實體除去並處理消息的過程是完全分離的。這兩個實體無 須同時運行，也無須位於同一系統上，甚至無須知道另一個實體的標識；它們僅 按照自己的時間表同隊列交互。它們只須就彼此將接收的消息的格式達成一致； 此外，它們無須知道對方的任何其它事情。
松散耦合有許多優點。它提供了一個自然的機制，將一個工作單元分成更小 的、獨立的組件，這種機制在處理請求的各階段之間隱式地創建了抽象。這種細 分允許我們方便地一個接一個地抽象每個組件的實現，更好地衡量和管理每個組 件對資源的利用，或者使用提供具有類似功能的組件替換一個組件而無需改變其 它組件。
JMS 規范要求 JMS 提供程序也實現 發布和訂閱功能，該功能允許您創建不 同的、應用程序定義的且名稱為 主題的通道，並允許單個實體訂閱這些主題。 排隊到主題的消息自動放置在任何訂閱過該主題的實體的專用隊列中。主題在財 務服務或新聞發送應用程序中執行有價值的排序功能。例如，雖然有 5000 多種 股票在美國的主要交易所交易，但每個投資者可能只對其中的 30 種股票感興趣 。因此您可以為每個訂單符號創建一個主題，讓用戶訂閱他們感興趣的符號，然 後讓 MQ 引擎執行僅僅顯示每個投資者想要的報價，避免發送重復的股價。用 SQL 數據庫實現這一過程要困難得多。
經典的 MQ 用法模式
有一些最適合於使用消息排隊的常見用法模式。當在您的應用程序中看到這 些模式之一時，您應該考慮使用消息傳遞。
面向事件的應用程序
高度面向事件的應用非常適於使用 MQ 技術。這些包括財務服務應用程序（ 請考慮一個證券交易所，它顯示股票價格更新，根據價格變化或其它訂單的執行 來啟動交易，報告訂單狀態等等），新聞發送服務應用程序以及供應鏈應用程序 。在金融市場中，必須對事件進行迅速處理；當發生了重要的事情時，您希望在 它一發生時就得到通知。
輪詢數據庫
數據庫在持久存儲數據方面是非常優秀的，但是存儲瞬時數據並在數據改變 時通知我們卻不是它們的長處。
雖然它不是高效的，但是輪詢數據庫卻非常常見。每個機場的顯示監視器不 斷輪詢數據庫以更新它們顯示的信息。有許多出納窗口的銀行經常使用電子信號 來指示下一個空閒出納員的位置。電子商務站點內的訂單處理系統可能輪詢數據 庫以查看是否有任何新訂單需要處理。或者保險索賠工作流系統可能輪詢以查看 是否有任何新的索賠可以分配給空閒的索賠調解人（claims adjusters）。
所有這些輪詢都產生了許多額外的工作。如果有許多實體頻繁地輪詢（並且 如果它們想要迅速地反映數據的更新，它們就必須這麼做），就可能給數據庫服 務器和網絡造成很大的負載。在大多數時候，輪詢不返回數據，更糟的是，會返 回我們已經見過的數據，但又必須再次處理或標識為已經處理過。
數據庫不只是為輪詢或事件而設計的。如果在事件發生或數據更改之後必須 采取相對迅速的行動，那麼異步消息傳遞是完成這一任務更容易和更有效的方法 。無論何時在需要知道更新而輪詢數據庫時，請考慮使用 JMS 來替代數據庫。
工作流
根據工作流門戶網站（它是 Workflow Management Coalition 和 Workflow And Reengineering International Association 共同努力的結果）的定義，工 作流是“……整個或部分商業過程的自動化，在這一過程中，根據一套過程規則 ，將文檔、信息或任務從一個參與者傳遞給另一個參與者。”MQ 解決方案特別 適合於工作流應用程序（例如文檔路由和批准、保險索賠處理等等），這是因為 MQ 技術對如何處理大量使用紙張的辦公室裡的工作流問題進行了精細的建模， 在這種辦公室內每個參與者都有一個收件箱和發件箱。
工作流應用程序的特征是有許多代理（代理可以是人，自動處理步驟甚至是 物理裝備，例如機器和打印機），每個代理都執行任務的一小部分並將其傳遞給 由業務規則所確定的下一代理。請考慮批准和支付電子支出報表這一過程。雇員 創建並提交報表，接下來該報表需要由雇員的經理批准（如果美元數目超出了規 定的數目，則需要由另外一級管理部門批准）。接下來到了人力資源部，在那裡 對它進行核查以確定其准確性，還要進行細查以確保該開支是有效的業務支出並 符合公司的政策。如果批准了，將會創建支付請求並安排打印支票。這之後，可 能進入財務部，在那裡單個收費記錄將會應用到適當的帳戶和成本中心。在這些 階段的每一個，支出報表都可能被彈回給雇員或雇員經理。
在構建工作流應用程序過程中，主要設計目標是確保工作能夠從一個代理迅 速地傳入到另一個代理，並確保任務不崩潰。MQ 服務器同數據庫一起攜手工作 ，它使得向您的應用程序中構建靈活、可伸縮、可擴展的工作流處理變得容易。
使用 MQ 以從關鍵路徑去除風險大的操作
在電子商務或供應鏈應用程序中的接收、批准和填寫訂單同工作流應用程序 有許多共同之處，雖然大多數步驟涉及的是電子參與者而不是人。接收並履行訂 單可能會包含下列步驟中的一些或全部：
接收訂單並將其存儲在數據庫中。
對於消費者顧客，驗證信用卡。
對於商業顧客，通過信用報告代理處或通過您公司的信用部門檢查該顧客的 信用。
執行一些欺詐核查分析。
核查庫存。
在有多個履行中心的情況下，決定由哪個中心填寫該訂單。
向顧客發送一封確認電子郵件。
向顧客的銷售代表發送一個通知。
生成挑選列表並將其交付給履行中心。
交付訂單。
向用戶收費並給其開票據。
由於您不想顧客在為獲取確認號碼和收據而單擊“Buy”之後等很久，因此無 論在提交之後執行哪一條代碼，該代碼路徑都應該簡短並且有可預見的執行時間 。但是這些步驟中的許多步驟都需要訪問一些資源，這些資源在客戶下訂單時可 能可用也可能不可用，或者這些資源的響應時間可能無法預料。在這種情況下， 應該從關鍵路徑去除它們；讓訂購的啟動動態設置事件鏈，而通過將提交步驟的 工作減到絕對最小來開始訂單，來盡可能快地使用戶脫離循環。除了將給顧客一 個更好的用戶經歷之外，將訂單處理分成多個離散的（較短）的步驟還改進了資 源利用並減少了競爭 ― 這意味著事務更短（因此鎖定也釋放得更早），並且在 一步（例如網絡和數據庫連接）中所用到的資源也釋放得更早。
在訂單處理過程中，最不可預見的步驟之一是發送確認電子郵件。郵件服務 器經常會擁塞，可能會要好長時間才能接收一條消息，也可能完全拒絕連接。如 果顧客的郵件服務器拒絕確認消息，那麼您就想要稍後重新嘗試發送該消息。這 樣，發送確認電子郵件就“有風險”，這是因為第一次發送可能不成功，或者發 送需要很長時間來處理，而您又不想讓顧客（或有關這件事的任何其它的東西） 一直等到確認到來。類似地，庫存可能存儲在同訂單處理分離的數據庫中（庫存 數據庫可能由一個外包的履行服務擁有），並且在訂購時可能不可用。或者信用 部門可能在星期五不上班。
通過使用消息隊列來存儲暫掛的確認電子郵件、庫存檢查或者信用檢查，您 可以將“有風險的”操作同過程的其余部分分離，因此也使過程的其余部分避免 了操作失敗或花費很長時間的風險。由於每個處理步驟只完成一項簡單的任務， 因而也將極大簡化了每個任務的錯誤處理。
結束語
如果應用得當，消息排隊技術通過將任務分解成子任務，可以極大地簡化復 雜任務的處理，還能增加應用程序的靈活性和可伸縮性。自 J2EE 版本 1.3 起 ，每個 J2EE 容器都將包含一個 JMS 提供程序，這意味著我們都能在我們的應 用程序中利用異步消息排隊的強大功能。
下個月，我們將探索 Java 事務服務（Java Transaction Service (JTS)） 的工作原理了。雖然它不如 EJB 或 J2EE 的其它元素引人注意，但 JTS 可能是 J2EE 的最關鍵部分 ― 事務使我們能夠構建可靠的分布式應用程序。我們將在 今後的某篇專欄文章中重述 MQ，並且構建一個工作流應用程序，以演示消息排 隊和關系型數據庫是如何相互協作和取長補短的。
