第 1 章 訊息傳送系統：簡介

Sun Java^TM System Message Queue 是一種中介軟體產品，用於實作與延伸 Java Message Service (JMS) 標準的訊息傳送。如果您已經相當瞭解這點，請從Message Queue：元素和功能一節開始閱讀。否則，請從頭開始閱讀。

本章介紹構成 Message Queue 等產品基礎的訊息傳送技術，並解釋 Message Queue 如何實作與延伸標準化此技術的 JMS 規格。涵蓋下列主題：

• 訊息導向中介軟體 (MOM)

• 作為 MOM 標準的 JMS

• Message Queue：元素和功能

• 延展 Message Queue 服務

• Message Queue 作為啟用技術

訊息導向中介軟體 (MOM)

由於企業、機構和技術持續演變，為其提供服務的軟體系統必須能夠因應演變的趨勢。企業可能因為合併、新增服務或擴充可用的服務，而急需重建企業資訊系統。在此迫切的情況下，企業需要整合新的元件或儘可能有效地延展現有的元件。整合異質元件最簡單的方法並非將其重建為同質元素，而是提供一個層級，使其可以無視差異進行通訊。此層級稱為中介軟體，可讓獨立開發及在不同網路平台上執行的軟體元件 (應用程式、Enterprise Java Bean、Servlet 和其他元件) 彼此互動。當此互動成為可能時，網路就能變成電腦。

如圖 1–1 所示，中介軟體介於應用程式層與平台層 (作業系統與基礎網路服務) 之間。

圖 1–1 中介軟體

分散於不同網路節點的應用程式會使用應用程式介面進行通訊，而不用考量執行其他應用程式的作業環境細節，也不用考量將其連線到這些應用程式的服務。此外，藉由提供管理介面，這種新型虛擬的互連應用程式系統非常可靠安全。其效能可以測量和調校，並且可以在不遺失功能的情況下進行延展。

中介軟體可以分為下列種類：

• 遠端程序呼叫 (RPC 型) 中介軟體，這可允許應用程式中的程序像呼叫本機程序那樣呼叫遠端應用程式中的程序。該中介軟體執行連結機制，尋找遠端程序並使其可供呼叫者使用。在過去，這類中介軟體會處理程序型程式，現在它還可包含物件型元件。

• 物件請求代理程式 (ORB 型) 中介軟體，可使應用程式的物件在異質網路上進行分發與共用。

• 訊息導向 (MOM 型) 中介軟體，可讓分散的應用程式透過傳送與接收訊息，進行通訊與交換資料。

所有這些模型均可以透過網路，使一個軟體元件影響另一個元件的運作方式。不同之處在於 RPC 型和 ORB 型中介軟體會建立元件緊密耦合的系統，而 MOM 型系統則允許耦合較鬆散的元件。在 RPC 或 ORB 型系統中，當一個程序呼叫另一個程序時，必須等候被呼叫的程序傳回，才能夠進行其他工作。如前所述，在這些模型中，中介軟體的部分功能是超級連結程式，在網路上尋找被呼叫程序，並使用網路服務傳送函數或方法參數至此程序，然後再傳回結果。

MOM 型系統可透過非同步交換訊息來進行通訊，如圖 1–2 所示。

圖 1–2 MOM 型系統

訊息導向中介軟體利用訊息傳送提供者協調訊息傳送作業。MOM 系統的基本元素為用戶端、訊息和 MOM 提供者 (包含 API 和管理工具)。MOM 提供者會使用不同的架構來路由和傳送訊息：它可以使用集中化訊息伺服器，或者將路由和傳送功能分發給每部用戶端電腦。部分 MOM 產品則結合這兩種方法。

使用 MOM 系統時，用戶端會發出 API 呼叫，將訊息傳送至提供者管理的目標。此呼叫會呼喚提供者服務來路由和傳送訊息。用戶端可在傳送訊息後繼續其他作業，確信提供者會保留訊息直到接收的用戶端接收到訊息為止。此訊息型模型會耦合提供者的協調，以便有可能建立元件鬆散耦合的系統。這類系統即使在個別元件或連線失敗時，還能夠可靠地繼續運作，而不會當機。

