訊息傳送中介軟體可讓元件與應用程式藉由產生及使用訊息的方式進行通訊。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 篩選掉。
這個較複雜的圖片解釋了許多有關發佈/訂閱訊息傳送的其他資訊。
多個產生器可以發佈訊息到相同的主題上。產生器可選擇共用同一條連線或不同的連線,但都皆可存取相同的主題。
多名訂閱者可以使用相同主題所提供的訊息。除非訂閱者使用選擇器將某些訊息篩選在外,或訊息在被使用之前即已過期,否則訂閱者會擷取所有發佈到主題上的訊息。
訂閱者可選擇共用同一條連線或不同的連線,但皆可存取相同的主題。
執行階段可動態增加或刪除發佈者與訂閱者,以便於訊息傳送系統視需要進行擴大或縮小。
訊息會依照傳送的順序發佈到主題上,但其使用順序則視訊息過期日期、訊息優先權,以及使用訊息時,是否使用選擇器而定。
發佈者與訂閱者會受到時間的影響:主題訂閱者只可使用訂閱建立之後所發佈的訊息。
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。如需結合兩個網域的範例,請參閱請求回覆式樣。