|
| |
| Sun Java System Message Queue 3 2005Q1 技術概述 | |
第1章
概念基礎Sun Java™ System Message Queue (Message Queue) 提供可靠的非同步訊息傳送 ，能整合企業中的分散式應用程式及元件。在不同平台和作業系統上執行的程序可連線至此服務來進行互動。
Message Queue 是基於標準的訊息傳送解決方案，其實作 Java™ Message Service (JMS) 開放式標準。此外，Message Queue 提供互通性、安全性、延伸性、可用性、可管理性和其他大規模企業部署所需的功能。
本章提供 Message Queue 的概念基礎。它涵蓋以下主題：
如果您已熟悉 JMS 的概念和術語，您可跳至第 2 章「Message Queue 簡介」。
企業訊息傳送系統企業訊息傳送系統可讓獨立的分散式應用程式或應用程式元件透過訊息互動。這些元件 (無論是在同一主機、同一網路上執行，還是透過網際網路鬆散地連線在一起) 均使用訊息傳送來傳輸資料以及協調各自的功能。
為使大量元件能夠同時交換訊息，並支援高密度流量，訊息傳送不能取決於用戶是否可以接收訊息。如果訊息用戶忙碌或離線，系統必須能讓訊息在用戶準備就緒時被接收。這樣的訊息傳送和接收的去耦合便是所謂的非同步訊息傳送。
非同步訊息模型在整合複雜系統的工作上提供優越的性能，在執行工作時元件不用也不需保留其他元件。由於非同步訊息放棄某些同步訊息系統允許的控制，它大大增加了元件相互作用的靈活性。它也增加了強健性，只有一個元件的故障並不會轉變成全部故障。
企業訊息傳送系統的要求
企業應用程式系統一般包含大量的分散式元件，這些元件在全天候的關鍵任務作業中交換數以萬計的訊息。若要支援此類系統，除了支援非同步訊息外，企業訊息傳送系統通常必須滿足以下要求：
可靠的傳送。 從一個元件傳送至另一個元件的訊息不能由於網路或系統故障而遺失。這意味著系統必須能夠保證傳送訊息。
安全性。 訊息傳送系統必須支援基本的安全性功能：使用者認證、訊息和資源的授權存取以及線上加密。
延伸性。 訊息傳送系統必須能夠在不降低效能或訊息流量的情況下，適應不斷增加的負載，即不斷增多的使用者和訊息數目。隨著商業和應用程式規模的擴大，這將成為一項重要的要求。
可用性。 訊息傳送系統必須很少發生運作當機。這表示當故障發生時，系統含有足夠的容錯性能繼續提供訊息傳送服務。
可管理性。 訊息傳送系統必須提供監視和管理訊息傳送的工具。管理員必須能最佳化系統資源和調校系統效能。
集中式 (MOM) 訊息
Message Queue 使用集中式訊息傳送系統，如圖 1-1 中所示。在此系統中，每個訊息傳送元件只需與一個中央訊息服務保持連線。元件透過定義完善的介面與訊息服務進行互動。
一個替代的點對點系統，其中每個訊息傳送元件與其他所有元件均保持連線，如左圖中的說明。點對點系統允許快速、安全且可靠的傳送；但是支援可靠性和安全性的程式碼必須駐留在每個元件中。訊息的傳送和接收緊密耦合，使得非同步傳送很難實現。隨著將元件不斷地加入系統，連線數目將成幾何級增加，因此系統的延伸性很差。在點對點系統中的集中式管理也會出現問題。
圖 1-1 集中式訊息傳送和點對點訊息傳送
在集中式系統中，企業訊息傳送的首選方法是，訊息服務提供元件之間的訊息傳送和路由，並負責可靠傳送及安全性。因為在此系統中的元件無密切關聯，非同步訊息傳送可輕易實現。
隨著將元件不斷地加入系統，連線的數目線性增長，這樣就可以透過調整訊息服務來更輕鬆地調整系統。除了連線訊息傳送用戶端之外，中央訊息服務也提供管理介面以配置運作方式、監督效能及調校服務以滿足每個訊息傳送用戶端要求。
基本訊息服務架構
集中式訊息傳送系統的基本架構如圖 1-2 所示。它包含訊息產生者和訊息用戶，兩者透過共用訊息服務來交換訊息。任何數目的訊息產生者和用戶均可駐留在同一個訊息傳送元件 (或應用程式) 中。
訊息產生者使用訊息服務程式設計 API 傳送訊息至訊息伺服器。訊息伺服器路由與傳送訊息至一個或多個已註冊接收此訊息的訊息用戶。用戶使用訊息服務程式設計 API 接收訊息。訊息服務負責保證將該訊息傳送至所有相應的用戶。
圖 1-2 訊息服務架構
也許對這個程序最好的比喻是交換郵件。雖然一封郵件最後終會寄到收件人手中，但它在收件人從郵箱中取出前曾繞經郵局、並停留在數個中繼站中。
Java Message Service (JMS) 基本資訊Message Queue 是實作 Java Message Service (JMS) 開放式標準的企業訊息傳送系統。它是一個 JMS 提供者。所以 JMS 概念對於理解 Message Queue 服務的工作原理很重要。
JMS 規格規定了一組管理可靠的、非同步的訊息傳送的規則和語義。該規格指定訊息結構、程式設計模型和 API。
本節說明了理解本書其餘各章所需的 JMS 概念和術語。它涵蓋以下主題：
JMS 訊息結構
在 Message Queue 中，資料的交換使用 JMS 訊息。依據 JMS 規格，由產生用戶端所建立的訊息由以下三部分組成：標頭、特性和內文。
標頭
每個 JMS 訊息都需要標頭。標頭欄位包含用來路由和辨別訊息的值。
標頭值可以數個方法來設定：
關於 JMS 所定義的標頭欄位的詳細資訊，請參閱「Message Queue Developer's Guide for Java Clients」或「Message Queue Developer's Guide for C Clients」。標頭欄位能讓您定義訊息目標、到期時間、優先順序等等。
特性
訊息可包含選擇性的標頭欄位，這些稱為特性。它們被指定為特性名稱及特性值對。特性，可想成訊息標頭的延伸，可包含關於資料由什麼程序建立、建立的時間以及每個資料的結構等資訊。JMS 提供者也可加入影響訊息處理的特性，例如訊息該如何壓縮或在使用終了時如何銷毀。
JMS 提供者可使用訊息特性如選擇器將訊息排序和路由。生產型用戶端可在訊息中放入應用程式特定的特性，使用型用戶端可以選擇只接收某些特定特性值的訊息。例如，使用型用戶端可指明只對在 New Jersey 州的兼差員工的薪資訊息有興趣。不符合指定選取條件的訊息將不會傳送到用戶端。
選擇器簡化使用型用戶端的工作，並消除了不需要這些訊息的用戶端傳送訊息的耗用時間。但是，它們也使得處理選取條件的訊息服務增加了一些耗用時間。JMS 規格中對訊息選擇器的語法和語義進行了概述。
訊息內文類型
JMS 訊息的類型決定內文的內容，如表 1-1 中所指定。
JMS 程式設計模型
JMS 程式設計模型支援非同步訊息傳送服務的架構：JMS 用戶端經由 JMS 訊息服務交換訊息。JMS 提供者提供執行 JMS 訊息傳送所需要的物件；這些物件實作 JMS 應用程式設計介面 (API)。
本節說明 JMS 訊息傳送所需的程式設計物件並介紹用來傳送和接收訊息的傳送模型 (點對點與出版/訂閱)。
程式設計物件
設定 JMS 用戶端傳送訊息所需的物件，如圖 1-3 中所示。
圖 1-3 JMS 程式設計物件
在 JMS 程式設計模型中，JMS 用戶端使用連線工廠物件 (ConnectionFactory) 建立一個連線，將訊息傳送至 JMS 訊息服務以及從 JMS 訊息服務接收訊息均透過此連線進行。連線物件 (Connection) 代表用戶端與訊息伺服器的使用中連線。
通訊資源的分配以及用戶端的認證均在建立連線時進行。相對而言，這是一個十分重要的物件，大多數用戶端均使用單一連線來進行所有的訊息傳送。
連線用於建立階段作業物件 (Session)。階段作業是用於生產和使用訊息的單執行緒環境。它用於建立訊息以及傳送和接收訊息的訊息產生者和用戶，並為所傳送的訊息定義傳送順序。階段作業透過大量的確認選項或作業事件，支援可靠的傳送。
用戶端使用訊息產生者物件 (MessageProducer) 將訊息傳送至指定實體目標，在 API 中表示為目標物件。訊息產生者可指定預設訊息標頭值，例如傳送模式 (永久性與非永久性)、優先順序和存在時間值，以控制由產生者傳送至實體目標的所有訊息。
同樣，用戶端使用訊息用戶物件 (MessageConsumer) 從指定實體目標 (在 API 中表示為目標物件) 接收訊息。有兩種類型的目標，佇列和主題，取決於訊息傳送模型。
訊息用戶可以使用訊息選擇器，該選擇器可令訊息服務僅將符合選取條件的訊息傳送至訊息用戶。
訊息用戶可以支援同步或非同步的訊息使用。
程式設計網域：訊息傳送模型
JMS 支援兩種完全不同的訊息傳送模型：點對點與出版/訂閱。
點對點 (佇列目標) 將訊息從產生者傳送至單一用戶。在此傳送模型中，目標類型為佇列。首先將訊息傳送至佇列目標，然後將訊息從該佇列傳送至已向佇列註冊的一個用戶，每次傳送一封訊息。可以向佇列目標傳送訊息的產生者沒有限制，但每封訊息只能傳送至一個用戶，並由一個用戶成功接收。如果沒有向佇列目標註冊的用戶，佇列將保留其接收到的訊息，並在用戶向該佇列註冊時將訊息傳送給他們。
出版/訂閱 (主題目標) 將訊息從產生者傳送至任意數目的用戶。在此傳送模型中，目標類型為主題。訊息被首先傳送至主題目標，然後傳送至已訂閱該主題的所有使用中用戶。可以向主題目標傳送訊息的產生者沒有限制，並且每封訊息可以被傳送至任意數目的訂閱用戶。
主題目標也支援長期訂閱。長期訂閱表示用戶已向主題目標進行註冊，但在訊息到達目標時此用戶可以處於非作用狀態。當用戶再次處於使用中時，將接收此訊息。如果沒有用戶向主題目標進行註冊，則主題將只保留非使用中用戶長期訂閱的訊息。
這兩種訊息傳送模型使用表示不同程式設計網域的三組 API 物件 (語義稍有差異) 進行處理，如表 1-2 中所示。
表 1-2 JMS 程式設計網域及物件
基本類型 (統一網域)
點對點網域
出版/訂閱網域
Destination (Queue 或 Topic)1
Queue
Topic
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
1取決於程式設計的方法，您必須指定特定的目標類型。
統一網域已在 JMS 版本 1.1 中說明過。如果您需要符合較早的 JMS 1.02b 規格，您可以使用網域特定的 API。使用網域特定的 API 也提供清理程式設計介面的優點，可以避免特定類型的程式設計錯誤：例如，為佇列目標建立長期訂閱。然而，網域特定 API 的缺點是您不能在同一作業事件或同一作業階段中結合點對點和出版/訂閱作業。如果您需要執行這些動作，您應該選擇統一網域的 API。
Message Queue 產品包含的範例應用程式以及 Message Queue 文件中提供的程式碼範例，均使用單獨程式設計網域。
可靠的訊息傳送
訊息的傳送模式可設成永久性或非永久性；此模式控制訊息傳送的可靠性。
對於永久性訊息，確保可靠性有兩個方面。一個是要確保，透過使用確認和作業事件，成功的產生和使用訊息。另一個是要確保將訊息放進永久性儲存，讓訊息服務在將永久性訊息傳送至用戶之前不會遺失訊息。
以下各節描述確保可靠性的兩個方面。
確認/作業事件
可靠的訊息傳送取決於確保從訊息產生者至訊息伺服器上的實體目標和來自實體目標至訊息用戶的永久性訊息的成功傳送。可使用 JMS 階段作業支援的兩個一般機制中的任何一個來達到可靠性的目標，這兩個機制是：確認或作業事件。作業事件可以是本地作業事件或分散式作業事件 (由分散式作業事件管理程式控制)。
確認
確認是用來確保傳送在用戶端和訊息服務間的訊息之可靠性。
在訊息產生的情況下，訊息服務確認收到傳送的訊息、放置訊息至它的目標以及永久儲存訊息。產生者的 send() 方法暫停運作直到傳回確認為止。
在訊息使用的情況下，訊息服務從目標刪除訊息之前，用戶端確認收到從目標傳送的訊息並加以使用。JMS 指定不同的確認模式來代表不同程度的可靠性。在這些模式中的某部份，用戶端暫停運作以等待訊息伺服器確認已刪除訊息，並因此而無法重新傳送訊息。
本地作業事件
也可以將階段作業配置為作業事件，這樣就可以將一個或多個訊息的生產和/或使用群組為不可分割的單元，即作業事件。JMS API 提供了啟動、確定或回復作業事件的方法。
在作業事件中生產或使用訊息時，訊息服務會追蹤各種傳送和接收過程，並在 JMS 用戶端發出確定作業事件的呼叫時完成這些作業。如果作業事件中特定的傳送或接收作業失敗，則會出現異常。用戶端程式碼可以透過忽略異常、重試作業或回復整個作業事件來處理異常。在作業事件確定後，將完成所有的作業。在作業事件回復後，將取消所有成功的作業。
本地作業事件的範圍始終是單一階段作業。即，可以將單一階段作業的環境中執行的一個或多個產生者或用戶作業群組為一個本地作業事件。
由於作業事件僅能是單一階段作業，因此不能有同時包含訊息生產和訊息使用的端對端作業事件。(換言之，至目標的訊息傳送和後續的至用戶端的傳送不能放在同一個作業事件中。)
分散式作業事件
JMS 規格也支援分散式作業事件。即，訊息的生產和使用可作為較大的分散式作業事件的一部分，其中包括涉及其他資源管理程式 (如資料庫系統) 的作業。在分散式作業事件中，分散式作業事件管理程式使用 Java Transaction API (JTA)、XA 資源 API 規格中定義的兩階段確定協定，追蹤和管理多個資源管理程式 (如訊息服務和資料庫管理程式) 執行的作業。在 Java 中，JTA 規格描述了資源管理程式和分散式作業事件管理程式之間的互動。
支援分散式作業事件表示，訊息傳送用戶端可以透過 JTA 定義的 XAResource 介面參與分散式作業事件。此介面定義了實作兩階段確定的許多方法。當用戶端進行 API 呼叫時，JMS 訊息服務僅與分散式作業事件管理程式 (由 Java Transaction Service (JTS) 提供) 協作，來追蹤分散式作業事件中的各種傳送和接收作業以及作業事件狀態，並完成訊息傳送作業。
處理本地作業事件時，用戶端可以透過忽略異常、重試作業或回復整個分散式作業事件來處理異常。
永久性儲存
可靠性的另一個方面是，確保訊息服務在將永久性訊息傳送至用戶之前不會遺失訊息。這表示當永久性訊息到達它的實體目標時，訊息伺服器必須將它放在永久的資料儲存。如果訊息伺服器由於某種原因失敗，它可以回復該訊息並將其傳送至相應的用戶。
訊息伺服器還必須永久儲存長期訂閱。否則如果訊息伺服器發生故障，它將無法將訊息傳送至在訊息抵達主題目標後成為使用中狀態的長期訂閱者。
需要保證訊息傳送的訊息應用程式必須將訊息指定為永久性訊息，並傳送至主題目標的長期訂閱或佇列目標。
JMS 受管理物件
在 JMS 程式設計模型中使用的兩個物件，連線工廠和目標，會因提供者實作的 JMS 規格而有所不同。
為了讓提供者在定義這些物件上有最大靈活性並讓用戶端可移植，JMS 規格定義了受管理物件 (針對連線工廠和目標) 可封裝提供者特定的資訊。這些物件由管理員建立和配置，儲存在 JNDI 名稱空間中 (物件儲存)，並由用戶端透過標準的 JNDI 查找程式碼存取。
受管理物件可讓 JMS 用戶端使用邏輯名稱查找和參照提供者特定的物件。這樣，用戶端程式碼無需瞭解提供者使用的特定命名語法、尋址語法或配置特性。從而使程式碼獨立於提供者之外。
受管理物件一節提供關於用在 Message Queue 中的管理物件的額外資訊。