讓訊息傳送提供者協調用戶端之間的訊息傳送還有一個優點，就是透過增加管理介面，得以監視並調校效能。因此，除了傳送、接收及處理訊息問題之外，用戶端應用程式能有效解決每個問題。若要解決互通性、可靠性、安全性、延展性和效能等問題，需視執行 MOM 系統的程式碼以及管理員而定。

到目前為止，我們已描述了使用訊息導向中介軟體連接分散式元件的優點。但是也有缺點：其中一個缺點源於鬆散耦合本身。使用 RPC 系統，要等到被呼叫的函數完成其工作後，才會傳回提出呼叫的函數。在非同步系統中，呼叫的用戶端可以繼續接收載入工作，直到需要處理此工作的資源耗盡且被呼叫的元件失敗為止。當然，透過監視效能和調整訊息流量可減少或避免這些狀況，但是，這不是 RPC 系統的必要工作。重要的是瞭解每種系統的優點和職責。各個系統適用於不同的工作。有時，需要結合兩種系統才能取得需要的實際運作方式。

圖 1–3 顯示 MOM 系統如何啟用兩種 RPC 型系統之間的通訊。圖的左側顯示將用戶端、伺服器和資料存放區元件分發到不同網路節點，以改善效能的應用程式。這是折扣航空訂位系統：一般使用者付費使用此服務，指定目的地和時間以尋找最便宜的機票。資料存放區會保留參與此程式的註冊使用者和航空公司之相關資訊。根據使用者的請求，伺服器會依邏輯操作，詢問參與航空公司的價格、排序資訊，然後向使用者顯示最便宜的三家航空公司。圖的右側顯示的 RPC 型系統，表示任何一家使用該系統的航空公司訂票/訂位系統。圖的右側將會視折扣程式連線到航空公司的數量重複。對於各家這類航空公司，資料存放區可保留可訂位航班的資訊 (座次、航班時間和票價)。伺服器元件會回應一般使用者輸入的資料來更新該資訊。航空公司的伺服器也可訂閱 MOM 服務，接受來自折扣訂位系統的資訊請求，並傳回座次和票價資訊。如果客戶決定購買 PanWorld 航空公司的折扣機票，該系統的伺服器元件會更新資料存放區的資訊，然後開出請求者的機票，或傳送訊息到折扣服務以開出機票。

圖 1–3 結合 RPC 和 MOM 系統

此範例描述 RPC 系統和 MOM 系統之間的一些差異。分散式元件耦合方式的不同之處，在前面已有所說明。還有一項差異是 RPC 系統通常用於分發與連接用戶端元件和伺服器元件，其中用戶端通常是一般使用者；而對於 MOM 系統，用戶端通常是異質軟體元件，僅能透過訊息傳送的方式互通。

MOM 系統有一個較為嚴重的問題，即 MOM 是實作為專用產品。當依賴 SuperMOM-X 的公司併購使用 SuperMOM-Y 的公司時，會發生什麼事？要有標準的訊息傳送介面才能解決此問題。如果 SuperMOM-X 和 SuperMOM-Y 均實作此介面，則開發為可在其中一個系統上執行的應用程式，也可以在另一個系統上執行。這類介面應該簡單易懂，卻又能提供足夠的功能，以支援複雜的訊息傳送應用程式。1998 年推出的 Java Message Service (JMS) 規格即為此應運而生。下一節將描述 JMS 的基本功能，並說明該標準的開發方式，如何涵蓋現有專用 MOM 產品的一般元素，以及允許差異性和未來發展。

作為 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. 訊息用戶從目標取得訊息。

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

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

Message Queue：元素和功能

到目前為止，我們已說明訊息導向中介軟體的元素，以及使用 JMS 增加 MOM 應用程式的可移植性。接下來要說明 Message Queue 如何實作 JMS 規格，並介紹其用於提供可靠、安全和可延展訊息傳送服務的功能與工具。

