第 2 章 用戶端程式設計模型

本章說明 Message Queue 用戶端程式設計的基礎。涵蓋下列主題：

• 訊息傳送網域

• 程式設計物件

• 產生訊息

• 使用訊息

• 請求回覆式樣

• 可靠的訊息傳送

• 訊息在系統中的行程

• Java 用戶端與 C 用戶端

本章著重描述 Java 用戶端的設計及實作。整體而言，C 用戶端設計與 Java 用戶端設計非常類似。本章的最後一節將會摘要說明 Java 用戶端與 C 用戶端之間的不同。如需程式設計 Message Queue 用戶端的詳細討論，請參閱「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients」與「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients」。

第 3 章, Message Queue 服務將說明如何使用 Message Queue 服務來支援、管理及調校訊息傳送的效能。

設計與效能

Message Queue 應用程式的運作方式取決於許多因素：用戶端設計、連線配置、代理程式配置、代理程式調校與資源管理等。有部分因素屬於開發者的責任，其他因素則須由管理員考量。但實際上，開發者應瞭解 Message Queue 服務的支援方式，進而調整應用程式設計；而管理員也應利用調校應用程式的機會，瞭解設計的目標。訊息傳送運作方式不只可以經由重新設計而達到最佳化，同時也可透過謹慎的監視與調整達到此目的。因此，製作優良 Message Queue 應用程式的關鍵，在於開發者與管理員必須瞭解應用程式在生命週期各階段中所能夠執行的動作，並共享期望的運作方式與觀測到的運作方式之相關資訊。

訊息傳送網域

訊息傳送中介軟體可讓元件與應用程式藉由產生及使用訊息的方式進行通訊。JMS API 定義兩種式樣 (訊息傳送網域) 來管理這類通訊：點對點訊息傳送與發佈/訂閱訊息傳送。JMS API 的目的就是支援這些式樣。基本的 JMS 物件有：連線、階段作業、產生器、用戶、目標及訊息等，可用來指定這兩個網域中的訊息傳送運作方式。

點對點訊息傳送

在點對點網域中，訊息產生器稱為傳送者，而用戶稱為接收者。他們會藉由稱為佇列的目標來交換訊息：傳送者會產生訊息到佇列，而接收者則會使用佇列中的訊息。

圖 2–1 所示是點對點網域中最簡易的訊息傳送作業。MyQueueSender 傳送 Msg1 到佇列目標 MyQueue1。然後， MyQueueReceiver 取得 MyQueue1 上的訊息。

圖 2–1 簡易的點對點訊息傳送

圖 2–2 所示圖片，是較為複雜的點對點訊息傳送，說明此網域中可能發生的情況。MyQSender1 與 MyQSender2 兩位傳送者皆使用相同的連線將訊息傳送到 MyQueue1。 MyQSender3 則使用另一條連線將訊息傳送到 MyQueue1 。在接收端上，MyQReceiver1 會使用 MyQueue1 上的訊息，而 MyQReceiver2 與 MyQReceiver3 則會共用同一條連線，以使用 MyQueue1 上的訊息。

圖 2–2 複雜的點對點訊息傳送

這個較複雜的圖片解釋了許多有關點對點訊息傳送的其他資訊。

• 多個產生器可以傳送訊息到相同的佇列上。產生器可選擇共用同一條連線或不同的連線，但都皆可存取相同的佇列。

• 同一個佇列的訊息可以讓多名接收者使用，但一則訊息只可供一名接收者使用。因此，Msg1、Msg2 與 Msg3 會由不同的接收者所使用。(這屬於 Message Queue 的延伸。)

• 接收者可選擇共用同一條連線或不同的連線，但都皆可存取相同的佇列。(這屬於 Message Queue 的延伸。)

• 傳送者與接收者不會受到時間的影響：當用戶端將訊息傳出時，不論其是否正在執行中，接收者皆能擷取訊息。

• 執行階段可動態增加或刪除傳送者與接收者，以便於訊息傳送系統視需要進行擴大或縮小。

• 訊息會依照傳送的順序放置於佇列中，但其使用順序則視訊息過期日期、訊息優先權，以及使用訊息時，是否使用選擇器而定。

點對點模型具有許多優點：

• 由於同一個佇列上的訊息可供多名接收者使用，因此若接收訊息的順序不是很重要，可以針對訊息使用進行負載平衡。(這屬於 Message Queue 的延伸。)

• 以佇列為目標的訊息一律會予以保留，而不論其是否有接收者。

