|
| |
| Sun Java System Message Queue 3.5 SP1 管理指南 | |
第 1 章
簡介本章提供 Sun Java™ System Message Queue 的簡介，適用於管理員和程式設計人員閱讀。
何謂 Sun Java System Message Queue？Message Queue 產品為分散式應用程式的可靠、非同步訊息傳送提供了基於標準的解決方案。Message Queue 是實施 Java™ Message Service (JMS) 開放式標準的企業訊息傳送系統：事實上即是作為 JMS 參考實施。然而，Message Queue 也是具備完整功能的 JMS 提供者，且擁有輔佐企業發展的功能。
JMS 規格描述了一組訊息傳送語義和行為、以及應用程式設計介面 (API)，它們為 Java 語言應用程式提供了在分散式環境中建立、傳送、接收和讀取訊息的常用方法 (請參閱「JMS 程式設計模型」)。除了支援 Java 訊息傳送應用程式，Message Queue 還提供 C 語言介面給Message Queue 服務 (Message Queue C-API)。
使用 Sun Java System Message Queue 軟體，在不同平台和作業系統上執行的程序可連接至一個共用 Message Queue 訊息服務 (請參閱「訊息服務架構」)，以傳送和接收資訊。應用程式開發人員便可以將精力集中在應用程式的業務邏輯上，而不是集中在應用程式應如何在網路中進行可靠通訊這樣的低層細節上。
Message Queue 的功能已超出 JMS 規格的最低要求。這些功能如下：
集中式管理。 提供指令行和 GUI 工具，它們可以管理 Message Queue 服務，且管理應用程式相依的項目，例如目標、異動、長期訂閱和安全性。Message Queue 也支援 Message Queue 服務的遠端監視。
可延伸式訊息服務。 可讓您在以串聯方式 (多重代理程式叢集) 工作的大量 Message Queue 訊息伺服器元件 (代理程式) 之間平衡負載，以服務於不斷增多的 Message Queue 用戶端 (元件或應用程式)。
用戶端連接防故障備用。 自動復原用戶端連接至 Message Queue 訊息伺服器失敗的連接。
可調整的效能。 在發送可靠性要求較低的情況下，則可讓您提高 Message Queue 服務的效能。
多重傳輸。 支援 Message Queue 用戶端使用多種不同的傳輸方式 (包括 TCP 和 HTTP 以及使用安全 (SSL) 連接)，與 Message Queue 訊息伺服器進行通訊的功能。
JNDI 支援。 支援將 Java Naming and Directory Interface (JNDI) 的基於檔案的實施和 LDAP 實施用作物件儲存區和使用者儲存庫。
SOAP 訊息傳送支援。 支援經由 JMS 訊息傳送來建立和發送 SOAP 訊息 (符合簡單物件存取協定 (SOAP) 規格的訊息)。SOAP 允許在分散式環境中的各點之間交換結構化 XML 資料。請參閱「Message Queue Java Client Developer's Guide」，以取得更多資訊。
請參閱附錄 G「選擇性 JMS 功能的 Message Queue 實施」，以取得 JMS 有關相容議題的說明文件。
產品版本Sun Java System Message Queue 有兩個可用版本：平台版與企業版 - 每個版本對應於不同的功能組與授權容量，如下所述。(將 Message Queue 從一個版本升級到另外一個版本的說明位於「Message Queue Installation Guide」)。
平台版
該版本可以從 Sun 網站免費下載，且隨附於 Sun Java System Application Server 平台。平台版未對 Message Queue 訊息伺服器所支援的用戶端連接做出數目限制。該版本附帶有兩種授權，如下所述：
- 基本授權。該授權提供基本的 JMS 支援 (它是一個完整的 JMS 供應程式)，但不包括下列企業功能，如：負載平衡 (多重代理程式訊息服務)、HTTP/HTTPS 連接、安全連接服務、可延伸式連接功能、用戶端連接防故障備用、至多個使用者的佇列發送、遠端且基於訊息的監視以及 C-API 支援。該授權的有效期沒有限定，因此可以用於無較高要求的生產環境。
- 具有 90 天試用期的企業授權。該授權包括基本授權中未提供的所有企業功能 (如支援多重代理程式訊息服務、HTTP/HTTPS 連接、安全連接服務、可延伸式連接功能、用戶端連接防故障備用、至多個使用者的佇列發送、遠端且基於訊息的監視以及 C-API 支援)。然而，軟體強制規定該授權只有 90 天的有效期，所以，它適合於評估企業版產品提供的企業功能 (請參閱「企業版」)。
備註
您可以啟動 Message Queue 訊息伺服器 - Message Queue 代理程式實例 - 來啟用 90 天試用授權，如「若要啟動使用試用企業版授權的代理程式實例」中所述。
企業版
該版本用於在生產環境中部署與執行訊息傳送應用程式。它支援多重代理程式訊息服務、HTTP/HTTPS 連接、安全連接服務、可延伸式連接功能、用戶端連接防故障備用、至多個使用者的佇列發送、遠端且基於訊息的監視以及 C-API 支援。您也可以使用企業版來進行開發、載入測試訊息傳送應用程式與組件並對其進行除錯。企業版具有無限制的授權有效期，並且該授權對多重代理程式訊息服務中的代理程式數目也沒有限制，但是必須基於使用的 CPU 數目而定。
企業訊息傳送系統企業訊息傳送系統可讓獨立的分散式應用程式或應用程式元件透過訊息互動。這些元件 (無論是在同一主機、同一網路上執行，還是透過網際網路鬆散地連接在一起) 均使用訊息傳送來傳輸資料以及協調各自的功能。
企業訊息傳送系統的要求
企業應用程式系統一般包含大量的分散式元件，這些元件在全天候的關鍵任務作業中交換數以萬計的訊息。若要支援此類系統，企業訊息傳送系統通常必須滿足以下要求：
可靠的發送。 從一個元件傳送至另一個元件的訊息不能由於網路或系統故障而遺失。這意味著系統必須能夠保證成功地發送訊息。
非同步發送。 為使大量元件能夠同時交換訊息，並支援高密度流量，訊息傳送不能取決於使用者是否可以立即接收訊息。如果使用者忙碌或離線，系統必須允許先將訊息傳送出去，然後在使用者準備就緒時接收訊息。這就是所謂的非同步訊息發送，通常稱為儲存與轉寄訊息傳送。
安全性。 訊息傳送系統必須支援基本的安全性功能：使用者認證、訊息和資源的授權存取以及線上加密。
延伸性。 訊息傳送系統必須能夠在不降低效能或訊息流量的情況下，適應不斷增加的負載，即不斷增多的使用者和訊息數目。隨著商業和應用程式的延伸，這將成為一項很重要的要求。
可管理性。 訊息傳送系統必須提供監視和管理訊息發送以及最佳化系統資源的工具。這些工具有助於衡量和維護系統的可靠性、安全性和效能。
集中式訊息傳送和點對點訊息傳送
傳統的點對點訊息傳送系統很難滿足企業訊息傳送系統的要求，如圖 1-1 中所示。
圖 1-1 集中式訊息傳送和點對點訊息傳送
在此系統中，每個訊息傳送元件與其他所有元件均保持連接。這些連接可以實現快速、安全且可靠的發送，但是支援可靠性和安全性的程式碼必須駐留在每個元件中。隨著將元件不斷地加入系統，連接數目將成指數級增加。這使得非同步訊息發送和可延伸性很難實現。集中式管理也會出現問題。
企業訊息傳送的首選方法是集中式訊息傳送系統，在圖 1-1 中也有說明。在此方法中，每個訊息傳送元件只需與一個中央訊息服務保持連接。訊息服務提供元件之間的訊息發送和路由，並負責可靠發送及安全性。元件透過定義完善的程式設計介面與訊息服務進行互動。隨著將元件不斷地加入系統，連接的數目只會線性增長，這樣就可以透過調整訊息服務來輕鬆地調整系統。此外，中央訊息服務還為系統提供集中式管理。
訊息傳送系統概念
以下幾個基本概念構成企業訊息傳送系統的基礎，這些部分包括：訊息、訊息服務架構和訊息發送模型。
訊息
訊息包含某種格式的資料 (訊息內文) 以及描述訊息特徵或特性的元資料 (訊息標頭)，如目標、有效期或由訊息傳送系統決定的其他特徵。
訊息服務架構
訊息傳送系統的基本架構如圖 1-2 所示。它包含訊息產生者和訊息使用者，二者透過共用訊息服務來交換訊息。任何數目的訊息產生者和使用者均可駐留在同一個訊息傳送元件 (或應用程式) 中。訊息產生者將訊息傳送至訊息服務。然後，訊息服務使用訊息路由與發送元件，將訊息發送至一個或多個已註冊接收此訊息的訊息使用者。訊息路由與發送元件負責保證將該訊息發送至所有相應的使用者。
圖 1-2 訊息服務架構
訊息發送模型
產生者與使用者之間存在多種關係：一對一、一對多和多對多。例如，您發送訊息的方式可能是：
這些關係通常被簡化為兩個訊息發送模型：點對點與出版/訂閱訊息傳送。點對點發送模型主要處理由特定產生者創建並由特定使用者接收的訊息。出版/訂閱發送模型主要處理由任意數目的產生者創建並由任意數目的使用者接收的訊息。這兩個訊息發送模型可以同時使用。
過去訊息傳送系統支援這兩個訊息發送模型的各種組合。Java Message Service (JMS) 規格使用 Java 程式設計的 API，建立了標準的訊息傳送語義。它同時支援點對點訊息發送模型和出版/訂閱訊息發送模型 (請參閱「程式設計網域」)。
JMS 規格JMS 規格規定了一組管理訊息傳送的規則和語義，包括程式設計模型、訊息架構和 API。因為 Message Queue 提供了 JMS 的實施方法，所以 JMS 概念對於理解 Message Queue 訊息傳送系統的工作原理很重要。本簡介說明了理解本書其餘各章所需的概念和術語。
JMS 訊息結構
JMS 訊息由三個部分組成：標頭、特性和內文。
標頭 標頭指定訊息的 JMS 特徵：目標、永久與否、存在時間以及優先順序。這些特徵控制訊息傳送系統發送訊息的方式。
特性 特性 (可稱為標頭的延伸) 是選擇性的 - 應用程式可以使用特性提供的值，根據各種選取條件來過濾訊息。特性為選擇性的。
訊息內文 訊息內文包含要交換的實際資料。JMS 支援六種內文類型。
JMS 程式設計模型
在 JMS 程式設計模型中，JMS 用戶端 (元件或應用程式) 透過 JMS 訊息服務交換訊息。訊息產生者將訊息傳送至訊息服務，訊息接收者則從訊息服務接收這些訊息。這些訊息傳送作業是使用一組實施 JMS 應用程式設計介面 (API) 的物件 (由 JMS 提供者提供) 來執行的。
本節介紹實施 JMS API 的物件，以及用於為訊息發送配置 JMS 用戶端的物件 (如需更多資訊，請參閱「Message Queue Java Client Developer's Guide」)。圖 1-3 顯示用於設計訊息發送程式的 JMS 物件。
圖 1-3 JMS 程式設計物件
在 JMS 程式設計模型中，JMS 用戶端使用 ConnectionFactory 物件建立一個連接，將訊息傳送至訊息服務以及從訊息服務接收訊息均透過此連接進行。Connection 是用戶端與訊息服務的作用中連接。通訊資源的分配以及用戶端的認證均在建立連接時進行。相對而言，這是一個十分重要的物件，大多數用戶端均使用單一連接來進行所有的訊息傳送。
連接用於建立階段作業。Session 是用於生產和使用訊息的單執行緒環境。它用於建立傳送和接收訊息的訊息產生者和使用者，並為所發送的訊息定義發送順序。階段作業透過大量的確認選項或異動，支援可靠的發送。
用戶端使用 MessageProducer 將訊息傳送至指定實體目標 (在 API 中表示為目標識別物件)。訊息產生者可以指定預設發送模式 (永久性與非永久性訊息)、優先順序和存在時間值，以控制由產生者傳送至實體目標的所有訊息。
同樣，用戶端使用 MessageConsumer 從指定實體目標 (在 API 中表示為目標物件) 接收訊息。訊息使用者可以使用訊息選擇器，該選擇器可讓訊息服務僅將符合選取條件的訊息發送至訊息使用者。
訊息使用者可以支援同步或非同步的訊息使用。透過向使用者註冊 MessageListener 可實現非同步使用。當階段作業執行緒呼叫 MessageListener 物件的 onMessage() 方法時，用戶端即可使用訊息。
JMS 受管理物件
JMS 規格藉由指定受管理物件 (可封裝提供者特定的配置資訊) 促成提供者相依的用戶端。
「JMS 程式設計模型」中描述的兩個物件取決於 JMS 提供者實施 JMS 訊息服務的方法。連線工廠物件取決於提供者用於發送訊息的基本協定和機制，目標物件取決於提供者使用的特定命名慣例和實體目標功能。
通常，這些提供者特定的特徵使得 JMS 用戶端程式碼取決於特定的 JMS 實施。然而，JMS 規格要求在連線工廠和目標物件中封裝提供者特定的實施和配置資訊，接著，即可使用標準的非提供者特定的方式來進行存取。
受管理物件由管理員建立和配置，並存儲在名稱服務中，由用戶端透過標準 Java Naming and Directory Service (JNDI) 查找代碼來存取。以這種方式使用受管理物件可使用戶端程式碼獨立於提供者。
受管理物件的兩種類型，即連線工廠和目標，會封裝提供者特定的資訊，但它們在用戶端中的用途有很大的差異。連線工廠用於建立至訊息伺服器的連接，而目標物件用於識別實體目標。
JMS/J2EE 程式設計：訊息驅動 Bean除「JMS 程式設計模型」中介紹的一般 JMS 用戶端程式設計模型之外，還有專用於 Java 2 平台企業版 (J2EE 平台) 應用程式環境的 JMS。此專用的 JMS 用戶端稱為訊息驅動 Bean，是 EJB 2.0 規格 (http://java.sun.com/products/ejb/docs.html) 中指定的企業 JavaBeans (EJB) 元件系列之一。
因為其他 EJB 元件 (階段作業 Bean 和實體 Bean) 僅可被同步呼叫，所以就產生了對訊息驅動 Bean 的需求。這些 EJB 元件只能透過標準 EJB 介面來存取，因此它們沒有非同步接收訊息的機制。
但是，非同步訊息傳送是許多企業應用程式中必不可少的要求。這些應用程式大都需要伺服器端元件在不佔用伺服器資源的情況下，能夠互相通訊和確認。因此就出現了對 EJB 元件的需求，該元件不需要緊密耦合到訊息產生者即可接收和使用訊息。對於伺服器端元件必須確認應用程式事件的任何應用程式，均必須具備此功能。在企業應用程式中，此功能還必須能夠依據不斷增加的負載來進行延伸。
訊息驅動 Bean
訊息驅動 Bean (MDB) 是由專用 EJB 容器 (為所支援的元件提供分散式服務的軟體環境) 支援的專用 EJB 元件。
訊息驅動 Bean MDB 是實施 JMS MessageListener 介面的 JMS 訊息使用者。在 MDB 容器接收訊息時，會呼叫 onMessage 方法 (由 MDB 開發人員編寫)。onMessage() 方法使用該訊息的方式與標準 MessageListener 物件的 onMessage() 方法使用訊息的方式一樣。您不能以呼叫其他 EJB 元件的方法來遠端呼叫 MDB，因此不存在與之關聯的主介面或遠端介面。MDB 可以使用來自單一目標的訊息。獨立式 JMS 應用程式、JMS 元件、EJB 元件或 Web 元件均可以生產訊息，如圖 1-4 中所示。
圖 1-4 與 MDB 進行訊息傳送
MDB 容器 MDB 由專用 EJB 容器支援，負責建立和配置 MDB 實例，以用於非同步訊息使用。這包括配置與訊息服務 (包括認證) 的連接，建立與給定目標關聯的階段作業儲存區，以及管理在階段作業儲存區和關聯的 MDB 實例之間分配收到的訊息。由於容器控制 MDB 實例的生命週期，因此它透過管理 MDB 實例儲存區來容納進來的訊息負載。
與 MDB 關聯的是一個部署描述元，此描述元為配置訊息使用時所用的受管理物件指定了 JNDI 查找名稱：連線工廠和目標。部署描述元可能還包括部署工具用於配置容器的其他資訊。每個容器僅支援單一 MDB 的實例。
J2EE 應用程式伺服器支援
在 J2EE 架構中 (請參閱 http://java.sun.com/j2ee/download.html#platformspec 上的 J2EE 平台規格)，EJB 容器由 J2EE 應用程式伺服器託管。應用程式伺服器提供各種容器所需的資源：異動管理程式、永久性管理程式、名稱服務以及 JMS 提供者 (用於訊息傳送和 MDB)。
在 Sun Java System Application Server 中，JMS 訊息傳送資源由 Sun Java System Message Queue 提供：
- 對 Sun Java System Application Server 7.0 而言，Message Queue 訊息傳送系統已與應用程式伺服器整合，作為其原生 JMS 提供者。
- 對 Sun J2EE 1.4 Application Server 而言，Message Queue 外掛到應用程式伺服器，作為內嵌的 JMS 資源介面 (請參閱附錄 F「Message Queue 資源介面」)。
- 如需新版的 Application Server，Message Queue 會使用標準的資源介面部署和配置方法，外掛到應用程式伺服器。
JMS 訊息傳送問題本節描述許多影響 Message Queue 訊息服務管理的 JMS 程式設計問題。主要討論 Message Queue 管理員需要的概念和術語。
JMS 提供者獨立性
JMS 指定受管理物件的用法 (請參閱「JMS 受管理物件」)，以支援可以移植到其他 JMS 提供者的用戶端應用程式的開發。受管理物件可讓 JMS 用戶端使用邏輯名稱查找和參考提供者特定的物件。這樣，用戶端程式碼無需瞭解提供者使用的特定命名語法、尋址語法或配置特性，從而使程式碼獨立於提供者。
受管理物件為 Message Queue 管理員建立和配置的 Message Queue 系統物件。這些物件放在 JNDI 目錄服務中，JMS 用戶端可以使用 JNDI 查找存取它們。
Message Queue 受管理物件也可以由用戶端創設，而不是在 JNDI 目錄服務中查找。這樣做的缺點是，要求應用程式開發人員使用提供者特定的 API，並降低了 Message Queue 管理員成功控制和管理 Message Queue 訊息伺服器的能力。
如需有關受管理物件的更多資訊，請參閱「Message Queue 受管理物件」。
程式設計網域
JMS 支援兩種完全不同的訊息發送模型：點對點與出版/訂閱。
點對點 (佇列目標) 將訊息從產生者發送至一個使用者。在此發送模型中，目標為佇列。首先將訊息發送至佇列目標，然後根據佇列的發送策略 (請參閱「佇列目標」) 將訊息從該佇列發送至已向佇列註冊的一個使用者，每次發送一封訊息。可以向佇列目標傳送訊息的產生者沒有限制，但每封訊息只能發送至一個使用者，並由一個使用者成功接收。如果沒有向佇列目標註冊的使用者，佇列將保留其接收到的訊息，並在使用者向該佇列註冊時將訊息發送給他們。
出版/訂閱 (主題目標) 將訊息從產生者發送至任意數目的使用者。在此發送模型中，目標為主題。訊息被首先發送至主題目標，然後發送至已訂閱該主題的所有作用中使用者。可以向主題目標傳送訊息的產生者沒有限制，並且每封訊息可以被發送至任意數目的訂閱使用者。主題目標還支援長期訂閱。長期訂閱表示使用者已向主題目標進行註冊，但在發送訊息時此使用者可以處於非作用狀態。然後，當使用者再處於作用中時，將接收此訊息。如果沒有使用者向主題目標進行註冊，則主題將不保留其收到的訊息，除非有非作用中使用者使用長期訂閱。
這兩種訊息發送模型使用表示不同程式設計網域的不同 API 物件 (語義稍有差異) 進行處理，如表 1-1 中所示。
表 1-1 JMS 程式設計物件
基本類型
(統一網域)點對點網域
出版/訂閱網域
Destination (Queue 或 Topic)1
佇列
主題
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
1取決於程式設計的方法，您可以指定特定的目標類型。
您可以使用表 1-1 第一欄中所示的統一網域物件設計點對點和出版/訂閱訊息傳送的程式。這是通常採用的方法。但是，為了符合早期的 JMS 1.02b 規格，可以使用點對點網域物件設計點對點訊息傳送的程式，使用出版/訂閱網域物件設計出版/訂閱訊息傳送的程式。
用戶端識別碼
JMS 提供者必須支援用戶端識別碼概念，用戶端識別碼將 JMS 用戶端至訊息服務的連接與代表用戶端的訊息服務所維護的狀態資訊相關聯。根據定義，用戶端識別碼是唯一的，並且每次僅套用至一個使用者。用戶端識別碼與長期訂閱名稱 (請參閱「出版/訂閱 (主題目標)」) 結合使用，可以確保每個長期訂閱僅對應一個使用者。
JMS 規格允許用戶端透過 API 方法呼叫來配置用戶端識別碼，但是建議您使用連線工廠受管理物件 (請參閱「JMS 受管理物件」) 從管理級別來配置它。但是如果硬連接至連線工廠，則每個使用者均需要個別的連線工廠以擁有唯一身份。
使用可在 ConnectionFactory 物件中配置的特殊變數替換語法，Message Queue 提供了一種方法，可讓用戶端識別碼同時特定於 ConnectionFactory 和使用者。使用此方法時，單一 ConnectionFactory 物件可由建立長期訂閱的多個使用者使用，而不必擔心命名衝突或缺乏安全性。這樣就保護了使用者的長期訂閱，不會因為其他使用者配置了錯誤的用戶端識別碼而導致意外刪除或不可用。
如需有關如何使用此 Message Queue 功能的詳細資訊，請參閱「Message Queue Java Client Developer's Guide」中有關連線工廠屬性的說明。
無論如何，若要建立長期訂閱，用戶端識別碼必須由用戶端使用 JMS API 透過程式配置，或在用戶端使用的 ConnectionFactory 物件中進行管理級別的配置。
可靠的訊息傳送
JMS 定義了兩種發送模式：
永久性訊息 保證這些訊息僅被發送一次並成功使用一次。對於這些訊息，可靠性是首要因素。
非永久性訊息 保證這些訊息最多被發送一次。對於這些訊息，可靠性並非主要因素。
對於永久性訊息，確保可靠性有兩個方面。一個是要確保至訊息服務和來自訊息服務的訊息發送成功。另一個是要確保訊息服務在將永久性訊息發送至使用者之前不會遺失訊息。
確認/異動
可靠的訊息傳送取決於確保至目標和來自目標的永久性訊息的成功發送。可使用 Message Queue 階段作業支援的兩個一般機制中的任何一個來實現此目的，這兩個機制是：確認或異動。異動 (可以是本地異動或分散式異動) 由分散式異動管理程式控制。
確認
可以將階段作業配置為使用確認來保證可靠發送。
對於產生者，這意味著在產生者的 send() 方法返回之前，訊息服務將向其目標確認永久性訊息的發送。對於使用者，這意味著在訊息服務從該目標刪除永久性訊息之前，用戶端將確認來自該目標的永久性訊息的發送與使用。
本地異動
也可以將階段作業配置為異動的，這樣就可以將一個或多個訊息的生產和/或使用群組為原子單元，即異動。JMS API 提供了啟動、確定或回轉異動的方法。
在異動中生產或使用訊息時，代理程式會追蹤各種傳送和接收過程，並在用戶端發出確定異動的呼叫時完成這些作業。如果異動中特定的傳送或接收作業失敗，則會出現異常。用戶端程式碼可以透過忽略異常、重試作業或回轉整個異動來處理異常。在異動確定後，將完成所有成功的作業。在異動回轉後，將取消所有成功的作業。
本地異動的範圍始終是單一階段作業。即，可以將單一階段作業的環境中執行的一個或多個產生者或使用者作業群組為一個本地異動。
由於異動僅能是單一階段作業，因此不能有同時包含訊息生產和訊息使用的端對端異動。(換言之，至目標的訊息發送和後續的至用戶端的發送不能放在同一個異動中。)
分散式異動
Message Queue 還支援分散式異動。即，訊息的生產和使用可作為較大的分散式異動的一部分，其中包括涉及其他資源管理程式 (如資料庫系統) 的作業。在分散式異動中，分散式異動管理程式使用 Java Transaction API (JTA)、XA 資源 API 規格中定義的兩階段確定協定，追蹤和管理多個資源管理程式 (如訊息服務和資料庫管理程式) 執行的作業。在 Java 中，JTA 規格描述了資源管理程式和分散式異動管理程式之間的互動。
支援分散式異動表示，訊息傳送用戶端可以透過 JTA 定義的 XA 資源介面參與分散式異動。此介面定義了實施兩階段確定的許多方法。當用戶端進行 API 呼叫時，Message Queue 代理程式僅與分散式異動管理程式 (由 Java Transaction Service (JTS) 提供) 協作，來追蹤分散式異動中的各種傳送和接收作業以及異動狀態，並完成訊息傳送作業。
處理本地異動時，用戶端可以透過忽略異常、重試作業或回轉整個分散式異動來處理異常。
Message Queue 透過 XA 連線工廠實施對分散式異動的支援，這可讓您建立 XA 連接，而 XA 連接又可讓您建立 XA 階段作業 (請參閱「JMS 程式設計模型」)。此外，對分散式異動的支援還要求協力廠商 JTS 或與 J2EE 相容的 Application Server (提供 JTS)。
永久性儲存
可靠性的另一個重要方面是，確保將永久性訊息發送至其目標後，訊息服務在將其發送至使用者之前不會遺失這些訊息。這意味著將永久性訊息發送至其目標時，訊息服務必須將其放在永久性資料存儲區中 (請參閱「持續性管理程式」)。如果訊息服務由於某種原因失敗，它可以回復該訊息並將其發送至相應的使用者。雖然這增加了訊息發送的耗用時間，但卻提昇了可靠性。
訊息服務還必須儲存長期訂閱。這是因為要確保主題目標下的發送，因此僅回復永久性訊息是不夠的。訊息服務還必須回復有關主題長期訂閱的資訊，否則它將無法將訊息發送至在訊息到達時處於非作用中狀態、隨後又處於作用中狀態的用戶。
需要可靠訊息發送的訊息傳送應用程式必須將訊息指定為永久性訊息，並使用佇列目標或主題目標的長期訂閱。
效能平衡
訊息發送的可靠性越高，需要的耗用時間和頻寬就越多。可靠性與效能之間的平衡是設計時要考慮的重點。您可以透過選擇生產和使用非永久性訊息來最大化效能。另一方面，您也可以透過生產和使用永久性訊息並使用異動階段作業來最大化可靠性。在這兩種極端之間有許多選擇，這取決於應用程式的需要，包括使用 Message Queue 特定的連接和確認特性 (請參閱「Message Queue Java Client Developer's Guide」)。這些平衡在「影響效能的應用程式設計因素」中有更完整說明。
訊息選取
JMS 提供了一種機制，透過它，訊息服務可以根據訊息選擇器中的條件執行訊息過濾和路由。生產型用戶端可在訊息中放入應用程式特定的特性，使用型用戶端可以使用基於這些特性的選取條件來表明它對訊息的興趣。這樣簡化了用戶端的工作並排除了給不需要訊息的用戶端額外傳送。但是，它也使得處理選取條件的訊息服務增加了一些額外耗用時間。JMS 規格中對訊息選擇器的語法和語義進行了概述。
訊息順序和優先順序
通常，可以確保將單一階段作業向目標傳送的所有訊息按其傳送順序發送至使用者。但是，如果為它們分配不同的優先順序，訊息傳送系統將嘗試先發送優先級較高的訊息。
此外，用戶端應用程式使用訊息的順序與訊息的生產順序僅具有一個粗略的關係。這是因為向目標發送訊息以及從這些目標發送訊息，可以取決於多個影響時間的問題，如訊息的傳送順序、傳送訊息的階段作業 (連接)、是否為永久性訊息、訊息的存在時間、訊息的優先順序、佇列目標的訊息發送策略 (請參閱「佇列目標」) 以及訊息服務的可用性。
對於使用多個互連代理程式 (請參閱「多重代理程式叢集 (企業版)」) 的 Message Queue 訊息伺服器，用戶端使用訊息的排序更為複雜，因為從不同代理程式的目標發送訊息的順序是不確定的。因此，由一個代理程式發送的訊息可能會在另一個代理程式所發送的訊息之前，即使後者可能會先收到訊息。
無論如何，對於給定使用者，具有較高優先順序的訊息總是在具有較低優先順序的訊息之前。