首先，和許多 JMS 提供者一樣，Message Queue 可以作為獨立產品，也可以用作內嵌在 J2EE 應用程式伺服器的啟用技術，以提供非同步的訊息傳送。第 5 章, Message Queue 和 J2EE對 Message Queue 在 J2EE 中所扮演的角色會有更詳盡的說明。與其他 JMS 提供者不同的是，Message Queue 已指定為 JMS 參照實作。此指定證明了 Message Queue 是正確完整的 JMS 實作。亦保證未來的 JMS 修訂和延伸可以繼續使用 Message Queue 產品。

Message Queue 服務

作為 JMS 提供者，Message Queue 提供訊息傳送服務，該服務實作 JMS 介面並提供管理服務與控制。到目前為止，在對 JMS 提供者的說明中，我們一直著重於代理程式在轉送訊息時所扮演的角色。但事實上，JMS 提供者必須包括除代理程式以外的許多元素，以提供可靠、安全、可延展的訊息傳送。圖 1–6 顯示組成 Message Queue 訊息服務的元素。這些元素包含多種連線服務 (支援不同的協定)、管理工具和資料存放區，以傳送訊息、監視和處理使用者資訊。Message Queue 服務本身包含圖中以灰色標記的所有元素。

圖 1–6 Message Queue 服務

如您所見，功能完整的 JMS 提供者的複雜程度超出基本 JMS 模型甚多。下列各節將說明上述的 Message Queue 服務元素。這些元素可分為三類：代理程式、用戶端執行階段支援和管理。

連線至代理程式

如圖 1–6 所示，應用程式用戶端和管理用戶端均可連線到代理程式。JMS 規格並未規定提供者必須實作任何特定的線路協定。應用程式用戶端和管理用戶端用於連線到代理程式的 Message Queue 服務，目前位於 TCP、TLS、HTTP 或 HTTPS 協定的最上層。(位於 HTTP 最上層的服務可讓訊息通過防火牆。)

• 提供 JMS 支援並可讓用戶端連線到代理程式的服務 (jms、ssljms、http 或 https) 類型為 NORMAL，並位於 TCP、TLS、HTTP 或 HTTPS 協定的最上層。

• 可讓管理員連線到代理程式的服務 (admin、ssladmin) 類型為 ADMIN，並位於 TCP 或 TLS 協定的最上層。

依預設，啟動代理程式時，jms 和 admin 服務會啟動並執行。此外，您可以將代理程式配置為執行這些連接服務的任何一種或全部。每個服務支援特定的認證與授權 (存取控制) 功能，且每個服務為多重執行緒作業，支援多重連線。

如果連線失敗，Message Queue 服務會自動重新嘗試將用戶端連線至同一個代理程式，或連線至其他代理程式 (如果已啟用此功能)。如需更多資訊，請參閱附錄 BMessage Queue 功能 中關於自動重新連線功能的描述。

用戶端可以在建立連線工廠以取得連線時，配置連線執行階段支援。選項可讓您指定代理程式連線的目標、如何處理重新連線、訊息流量控制等。如需有關連線配置方式的其他資訊，請參閱連線工廠與連線。

代理程式

代理程式是訊息服務的核心，可以可靠地路由和傳送訊息、認證使用者，並收集用於監視效能的資料。

• 為了路由及傳送訊息，代理程式會將內送訊息置於其各自的目標，並管理進出這些目標的訊息流量。

• 為了提供可靠的傳送，代理程式會使用永久性存放區來儲存狀態資訊和永久性訊息 (直到訊息被接收為止)。如果代理程式或連線失敗，儲存的資訊會讓代理程式復原代理程式的狀態，然後重試作業。

• 為了提供所交換資料的安全性，代理程式會使用經過認證的連線。也可以經由 SSL 之類的安全協定，執行資料加密。代理程式還會使用並管理儲存庫，以保留使用者資訊以及使用者可以存取的資料或作業。代理程式會查找此儲存庫內的資訊，以認證請求服務的使用者，並授權使用者想要執行的作業。