• Java 用戶端可使用佇列瀏覽器物件來檢視佇列的內容。其可根據這項檢視所取得的資訊來使用訊息。也就是說，雖然使用模型一般為 FIFO (先進先出)，但用戶若是知道自己所需的訊息，便可以透過訊息選擇器使用不在佇列最前面的訊息。管理用戶端也可以使用佇列瀏覽器來監視佇列內容。

發佈/訂閱訊息傳送

在發佈/訂閱網域中，訊息產生器稱為發佈者，而訊息用戶則稱為訂閱者。他們會藉由稱為主題的目標來交換訊息：發佈者會產生主題相關的訊息，而訂閱者則會訂閱主題，並使用主題所提供的訊息。

圖 2–3 所示是發佈/訂閱網域中的簡易訊息傳送作業。MyTopicPublisher 將 Msg1 發佈到目標 MyTopic 上。然後，MyTopicSubscriber1 與 MyTopicSubscriber2 各自從 MyTopic 接收一份 Msg1。

圖 2–3 簡易的發佈/訂閱訊息傳送

發佈/訂閱模型中不一定要有多位訂閱者；此圖中之所以顯示兩名訂閱者，是為了強調此網域可讓您廣播訊息。某項主題的所有訂閱者皆可收到任何發佈到該主題的訊息。

訂閱者可以是非長期或長期的訂閱者。代理程式會保留所有使用中訂閱者的訊息，但對於非使用中的訂閱者，便只會為長期訂閱者保留訊息。

圖 2–4 所示圖片，是較為複雜的發佈/訂閱訊息傳送，說明此式樣中可能發生的情況。數個產生器發佈訊息到 Topic1 目標。數名訂閱者使用 Topic1 目標上的訊息。除非訂閱者利用選擇器來篩選訊息，否則每位訂閱者都會取得所有發佈到所選主題的訊息。在圖 2–4 中，MyTSubscriber2 已將 Msg2 篩選掉。

圖 2–4 複雜的發佈/訂閱訊息傳送

這個較複雜的圖片解釋了許多有關發佈/訂閱訊息傳送的其他資訊。

• 多個產生器可以發佈訊息到相同的主題上。產生器可選擇共用同一條連線或不同的連線，但都皆可存取相同的主題。

• 多名訂閱者可以使用相同主題所提供的訊息。除非訂閱者使用選擇器將某些訊息篩選在外，或訊息在被使用之前即已過期，否則訂閱者會擷取所有發佈到主題上的訊息。

• 訂閱者可選擇共用同一條連線或不同的連線，但皆可存取相同的主題。

• 長期訂閱者可以是使用中或非使用中的訂閱者。代理程式會保留非使用中長期訂閱者的訊息。

• 執行階段可動態增加或刪除發佈者與訂閱者，以便於訊息傳送系統視需要進行擴大或縮小。

• 訊息會依照傳送的順序發佈到主題上，但其使用順序則視訊息過期日期、訊息優先權，以及使用訊息時，是否使用選擇器而定。

• 發佈者與訂閱者會受到時間的影響：主題訂閱者只可使用訂閱建立之後所發佈的訊息。

發佈/訂閱模型主要的優點在於可以將訊息廣播給多名訂閱者。

網域專用及統一的 API

JMS API 可定義讓您用來實作點對點或發佈/訂閱網域的介面與類別。這些就是表 2–1 第 2 欄與第 3 欄所顯示的網域專用 API。JMS API 另外可定義統一網域，讓您進行一般訊息傳送用戶端的程式設計。這類用戶端的運作方式，取決於它產生訊息與使用訊息的目標類型。若目標為佇列，則訊息傳送的運作方式會依據點對點式樣；若目標為主題，則訊息傳送的運作方式會依據發佈/訂閱式樣。

表 2–1 JMS 程式設計網域及物件

基本類型 (統一網域)	點對點網域	發佈/訂閱網域
Destination (佇列或主題)	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

JMS 從版本 1.1 開始引入統一網域。如果您需要符合較早的 JMS 1.02b 規格，可以使用網域專用的 API。使用網域專用的 API 也可提供清晰的程式設計介面，避免出現特定類型的程式設計錯誤：例如，為佇列目標建立長期訂閱。然而，網域專用 API 的缺點是，您不能在同一作業事件或同一階段作業中結合點對點和發佈/訂閱作業。如果您需要執行這些動作，應該選擇統一網域 API。如需結合兩個網域的範例，請參閱請求回覆式樣。

