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

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

本章著重描述 Java 用戶端的設計及執行。總體而言，C 用戶端設計與 Java 用戶端設計基本相同。本章的最後一節將會摘要說明 Java 用戶端與 C 用戶端之間的不同。如需程式設計 Message Queue 用戶端的詳細討論，請參閱「Message Queue Developer's Guide for Java Clients」與「Message Queue Developer's Guide forC Clients 」。

設計與效能

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

訊息傳送網域

訊息傳送中介軟體可讓元件與應用程式藉由產生及使用訊息的方式進行通訊。JMS API 會定義兩種樣式或訊息傳送網域來管理這項通訊：點對點訊息傳送與出版/訂閱訊息傳送。JMS API 即在支援這些樣式。基本的 JMS 物件：連線、階段作業、產生者、用戶、目標及訊息等，皆可用來指定這兩個網域中的訊息傳送行為。

點對點訊息傳送

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

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

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

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

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

如有多位接收者，則可使用相同佇列中的訊息，但每一則訊息只可供一位接收者使用。因此，Msg1、Msg2 與 Msg3 會由不同的接收者所使用。(這屬於 Message Queue 的延伸。)

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

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

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

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

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

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

Java 用戶端可使用佇列瀏覽器物件來檢視佇列的內容。其可根據這項檢視所取得的資訊來使用訊息。亦即，使用模型雖然多是 FIFO (先進先出)，但用戶若是透過訊息選擇器而得知所需的訊息，便可以使用不在佇列開頭的訊息。管理用戶端也可以使用佇列瀏覽器來監視佇列內容。

出版/訂閱訊息傳送

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

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

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

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

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

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

多位產生者可以出版訊息到相同的主題上。產生者可選擇共用同一條連線或不同的連線，但都皆可存取相同的主題。

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

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

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

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

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

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

網域專用及統一的 API

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

表 2-1 JMS 程式設計網域及物件
基本類型 (統一網域)	點對點網域	出版/訂閱網域
Destination (Queue 或 Topic)1	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

1取決於程式設計的方法，您必須指定特定的目標類型。

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

程式設計物件

用於執行 JMS 訊息傳送的物件，在各程式設計網域間仍維持相同的本質：連線工廠、階段作業、產生者、用戶、訊息與目標等。這些物件會顯示在圖 2-5 中。此圖將從連線工廠物件開始，完整說明物件導出的方式。

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

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

表 2-2 產生與使用訊息
產生訊息	使用訊息
1. 管理員建立受連線工廠所管理的物件。




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

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

連線工廠與連線

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

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

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

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

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

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

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

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

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

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

是否應覆寫特定的訊息標頭欄位。

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

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

階段作業

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

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

訊息

訊息組成包括下列三個部份：標頭、特性和內文。您必須瞭解此結構，才能編寫正確的訊息，以及配置特定的訊息傳送行為。

訊息標頭

每個 JMS 訊息都需要標頭。標頭中含有十個預先定義的欄位，會列示在表 2-3 中，並加以說明。

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

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

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

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

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

這些欄位若不只設在一個層級上，則連線工廠的設定值便會覆寫個別訊息的設定值；特定訊息的設定值則會覆寫訊息產生者的設定值。

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

訊息特性

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

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

Message Queue 也可定義訊息特性，以識別壓縮訊息及訊息無法傳送時的處理方式。如需相關資訊，請參閱「Message Queue Developer's Guide for Java Clients」。

訊息內文

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

表 2-4 訊息內文類型
類型	說明
StreamMessage	訊息內文包含 Java 原始值的串流。它被依序寫入及讀取。
MapMessage	訊息內文包含名稱-值對的組合。項目的順序未加以定義。
TextMessage	訊息內文包含 Java 字串，如 XML 訊息。
ObjectMessage	訊息內文包含序列化的 Java 物件。
BytesMessage	訊息內文包含未解譯位元組的串流。

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

產生訊息

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

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

訊息產生者也可以設定 JMSReplyTo 訊息標頭欄位來執行請求-回覆樣式。如需相關資訊，請參閱請求回覆樣式。

使用訊息

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

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

同步與非同步用戶

使用選擇器篩選訊息

訊息用戶可以使用訊息選擇器，令訊息服務僅將符合選取條件的訊息傳送至訊息用戶。您可以在建立用戶時指定此條件。

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

使用長期訂閱者

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

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

請求回覆樣式

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

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

請求-回覆機制除了免去產生者設定回覆目標之管理物件的麻煩之外，還簡化了用戶回應請求的程序。當產生者在處理之前必須確定請求是否已處理時，此樣式非常有用。

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

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

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

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

可靠的訊息傳送

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

確認

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

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

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

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

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

對於效能高於可靠性的用戶端而言，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) 提供的分散式作業事件管理員協作，來追蹤分散式作業事件中的各種傳送和接收作業以及作業事件狀態，並完成訊息傳送作業。

處理本機作業事件時，用戶端可以藉由忽略異常、重試作業或回轉整個分散式作業事件來處理異常。

永久性儲存

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

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

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

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

訊息在系統中的行程

本節將藉由總結目前已介紹的內容，說明如何使用 Message Queue服務，將訊息從產生者傳送給用戶。為了讓您有完整的概念，我們將加入更多的詳細資訊：系統在傳遞程序中所處理的訊息分成兩類：

訊息生產

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

訊息處理和訊息發送

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

訊息使用

訊息結束

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 訊息。

使用 java.xml.soap 套裝軟體中所定義的物件來建置 SOAP 訊息，或使用 javax.xml.messaging 套裝軟體中所定義的 Servlet 來擷取 SOAP 訊息，或使用 JAX-RPC 等 Web 服務來擷取 SOAP 訊息。

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

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

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

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

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

如需 SOAP 訊息及其處理的詳細資訊，請參閱「Message Queue Developer's Guidefor Java Clients 」。

Java 用戶端與 C 用戶端

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

JMS 程式設計模型是 Message Queue C 用戶端設計的基礎。「Message Queue Developer's Guide for C Clients」說明了 C 資料類型與函數執行此模型的方式。

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

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