• 為了監視系統，代理程式會產生度量和診斷資訊供管理員存取，以測量效能並調校代理程式。度量資訊亦可透過程式設計的方式取得，以允許應用程式調整訊息流量和式樣來改善效能。

Message Queue 服務提供多種管理工具，管理員可用於配置代理程式支援。如需更多資訊，請參閱管理。

用戶端執行階段支援

建立 Message Queue 用戶端時，所連結的程式庫便會提供用戶端執行階段支援。您可以將用戶端執行階段想像為 Message Queue 服務變成為用戶端一部分的一個階段。例如，當用戶端程式碼呼叫 API 傳送訊息時，會呼叫這些程式庫中的程式碼，以便用適當方式為協定封裝訊息位元，而此協定將用於將訊息轉送至代理程式上的實體目標。

Java 和 C 用戶端支援

只有支援 Java 用戶端時才需要 JMS 提供者；但是，如圖 1–6 所示，Message Queue 用戶端可以使用 Java 或提供者專用的 C API，傳送或接收訊息。這些介面是在 Java 或 C 執行階段程式庫中實作，會執行建立代理程式連線與依據連線服務請求封裝位元的實際工作。

• Java 用戶端執行階段提供 Java 用戶端與代理程式互動所需的物件。這些物件包括連線、階段作業、訊息、訊息產生器與訊息用戶。

• C 用戶端執行階段提供 C 用戶端與代理程式互動所需的功能和結構。它支援 JMS 程式設計模型的程序版本。C 用戶端無法使用 JNDI 來存取受管理物件，但是可以透過程式設計建立連線工廠和目標。

Message Queue 服務提供 C API，使舊版 C 和 C++ 應用程式能參與 JMS 型訊息傳送。這兩種 API 所提供的功能中有許多不同之處，會在Java 用戶端與 C 用戶端中進行說明。

請謹記， JMS 規格是僅限於 Java 用戶端使用的標準。C 支援是 Message Queue 提供者專用的支援，不能用於計劃移植到其他提供者的用戶端應用程式。

Java 用戶端的 SOAP 支援

Message Queue Java 用戶端也可以傳送和接收包裝成 JMS 訊息的 SOAP 訊息。SOAP (簡易物件存取協定) 允許在分散式環境中的兩個對等端之間交換結構化資料。交換的資料由 XML 機制指定。

Sun SOAP 處理目前限制為使用點對點模型，且不保證可靠性。您可以將 SOAP 訊息包裝在 JMS 訊息中，並使用代理程式路由該訊息，這樣就可利用完整功能的 Message Queue 訊息傳送以保證可靠的傳送，並能使用主題及點對點網域。Message Queue 提供公用程式常式，讓訊息產生器將 SOAP 訊息包裝到 JMS 訊息中，也可以讓訊息用戶從 JMS 訊息擷取 SOAP 訊息。

使用 SOAP 訊息為您提供有關 SOAP 訊息處理更加詳細的說明。

管理

Message Queue 服務提供指令行工具，可用於執行下列作業：

• 啟動並配置代理程式。

• 建立並管理目標、管理代理程式連線，以及管理代理程式資源。

• 在 JNDI 物件存放區中增加、列出、更新和刪除受管理物件。

• 寫入和管理檔案式使用者儲存庫。

• 建立和管理用於永久性存放區的 JDBC 相容資料庫。

您也可以使用 GUI 型管理主控台，以執行下列指令行功能：

• 連接至代理程式並進行管理。

• 建立和管理實體目標。

• 連線到物件存放區、將物件增加到存放區，以及管理這些物件。

延展 Message Queue 服務

隨著用戶端數目或連線數量的增加，您可能需要延展訊息服務，以突破瓶頸或改善效能。Message Queue 訊息服務會依照您的需求提供多種延展選項。為方便起見，這些選項可分為下列種類：