程式設計物件

以下用於實作 JMS 訊息傳送的物件，在各程式設計網域間基本上都能保持相同：連線工廠、連線、階段作業、產生器、用戶、訊息與目標。圖 2–5 是這些物件的示意圖。此圖將從連線工廠物件開始，完整說明物件導出的方式。

連線工廠物件與目標物件會顯示在物件存放區中。強調這些物件通常會被視為受管理物件而進行建立、配置及管理。假設本章中的連線工廠與目標皆是利用管理方式建立 (而不是利用程式設計所建立)。

圖 2–5 JMS 程式設計物件

表 2–2 總結了傳送與接收訊息時的必要步驟。請注意，傳送者與接收者的步驟 1 至步驟 6 皆相同。

表 2–2 產生與使用訊息

產生訊息	使用訊息
1. 管理員建立連線工廠受管理物件。
2. 管理員建立實體目標與參照此目標的受管理物件。
3. 用戶端透過 JNDI 查找而取得連線工廠物件。
4. 用戶端透過 JNDI 查找而取得目標物件。
5. 用戶端建立連線，並設定此連線專有的特性。
6. 用戶端建立階段作業，並設定負責控制訊息傳送可靠性的特性。
7. 用戶端建立訊息產生器。	用戶端建立訊息用戶。
8. 用戶端建立訊息。	用戶端啟動連線。
9. 用戶端傳送訊息。	用戶端接收訊息。

下列幾節將說明產生器與用戶所使用的物件：連線、階段作業、訊息與目標。我們將藉由描述訊息的產生與使用，來結束對 JMS 物件的討論。

連線工廠與連線

用戶端會使用連線工廠物件 (ConnectionFactory) 建立連線。連線物件 (Connection) 代表用戶端與代理程式之間使用中的連線。它會使用依預設啟動的基本連線服務，或使用管理員為該用戶端專門啟動的基本連線服務。

通訊資源的分配以及用戶端的認證均在建立連接時進行。相對而言，這是一個十分重要的物件，大多數用戶端均使用單一連線來進行所有的訊息傳送。連線可支援同時使用：多個產生器與用戶共用相同的連線，而無數量上的限制。

建立連線工廠時，藉由設定其特性，可以對所有源自此連線工廠的連線配置其運作方式。對於 Message Queue，這些特性會指定下列資訊：

• 代理程式所在主機的名稱、所需的連線服務，以及用戶端存取該服務時使用的連接埠。

• 連線失敗時應以何種方式處理代理程式的自動重新連線。(這項功能會在連線中斷時，將用戶端重新連線到相同或不同的代理程式上。但不一定會進行資料容錯移轉：重新連線到不同的代理程式時，可能會遺失永久性訊息與其他狀態資訊。)

• 需要代理程式追蹤其長期訂閱之用戶端的 ID。

• 嘗試進行連線之用戶的預設名稱與密碼。連線時若未指定密碼，可以利用這項資訊認證用戶並進行作業授權。

• 對於不需考量可靠性的用戶端，是否需停用代理程式確認。

• 如何管理代理程式與用戶端執行階段之間的控制流程及有效負載訊息。

• 如何處理佇列瀏覽。(僅限 Java 用戶端。)

• 是否應置換特定的訊息標頭欄位。

您可以從指令行置換連線工廠特性，以啟動用戶端應用程式。您也可以透過設定連線特性，而置換任何指定連線的特性。

您可以使用連線物件來建立階段作業物件、設定異常偵聽程式，或取得 JMS 的版本與提供者資訊。

階段作業

若連線代表用戶端與代理程式之間的通訊通道，則階段作業便代表用戶端與代理程式之間的單次對話。階段作業物件主要用於建立訊息、訊息產生器與訊息用戶。建立階段作業時，必須透過多個確認選項或透過作業事件來配置可靠的傳送作業。如需更多資訊，請參閱可靠的訊息傳送。

根據 JMS 規格，階段作業是用來產生及使用訊息的單執行緒環境。您可以為單一階段作業建立多個訊息產生器與用戶；但若要連續加以使用，則會受到限制。Java 用戶端與 C 用戶端的執行緒在實作上略有不同。如需執行緒實作與限制的相關資訊，請參閱適當的開發者指南。

您也可以使用階段作業物件來執行下列作業：

• 為並未使用受管理物件來定義目標的用戶端建立及配置目標。

• 建立及配置暫時主題與佇列，這些將會作為請求回覆式樣的一部分。請參閱請求回覆式樣。

