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

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

本章描述訊息傳送技術，將說明 Message Queue 等產品，解釋 Message Queue 的執行方式，並擴充標準化此技術的 JMS 規格。本節涵蓋下列主題：

訊息導向中介軟體 (MOM)

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

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

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

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

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

訊息導向中介軟體或 MOM 型中介軟體：透過傳送與接收訊息，允許分散的應用程式進行通訊與交換資料。

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

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

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

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

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

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

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

此範例描述 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 介面的程式庫；路由與傳送訊息的功能；以及管理、監視和調整訊息傳送服務的管理工具。路由和傳送功能可透過集中化訊息伺服器或代理程式來執行，或可透過每個用戶端執行階段的部份功能來執行。

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

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

JMS 訊息傳送物件和模式

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

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

用戶端 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 顯示訊息產生者和訊息用戶如何使用目標管理物件存取對應的實體目標。標示的步驟表示管理員和用戶端應用程式使用此機制傳送和接收訊息時，需要採取的動作。

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

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

訊息產生者使用 JNDI 查找呼叫，查找目標管理物件。

訊息產生者傳送訊息到目標。

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

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

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

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

Message Queue：元素和功能

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

首先，Message Queue 和許多 JMS 提供者一樣，可以用作獨立產品，也可以用作內嵌在 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 服務包括圖中灰階標示的所有元素。

根據所見基本 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 服務會自動重新嘗試將用戶端連線至同一個代理程式，或連線到其他代理程式 (如果已啟用此功能)。如需詳細資訊，請參閱附錄 B「Message 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 訊息傳送處理更加詳細的說明。

管理

啟動並配置代理程式。

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

在 JNDI 物件存放區中新增、列示、更新和刪除管理物件。

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

建立和管理用於永久儲存的 JDBC 相容資料庫。

調整 Message Queue 服務

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

如果您使用點對點網域，可以藉由允許多個用戶存取佇列，來調整用戶端。使用這種方式，可以指定使用中和備份用戶的最大數目。負載平衡機制也會考慮用戶的目前處理能力與訊息處理率。這屬於 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 有兩個可用版本：企業版與平台版。兩個版本都提供完整的 JMS 規格執行，但每個版本都對應到不同的功能集與授權容量。

HTTP 與 HTTPS 支援

C 用戶端支援

可延伸的連線功能

代理程式叢集

每個佇列可以向不限數量的訊息用戶發送佇列。(平台版限制每個佇列傳送到三個用戶。)

用戶端連線容錯移轉到叢集中的其他代理程式。

訊息型監視 API

Message Queue 企業版依據所使用的 CPU 數量，具有不受期限的授權。授權未對多重代理程式訊息服務中的代理程式數目做出限制。

Message Queue 平台版未對代理程式所支援的用戶端連線做出數目限制。它提供基本授權或 90 天的試用授權：

基本授權沒有期限限制，但不包括企業版功能。

90 天的試用企業授權可讓您使用並評估所有企業版功能，不過軟體強制規定該授權只有 90 天的有效期。如需使用此授權的說明，請參閱「Message Queue 管理指南」中所述的啟動選項。

如需有關授權功能、重新發行權限，以及將平台版升級到企業版的更多資訊，請參閱「Message Queue Installation Guide」。

Message Queue 功能摘要

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

上一頁目錄索引下一頁
Sun Java System Message Queue 3 2005Q4 技術摘要