作為 MOM 標準的 JMS

Java Messaging Service 規格起初是為了讓 Java 應用程式存取現有的 MOM 系統而開發。自從推出之後，已經為許多現有的 MOM 供應商所採用，本身也已經實作成非同步訊息傳送系統。

設計人員在建立 JMS 規格時，想要擷取現有訊息傳送系統的必要元素。這些元素包括：

• 訊息傳送提供者路由及傳送訊息的概念

• 不同的訊息傳送式樣或網域，例如點對點訊息傳送以及發佈/訂閱訊息傳送

• 同步與非同步訊息接收的設備

• 可靠訊息傳送的支援

• 常用訊息格式，例如串流、文字和位元組

供應商實作 JMS 規格的方式是提供 JMS 提供者，其中包括實作 JMS 介面的程式庫、路由與傳送訊息的功能，以及管理、監視和調校訊息傳送服務的管理工具。路由和傳送功能可透過集中化訊息伺服器或代理程式來執行，或可透過每個用戶端執行階段都具有的功能來實作。

JMS 提供者可同時扮演多種角色：它可以建立作為獨立產品，或作為更大型分散式執行階段系統的內嵌元件。作為獨立產品時，可用於定義企業應用程式整合系統的主網路；而內嵌於應用程式伺服器時，則可支援元件間的訊息傳送。例如， J2EE 使用 JMS 提供者來實作訊息驅動 Bean，讓 EJB 元件得以傳送和接收訊息。

若要建立一套包含所有現有系統功能的標準，可能會造成系統難以瞭解與執行。相反地，JMS 定義了訊息傳送概念和功能的最基本共同點。這讓標準易於瞭解，且讓 JMS 應用程式有最大的可移植性，能悠遊於各 JMS 提供者。請注意，JMS 是 API 標準，不是協定標準。在供應商之間移動 JMS 用戶端很容易。但是不同的 JMS 供應商一般無法直接彼此互相通訊。

下一節將說明 JMS 規格所定義的基本物件和訊息傳送式樣。

JMS 訊息傳送物件和式樣

若要傳送或接收訊息，JMS 用戶端必須先連線到通常作為訊息代理程式實作的 JMS 提供者：開啟用戶端與代理程式之間通訊通道的連線。然後，用戶端必須設定建立、產生和使用訊息的階段作業。您可以將階段作業想成是定義用戶端與代理程式之間特定對話的訊息串流。用戶端本身是訊息產生器和 (或) 訊息用戶。訊息產生器會傳送訊息到代理程式管理的目標。訊息用戶會存取目標以使用訊息。訊息包括標頭、可選特性和內文。內文會保留資料；標頭則包含代理程式需要路由及傳送訊息的資訊；而特性可由用戶端應用程式或提供者定義，以滿足其處理訊息的需求。連線、階段作業、目標、訊息、產生器和用戶是組成 JMS 應用程式的基本物件。

用戶端應用程式藉由這些基本物件，可以使用兩種訊息傳送式樣 (或網域) 來傳送與接收訊息。如圖 1–4 所示。

圖 1–4 JMS 訊息傳送式樣

用戶端 A 和 B 是訊息產生器，經由兩種不同的目標傳送訊息到用戶端 C、 D 和 E。

• 用戶端 A、 C 和 D 之間的訊息傳送可說明點對點的式樣。用戶端可以使用此式樣，傳送訊息到佇列目標，僅讓一個接收者從該目標取得訊息。其他存取該目標的接收者無法取得此訊息。

• 用戶端 B、 E 和 F 之間的訊息傳送可說明發佈/訂閱的式樣。用戶端可以使用此廣播式樣，傳送訊息到主題目標，讓任意多的使用訂閱者從中接收訊息。每個用戶皆可取得各自的訊息副本。

不管是哪個網域，訊息用戶均能選擇同步或非同步取得訊息。同步用戶經由明確的呼叫可擷取訊息，而非同步用戶則可指定回呼方法，呼叫該方法可傳送擱置訊息。用戶也可以指定內送訊息的選取條件，以過濾訊息。

受管理物件

JMS 規格建立一套標準，結合了現有 MOM 系統的許多元素，但並不打算涵蓋所有可能性。相反地，它試圖建立可延伸的方案，以容納差異並得以進一步發展。JMS 讓個別提供者自行決定要如何定義與實作許多訊息傳送元素。這些元素包括負載平衡、標準錯誤訊息、管理 API、安全性、基礎線路協定和訊息存放區。下一節Message Queue：元素和功能將說明 Message Queue 如何實作其中的許多元素，以及如何延伸 JMS 規格。

JMS 未完全定義的訊息傳送元素有兩個：連線工廠和目標。雖然這兩個都是 JMS 程式設計模型中的基本元素，但是提供者定義與管理這些物件的方式存在許多現有和預期的差異，所以不可能也不需要建立共同的定義。因此，這兩個物件不會以程式設計的方式建立，一般會使用管理工具來建立與配置。這兩個物件之後會儲存在物件存放區，並由 JMS 用戶端透過標準 JNDI 查找來存取。

• 連線工廠受管理物件可用於產生用戶端至代理程式的連線。這些物件封裝提供者專用的資訊，以管理訊息傳送運作方式的特定方面：連線處理、用戶端識別、訊息標頭置換、可靠性和流量控制等。源自指定連線工廠的每個連線會以該工廠的配置方式運作。

• 目標受管理物件可用於參照代理程式上的實體目標。這些物件封裝提供者專用的命名 (位址語法) 慣例，並指定使用何種訊息傳送網域以使用目標：佇列或主題。

JMS 用戶端不需要查找受管理物件，而可以透過程式設計建立這些物件 (之後這些物件會儲存在代理程式的記憶體中)。若要有快速參考原型，透過程式設計建立這些物件可能是最簡單的方式。但是若要在生產環境中部署，在中央儲存庫內查找受管理物件，會比較容易控制與管理訊息傳送的運作方式：

• 管理員針對連線工廠物件使用受管理物件，可以經由重新配置這些物件，來調校訊息傳送的效能。不需要重新撰寫程式碼就能改善效能。

• 管理員針對實體目標使用受管理物件，可以經由要求用戶端存取這些預先配置的物件，來控制這些目標不會在代理程式上激增。

• 受管理物件讓開發者不用考量提供者專用的實作細節，讓他們為一個提供者開發的程式碼在不變更或變更很少的情況下，就可移植至其他提供者。

受管理物件為基本的 JMS 應用程式圖片增添了最終的創意，如圖 1–5 所示。

圖 1–5 JMS 應用程式的基本元素

圖 1–5 顯示訊息產生器和訊息用戶如何使用目標受管理物件存取對應的實體目標。標示的步驟表示管理員和用戶端應用程式使用此機制傳送和接收訊息時，需要採取的動作。

使用受管理物件作為目標

1. 管理員在代理程式上建立實體目標。

2. 管理員建立目標受管理物件，並透過指定其對應的實體目標名稱和以下類型進行配置：佇列或主題。

3. 訊息產生器使用 JNDI 查找呼叫，查找目標受管理物件。

4. 訊息產生器傳送訊息到目標。

5. 訊息用戶查找目標受管理物件，期望從中獲取訊息。

6. 訊息用戶從目標取得訊息。

   使用連線工廠受管理物件的程序很類似。管理員使用管理工具建立並配置連線工廠受管理物件。用戶端查找連線工廠物件，並以此建立連線。

   雖然使用受管理物件增加了訊息傳送程序的步驟，但同時也會增強訊息傳送應用程式的牢固性和可移植性。