• 支援作業事件處理。

• 定義產生或使用訊息的順序。

• 為非同步用戶串列化訊息偵聽程式的執行工作。

• 建立佇列瀏覽器。(僅限 Java 用戶端。)

訊息

訊息由下列 3 個部分組成：標頭、特性和內文。您必須瞭解此結構，才能編寫正確的訊息，並且配置特定的訊息傳送運作方式。

訊息標頭

每個 JMS 訊息都需要標頭。標頭含有 10 個預先定義的欄位，列出在表 2–3 中加以說明。

表 2–3 JMS 定義的訊息標頭

標頭欄位	說明
JMSDestination	指定訊息傳送所至之目標物件的名稱。(由提供者設定。)
JMSDeliveryMode	指定訊息是否具有永久性。(預設是由提供者所設定，或由產生器或個別訊息的用戶端明確設定。)
JMSExpiration	指定訊息的過期時間。(預設是由提供者所設定，或由產生器或個別訊息的用戶端設定。)
JMSPriority	指定介於 0 (低) 至 9 (高) 之間的訊息優先權。(預設是由提供者所設定，或由產生器或個別訊息的用戶端明確設定。)
JMSMessageID	指定提供者安裝環境內之訊息的唯一 ID。(由提供者設定。)
JMSTimestamp	指定提供者接收訊息的時間。(由提供者設定。)
JMSCorrelationID	供用戶端定義兩訊息間一致性的值。(必要時由用戶端設定。)
JMSReplyTo	指定用戶傳送回覆所至的目標。(必要時由用戶端設定。)
JMSType	可由訊息選擇器評估的值。(必要時由用戶端設定。)
JMSRedelivered	指定訊息是否已傳送但尚未確認。(由提供者設定。)

如您在閱讀此表格時所見，訊息標頭欄位具有多種用途：識別訊息、配置訊息路由、提供訊息處理的相關資訊等。

JMSDeliveryMode 是最重要的欄位之一，可決定訊息傳送的可靠性。此欄位可指出訊息是否具有永久性。

• 永久性訊息保證能夠傳送出去，而且只能成功使用一次。永久性訊息不會因訊息服務失敗而遺失。

• 非永久性訊息最多只傳送一次。非永久性訊息則可能因訊息服務失敗而遺失。

某些訊息標頭欄位是由提供者 (代理程式或用戶端執行階段) 設定，某些則是由用戶端設定。訊息產生器必須配置標頭值，才能取得特定的訊息傳送運作方式；而訊息用戶則必須讀取欄位值，才能夠瞭解路由訊息的方式，以及訊息可能需要的進一步處理。

標頭欄位 (JMSDeliveryMode、 JMSExpiration 和 JMSPriority) 可設定為三種不同的層級：

• 適用於源自連線工廠之每個連線發出的訊息。

• 適用於產生的各項訊息。

• 適用於特定訊息產生器發出的各項訊息。

如果這些欄位不只設在一個層級上，則連線工廠的設定值便會置換個別訊息的設定值；特定訊息的設定值則會置換訊息產生器的設定值。

訊息標頭欄位的常數名稱則會隨所用語言而有所不同。如需更多資訊，請參閱「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients」或「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients」。

訊息特性

訊息中也可能含有可選的標頭欄位 (稱為特性)，會以特性名稱與特性值成對指定。「特性」可讓用戶端與提供者延伸訊息標頭，並可包含任何有助於用戶端或提供者識別及處理訊息的資訊。訊息特性可讓接收用戶端要求僅傳送符合指定準則的訊息。例如，使用用戶端可指定只需要紐澤西州之兼差員工的薪資訊息。提供者將不會傳送任何不符指定準則的訊息。

JMS 規格定義九種標準特性。這些特性部分是由用戶端設定，部分則是由提供者設定。其名稱會以保留字元「JMSX」為開頭。用戶端或提供者可使用這些特性來判斷訊息的傳送者、訊息狀態，以及傳送訊息的頻率與時間。這些特性對提供者在路由訊息及提供診斷資訊時非常有用。

Message Queue 也可定義訊息特性，以識別壓縮訊息及訊息無法傳送時的處理方式。如需更多資訊，請參閱「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients」中的「Managing Message Size」。

訊息內文

訊息內文中含有用戶端所要交換的資料。

JMS 訊息的類型決定內文所要包含的項目，以及用戶應以何種方式進行處理，如表 2–4 所指定。階段作業物件中包含各種訊息內文類型的建立方法。