• 垂直延展的方式是增加更多處理能力及擴充可用資源。方法是增加更多處理器或記憶體、切換至共用執行緒模型，或以 64 位元模式執行 Java VM。

  如果您使用點對點網域，可以藉由允許多個用戶存取佇列，來延展用戶端。使用這種方式，可以指定使用中和備份用戶的最大數目。負載平衡機制也會考慮用戶的目前處理能力與訊息處理率。這屬於 Message Queue 功能。(JMS 規格定義僅有一個用戶存取佇列的訊息傳送運作方式；允許多個用戶的佇列運作方式隨提供者而定。Message Queue 開發者指南提供此延展選項的更多資訊。)

• 無狀態水平延展的方式是增加代理程式，並重新分發現有的用戶端到這些代理程式。此方式易於執行，但是僅在訊息傳送作業可以劃分為獨立的工作群組時才適用。

• 狀態水平延展的方式是將代理程式連線到叢集中。在代理程式叢集中，每個代理程式都會連線到叢集中的其他代理程式，亦會連線到其本機應用程式用戶端。代理程式可位於相同的主機或分散在網路中不同的主機。有關目標和用戶的資訊會複製到叢集中的所有代理程式上。目標或訂閱者的更新也會進行傳播，因此每個代理程式可以從產生器路由訊息到其直接連線到用戶的代理程式，而這些用戶是連線到叢集的其他代理程式。在使用備份用戶的情況下，如果代理程式或連線失敗，則傳送到無法存取的用戶之訊息，會轉寄至其他代理程式上的備份用戶。

  如果代理程式或連線失敗，有關永久性實體 (目標和長期訂閱) 的狀態資訊可能會不同步。例如，如果叢集代理程式失敗，且在叢集的其他代理程式上建立目標，則當第一個代理程式重新啟動時，將不知道這個新目標。若要避免此問題，可以將叢集中的某個代理程式指定為主代理程式。此代理程式負責追蹤主配置檔案中對目標和長期訂閱的所有變更，並且負責更新叢集中暫時離線的代理程式。如需更多資訊，請參閱第 4 章, 代理程式叢集。

  若是代理程式或連線失敗，即使使用主代理程式，Message Queue 也只提供服務可用性，而不會提供資料可用性。例如，若是叢集代理程式變成無法使用，代理程式所保留的任何永久性訊息都會變成無法使用，直到代理程式回復為止。目前確保資料可用性的唯一方法，是透過使用 SunCluster Message Queue 代理程式。在這種情況下，永久性存放區會位於共用檔案系統上。如果代理程式失敗，則第二個節點上的 Message Queue 代理程式會啟動某個代理程式，來接管共用存放區。用戶端會重新連線到該代理程式，並由此繼續取得服務及存取永久性資料。

Message Queue 作為啟用技術

Java 2 Platform, Enterprise Edition (J2EE 平台) 是一種 Java 程式設計環境中分散式元件模型的規格。J2EE 平台的一個要求是，分散式元件必須能夠透過可靠的非同步訊息交換而彼此互動。此功能由 JMS 提供者提供，它有兩個作用：提供服務和支援訊息驅動 Bean (MDB)，這是一種可使用 JMS 訊息之特殊類型的 Enterprise Java Bean (EJB) 元件。

J2EE 相容應用程式伺服器必須使用指定 JMS 提供者提供的資源介面，才能使用該提供者的功能。Message Queue 提供這類資源介面。藉由使用外掛 JMS 提供者的支援，在應用程式伺服器環境中部署並執行的 J2EE 元件 (包括 MDB)，可以在這些元件間與外部 JMS 元件間交換 JMS 訊息。這提供分散式元件的強大整合功能。

如需有關 Message Queue 資源介面的資訊，請參閱第 5 章, Message Queue 和 J2EE。

Message Queue 功能摘要

Message Queue 的功能遠超出了 JMS 規格的需求。這些功能可讓 Message Queue 與由大量分散式元件組成的系統整合，可在全天候的關鍵任務作業中交換數以萬計的訊息。如需這些功能的摘要，請參閱附錄 BMessage Queue 功能。