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