表 2–4 訊息內文類型

類型	說明
StreamMessage	內文包含一連串 Java 原始值串流的訊息。它被依序寫入及讀取。
MapMessage	內文包含一組「名稱-值」對的訊息。項目的順序未加以定義。
TextMessage	內文包含 Java 字串的訊息，例如 XML 訊息。
ObjectMessage	內文包含串列化 Java 物件的訊息。
BytesMessage	內文包含未解譯位元組串流的訊息。
Message	包含標頭和特性，但沒有內文的訊息。

Java 用戶端可設定特性，讓用戶端執行階段壓縮所要傳送的訊息內文。位於用戶端上的 Message Queue 執行階段可在傳送前解壓縮訊息。

產生訊息

訊息產生器可在連線與階段作業的環境中傳送或發佈訊息。產生訊息的方式並不複雜：用戶端使用訊息產生器物件 (MessageProducer) 將訊息傳送至實體目標 (在 API 中即以目標物件表示)。

建立產生器時，可以指定所有產生器訊息的預設傳送目標。您也可以指定管理永久性、優先權與存在時間之訊息標頭欄位的預設值。除非在傳送時指定替代目標，或為指定訊息的標頭欄位設定替代值，從而置換預設值，否則這些預設值在指定後，即可供該產生器所發出的所有訊息使用。

訊息產生器也可以設定 JMSReplyTo 訊息標頭欄位來實作請求回覆式樣。如需更多資訊，請參閱請求回覆式樣。

使用訊息

訊息用戶可在連線與階段作業的環境中接收訊息。用戶端會使用訊息用戶物件 (MessageConsumer) 接收來自特定實體目標 (在 API 中即以目標物件表示) 的訊息。

下列 3 項因素會影響代理程式傳送訊息給用戶的方式：

• 使用屬於同步或非同步

• 是否使用選擇器篩選內送的訊息

• 若是從主題目標使用訊息，訂閱者是否為長期訂閱者

另一個會影響訊息傳送與用戶端設計的主要因素，是用戶所需的可靠性程度。請參閱可靠的訊息傳送。

同步與非同步用戶

訊息用戶可以支援同步或非同步的訊息使用。

• 同步使用表示用戶明確請求傳送訊息並隨後使用訊息。

  同步用戶可依據請求訊息的方式不同，選擇在訊息傳入前一直等待訊息 (無限期)、在指定的時間內等待訊息，或在沒有訊息可使用時立即傳回。(「已使用」表示物件可立即供用戶端使用。已順利傳送但代理程式尚未完成處理的訊息則無法立即使用。)

• 非同步使用表示訊息自動傳送到已為用戶註冊的訊息偵聽程式物件 (MessageListener)。當階段作業執行緒呼叫訊息偵聽程式物件的 onMessage() 方法時，用戶端即可使用該訊息。

使用選擇器篩選訊息

訊息用戶可以使用訊息選擇器，使訊息服務僅傳送符合特定選取準則的訊息。您可以在建立用戶時指定此準則。

選擇器會使用類似 SQL 的語法來比對訊息特性。例如：

color = ”red’
size > 10

Java 用戶端也可以在瀏覽佇列時指定選擇器，以讓您檢視可供使用的已選取訊息。

使用長期訂閱者

您可以使用階段作業物件建立對主題的長期訂閱者。即使訂閱者處於非使用中的狀態，代理程式仍會保留這類訂閱者的訊息。

由於代理程式必須維護訂閱者的狀態，並在訂閱者重新啟動時繼續執行訊息傳送，因此代理程式在指定的訂閱者傳入與傳出時，都必須能夠加以識別。訂閱者的身份是由建立訂閱者的連線 ClientID 特性，以及您在建立訂閱者時所指定的訂閱者名稱建構而成。

請求回覆式樣

您可以將產生器與用戶結合在同一條連線中 (使用統一 API 時，甚至可結合在同一個階段作業中)。此外，JMS API 可讓您使用暫時目標，對您的訊息傳送作業實作請求回覆式樣。

若要設定請求回覆式樣，必須執行下列動作：

1. 建立可供用戶傳送回覆的暫時目標。

2. 在要傳送的訊息中，將訊息標頭的 JMSReplyTo 欄位設為該暫時目標。

當訊息用戶處理訊息時，會檢查訊息的 JMSReplyTo 欄位，以決定是否需要回覆，並將回覆傳送到指定的目標。

請求回覆機制讓產生器不需要設置回覆目標的受管理物件，而且讓用戶容易回應請求。當產生器在處理之前必須確定請求是否已處理時，此式樣非常有用。

圖 2–6 說明請求回覆式樣將訊息傳送到主題，並從暫時佇列中接收回覆。

圖 2–6 請求/回覆式樣

如圖所示，MyTopicPublisher 會產生 Msg1，並傳送到目標 MyTopic 上。MyTopicSubsriber1 與 MyTopicSubscriber2 會在收到訊息後，傳送回覆到 MyTempQueue，而 MyTQReceiver 則會由此處擷取回覆。應用程式如須發佈報價資訊給大量用戶端，且將其 (回覆) 訂單排入佇列依序處理，則此式樣會非常有用。

暫時目標的存在情況取決於建立它們的連線。任何產生器都可以對暫時目標進行傳送，但只有透過建立目標之相同連線建立的用戶，才可以存取暫時目標。

由於請求回覆式樣取決於暫時目標的建立，因此不應在下列情況下使用此式樣：

• 若預期建立暫時目標的連線可能會在您傳送回覆之前終止。

• 若必須傳送永久性訊息到暫時目標。

可靠的訊息傳送

訊息傳送會在兩個躍點上執行：第一個躍點會將訊息從產生器傳送到代理程式上的實體目標；第二個躍點則會將訊息從該目標傳送給用戶。因此，訊息可能會在這三個階段之一中遺失：當訊息位於傳送至代理程式的躍點上時；當訊息位於代理程式記憶體中，而代理程式失敗時；當訊息位於代理程式傳送給用戶的躍點上時。可靠的傳送可確保傳送不會在上述任何一個階段中失敗。由於非永久性訊息一律會隨著代理程式失敗而遺失，因此可靠的傳送僅適用於永久性訊息。

有兩種機制可確保傳送的可靠性：

• 用戶端可使用確認或作業事件讓訊息的產生與使用程序都能順利。

• 代理程式可將訊息儲存在永久存放區中；如此一來，即使代理程式在訊息使用之前即失敗，仍可擷取已儲存的訊息副本，並重試該作業。

以下各節描述確保可靠性的兩個方面。

確認

確認是在用戶端與訊息服務之間傳送的訊息，可確保郵件傳送的可靠性。產生器與用戶的確認用法不盡相同。

以訊息產生來說，代理程式會確認它已收到訊息，並將其放置在它的目標上，以永久存放。產生器的 send() 方法會暫停運作，直到收到此確認為止。在傳送永久性訊息時，會對用戶端自動進行這些確認作業。

以訊息使用來說，必須在用戶端確認已收到目標傳送的訊息，並加以使用之後，代理程式才會刪除該目標上的該項訊息。JMS 指定不同的確認模式來代表不同程度的可靠性。

• 在 AUTO_ACKNOWLEDGE 模式中，階段作業會自動確認用戶端使用的每個訊息。階段作業執行緒會暫停運作，以等待代理程式確定已處理每個使用訊息用戶端的確認。

• 在 CLIENT_ACKNOWLEDGE 模式中，用戶端會在一或多個訊息已被使用之後，呼叫訊息物件的 acknowledge() 方法，以進行明確的確認。這會使階段作業確認自前次方法呼叫之後，由階段作業所使用的所有訊息。階段作業執行緒會暫停運作，以等待代理程式確定已處理用戶端的確認。

  Message Queue 提供一種方法，讓用戶端只針對某個訊息接收與否進行確認，以延伸此模式。

• 在 DUPS_OK_ACKNOWLEDGE 模式中，階段作業會在使用 10 個訊息後確認。此模式中因為不需要使用代理程式確認，因此階段作業執行緒不會暫停來等侍代理程式的確認。雖然此模式可確保不會遺失任何訊息，但無法確保不會收到重複的訊息，這是其名稱：DUPS_OK。

對於效能高於可靠性的用戶端而言，Message Queue 服務提供 NO_ACKNOWLEDGE 方法來延伸 JMS API。在此模式中，代理程式不會追蹤用戶端確認，因此無法確保使用用戶端能夠順利處理訊息。選擇此模式可讓您在將非永久性訊息傳送給非長期訂閱者時，都保有較佳的效能。

作業事件

作業事件是將一或多個訊息的產生和 (或) 使用動作，集合為不可分割單位的方法。先前所討論的用戶端與代理程式確認，亦屬於作業事件。在此情況下，用戶端執行階段與代理程式確認會隱含地在作業事件層級上執行。確定作業事件時，代理程式回應會被自動傳送。

階段作業可配置成作業事件，而 JMS API 則提供用於啟動、確認或回復作業事件的方法。

在作業事件中產生或使用訊息時，訊息服務會追蹤各種傳送和接收過程，而且只有在 JMS 用戶端發出確定作業事件的呼叫時，才完成這些作業。如果作業事件中特定的傳送或接收作業失敗，則會出現異常。用戶端程式碼可以透過忽略異常、重試作業或回復整個作業事件來處理異常。在作業事件確定後，將完成所有的作業。在作業事件回復後，將取消所有成功的作業。

作業事件的範圍一律為單一階段作業。亦即，可以將單一階段作業的環境中執行的一個或多個產生器或用戶作業歸類為一個作業事件。由於作業事件僅能是單一階段作業，因此不能有同時包含訊息生產和訊息使用的端對端作業事件。

JMS 規格也支援分散式作業事件。也就是說，訊息的產生和使用可成為較大分散式作業事件的一部分，其中包括涉及資料庫系統等其他資源管理程式的作業。這時必須有作業事件管理程式 (如 Java Systems Application Server 所提供)，才能支援分散式作業事件。

在分散式作業事件中，分散式作業事件管理程式使用 Java Transaction API (JTA)、XA 資源 API 規格中定義的兩階段確定協定，追蹤和管理多個資源管理程式 (如訊息服務和資料庫管理員) 執行的作業。在 Java 中，JTA 規格描述了資源管理程式和分散式作業事件管理程式之間的互動。

支援分散式作業事件表示，訊息傳送用戶端可以透過 JTA 定義的 XAResource 介面參與分散式作業事件。此介面定義了實施兩階段確定的許多方法。當用戶端進行 API 呼叫時，JMS 訊息服務僅與 Java Transaction Service (JTS) 提供的分散式作業事件管理程式協作，來追蹤分散式作業事件中的各種傳送和接收作業以及作業事件狀態，並完成訊息傳送作業。處理本機作業事件時，用戶端可以藉由忽略異常、重試作業或回復整個分散式作業事件來處理異常。

---

備註 –

Message Queue 只有在 Java Enterprise Edition 平台中被當成 JMS 提供者使用時，才支援分散式作業事件。如需有關如何使用分散式作業事件的其他資訊，請參閱應用程式伺服器提供者所提供的文件。

---

永久性存放區

可靠性的另一層意義，就是確保代理程式在將永久性訊息傳送至用戶之前，訊息不會遺失。這表示當訊息送達實體目標時，代理程式必須將其存放在永久性資料存放區。代理程式若因故中斷，可於稍後回復該訊息，並將其傳送給適當的用戶。

代理程式也必須永久儲存長期訂閱。否則代理程式若是失敗，便無法將訊息傳送給訊息抵達主題目標之後，成為使用中狀態的長期訂閱者。

需要保證訊息傳送的訊息應用程式必須將訊息指定為永久性訊息，並傳送至主題目標的長期訂閱或佇列目標。

第 3 章, Message Queue 服務說明由 Message Queue 服務提供的預設訊息存放區，以及管理員應如何設定及配置替代的存放區。

訊息在系統中的行程

本節將總結目前已介紹的內容，說明如何使用 Message Queue 服務，將訊息從產生器傳送給用戶。為提供完整的概念，必須再深入說明一點。系統在傳送程序中所處理的訊息分成兩類：

• 有效負載訊息：產生器傳送給用戶的訊息。

• 控制訊息：在代理程式與用戶端執行階段之間傳播的私有訊息，可確保有效負載訊息順利傳送，並可控制連線間的訊息流量。

圖 2–7 是訊息傳送的示意圖。

圖 2–7 訊息傳送步驟

安全傳送永久性訊息時的訊息傳送步驟如下所示：

訊息生產

1. 用戶端執行階段透過連線，將訊息從訊息產生器傳送至代理程式。

訊息處理和訊息路由

2. 代理程式從連線讀取訊息，並將其放入適當的目標中。

3. 代理程式將 (永久性) 訊息放入資料存放區中。

4. 代理程式向訊息產生器的用戶端執行階段確認收到訊息。

5. 代理程式判斷訊息的路由情況。

6. 代理程式將訊息從目標寫入適當的連線，並為用戶在上面標記唯一的識別碼。

訊息使用

7. 訊息用戶的用戶端執行階段從連線傳送訊息至訊息用戶。

8. 訊息用戶的用戶端執行階段向代理程式確認訊息的使用。

訊息結束

9. 代理程式處理用戶端確認，並在收到所有確認後刪除 (永久性) 訊息。

10. 代理程式向用戶的用戶端執行階段確認已處理用戶端確認。

若管理員從目標中刪除訊息，或管理員移除或重新定義長期訂閱，而導致主題目標中的訊息尚未傳送即被移除，則代理程式便可能會在使用該訊息之前，即將其捨棄。在其他情況下，您可以讓代理程式將訊息儲存在名為停用的訊息佇列的特殊目標中，而不要將訊息捨棄。當訊息因為過期、記憶體限制而被移除，或在傳送時因用戶端發生異常而失敗時，會置於停用的訊息佇列中。將訊息儲存在停用的訊息佇列中可讓您進行系統的疑難排解，並在特定情況下回復訊息。

使用 SOAP 訊息

SOAP (請參閱Java 用戶端的 SOAP 支援) 可讓您在分散式環境中的兩個點之間，交換結構化資料 (由 XML 機制所指定)。Sun 的 SOAP 實作目前不支援可靠的 SOAP 訊息傳送，亦不支援 SOAP 訊息的發佈。必要時，您可以使用 Message Queue 服務取得可靠的 SOAP 訊息傳送，以發佈 SOAP 訊息。Message Queue 服務無法直接傳送 SOAP 訊息，但可讓您將 SOAP 訊息納入 JMS 訊息中，像一般的 JMS 訊息一樣產生及使用這些訊息，並從 JMS 訊息中取出 SOAP 訊息。

Message Queue 透過下列兩種套裝模組提供 SOAP 支援：javax.xml.messaging 與 com.sun.messaging.xml。您可以使用在這些程式庫中所實作的類別來接收 SOAP 訊息，以便將 SOAP 訊息包裝到 JMS 訊息中，並擷取 JMS 訊息中的 SOAP 訊息。J2EE 平台上提供的 java.xml.soap 套裝模組，可讓您用來組合及分解 SOAP 訊息。

取得可靠 SOAP 訊息傳送

1. 使用 java.xml.soap 套裝模組中所定義的物件來建置 SOAP 訊息，或使用 javax.xml.messaging 套裝模組中所定義的 Servlet 來接收 SOAP 訊息，或使用 JAX-RPC 等 Web 服務來接收 SOAP 訊息。

2. 使用訊息轉換公用程式將 SOAP 訊息轉換為 JMS 訊息。

3. 將 JMS 訊息傳送到所需的目標。

4. 以非同步或同步的方式使用 JMS 訊息。

5. 使用 JMS 訊息後，利用 MessageTransformer 公用程式將其轉換為 SOAP 訊息。

6. 使用 SAAJ API (定義於 java.xml.soap 套裝模組) 分解 SOAP 訊息。

   如需有關 SOAP 訊息及其處理的詳細資訊，請參閱「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients」中的第 5 章「Working with SOAP Messages」。

Java 用戶端與 C 用戶端

Message Queue 為其訊息傳送服務提供 C API，可讓傳統 C 應用程式與 C++ 應用程式參與 JMS 型訊息傳送。

JMS 程式設計模型是 Message Queue C 用戶端設計的基礎。「Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients」說明 C 資料類型與函數實作此模型的方式。

C 介面與 Java 介面一樣，皆支援下列功能：

• 發佈/訂閱與點對點連線

• 同步與非同步接收

• CLIENT、AUTO 與 DUPS_OK 確認模式

• 本機作業事件

• 階段作業回復

• 暫時主題與佇列

• 訊息選擇器

但請務必瞭解，Java Message Service 規格僅為 Java 用戶端的標準；因此 C Message Queue API 僅適用於 Message Queue 提供者，而無法搭配其他 JMS 提供者使用。其他 JMS 提供者無法處理包含 C 用戶端的訊息傳送應用程式。

C 介面不支援下列功能：

• 使用受管理物件

• 對映、串流或物件訊息類型

• 用戶型流量控制

• 佇列瀏覽器

• JMS 應用程式伺服器設備 (連線用戶、分散式作業事件)

• 接收或傳送 SOAP 訊息

• 接收或傳送壓縮的 JMS 訊息

• 自動重新連線或容錯移轉 (這些功能可在連線失敗時，讓用戶端執行階段自動重新連線到代理程式)

• NO_ACKNOWLEDGE 模式