1.PTP模型
PTP(Point-to-Point)模型是基於隊列(Queue)的,對於PTP訊息模型而言,它的訊息目的是一個訊息佇列(Queue),訊息生產者每次發送訊息總是把訊息送入訊息佇列中,訊息消費者總是從訊息佇列中讀取訊息.先進隊列的訊息將先被訊息消費者讀取.
發送方發訊息到隊列,接收方從隊列接收訊息,隊列的存在使得訊息的非同步傳輸成為可能。和郵件系統中的郵箱一樣,隊列可以包含各種訊息,JMS Provider 提供工具管理隊列的建立、刪除。JMS PTP 模型定義了用戶端如何向隊列發送訊息,從隊列接收訊息,瀏覽隊列中的訊息.第一節中的代碼就是PTP模型的.
下面的表格中的就是PTP模型的對象的主要概念和方法:
| 名稱 |
描述 |
| Queue |
由JMS Provider 管理,隊列由隊列名識別,用戶端可以通過JNDI 介面用隊列名得到一個隊列對象. |
| TemporaryQueue |
由QueueConnection 建立,而且只能由建立它的QueueConnection 使用.暫存佇列. |
| QueueConnectionFactory |
用戶端用QueueConnectionFactory 建立QueueConnection 對象. |
| QueueConnection |
一個到JMS PTP provider 的串連,用戶端可以用QueueConnection 建立QueueSession 來發送和接收訊息. |
| QueueSession |
提供一些方法建立QueueReceiver,QueueSender,QueueBrowser 和TemporaryQueue.如果在QueueSession 關閉時,有一些訊息已經被收到,但還沒有被簽收(acknowledged),那麼,當接收者下次串連到相同的隊列時,這些訊息還會被再次接收. |
| QueueReceiver |
用戶端用QueueReceiver 接收隊列中的訊息,如果使用者在QueueReceiver中設定了訊息選擇條件,那麼不合格訊息會留在隊列中,不會被接收到. |
| QueueSender |
用戶端用QueueSender 發送訊息到隊列 |
| QueueBrowser |
用戶端可以QueueBrowser 瀏覽隊列中的訊息,但不會收走訊息. |
| QueueRequestor |
JMS 提供QueueRequestor 類簡化訊息的收發過程.QueueRequestor 的建構函式有兩個參數:QueueSession 和queue,QueueRequestor 通過建立一個暫存佇列來完成最終的收發訊息請求. |
| 可靠性(Reliability) |
隊列可以長久地儲存訊息直到接收者收到訊息.接收者不需要因為擔心訊息會丟失而時刻和隊列保持啟用的串連狀態,充分體現了非同步傳輸模式的優勢. |
2.PUB/SUB模型
JMS Pub/Sub 模型定義了如何向一個內容節點發布和訂閱訊息,這些節點被稱作主題(topic).
主題可以被認為是訊息的傳輸中介,發行者(publisher)發布訊息到主題,訂閱者(subscribe) 從主題訂閱訊息.主題使得訊息訂閱者和訊息發行者保持互相獨立,不需要接觸即可保證訊息的傳送.
下面描述JMS Pub/Sub 模型中的主要概念和對象:
| 訂閱(subscription) |
訊息訂閱分為非持久訂閱(non-durable subscription)和持久訂閱(durable subscrip-tion),非持久訂閱只有當用戶端處於啟用狀態,也就是和JMS Provider 保持串連狀態才能收到發送到某個主題的訊息,而當用戶端處於離線狀態,這個時間段發到主題的訊息將會丟失,永遠不會收到.持久訂閱時,用戶端向JMS 註冊一個識別自己身份的ID,當這個用戶端處於離線時,JMS Provider 會為這個ID 儲存所有發送到主題的訊息,當客戶再次串連到JMS Provider時,會根據自己的ID 得到所有當自己處於離線時發送到主題的訊息. |
| Topic |
主題由JMS Provider 管理,主題由主題名識別,用戶端可以通過JNDI 介面用主題名得到一個主題對象.JMS 沒有給出主題的組織和階層的定義,由JMS Provider 自己定義. |
| TemporaryTopic |
臨時主題由TopicConnection建立,而且只能由建立它的TopicConnection使用.臨時主題不能提供持久訂閱功能. |
| TopicConnectionFactory |
用戶端用TopicConnectionFactory建立TopicConnection對象. |
| TopicConnection |
TopicConnection是一個到JMS Pub/Sub provider的串連,用戶端可以用TopicConnection建立TopicSession 來發布和訂閱訊息. |
| TopicSession |
TopicSession 提供一些方法建立TopicPublisher,TopicSubscriber,TemporaryTopic.它還提供unsubscribe方法取消訊息的持久訂閱. |
| TopicPublisher |
用戶端用TopicPublisher 發布訊息到主題. |
| TopicSubscriber |
用戶端用TopicSubscriber 接收發布到主題上的訊息.可以在TopicSubscriber 中設定訊息過濾功能,這樣,不符合要求的訊息不會被接收. |
| Durable TopicSubscriber |
如果一個用戶端需要持久訂閱訊息,可以使用Durable TopicSubscriber,TopSession 提供一個方法createDurableSubscriber建立Durable TopicSubscriber 對象. |
| 恢複和重新派送(Recovery and Redelivery) |
非持久訂閱狀態下,不能恢複或重新派送一個未簽收的訊息.只有持久訂閱才能恢複或重新派送一個未簽收的訊息. |
| TopicRequestor |
JMS 提供TopicRequestor 類簡化訊息的收發過程.TopicRequestor 的建構函式有兩個參數:TopicSession 和topic.TopicRequestor 通過建立一個臨時主題來完成最終的發布和接收訊息請求. |
| 可靠性(Reliability) |
當所有的訊息必須被接收,則用持久訂閱模式.當丟失訊息能夠被容忍,則用非持久訂閱模式. |
| |
|
綜上所述,兩者的API介面已經詳細的寫了出來,作為一個Java合格的開發人員,即使不背會這些,也需要理解透徹記住.接著可以看看兩種方式的對比: 3.JMS規範裡的兩種message傳輸方式Topic和Queue,兩者的對比如下表:
| |
topic |
Queue |
| 概要 |
Pub-Sub(發布/訂閱) |
PTP(點對點) |
| 有無狀態 |
topic資料預設是無狀態的. |
Queue資料是要實際介質儲存的,如儲存到資料庫. |
| 完整性保障 |
並不保證publisher發布的每條資料,Subscriber都能接受到. |
Queue保證每條資料都能被receiver接收. |
| 訊息是否會丟失 |
一般來說publisher發布訊息到某一個topic時,只有正在監聽該topic地址的sub能夠接收到訊息;如果沒有sub在監聽,該topic就丟失了. |
Sender發送訊息到目標Queue,receiver可以非同步接收這個Queue上的訊息.Queue上的訊息如果暫時沒有receiver來取,也不會丟失. |
| 訊息發布接收策略 |
一對多的訊息發布接收策略,監聽同一個topic地址的多個sub都能收到publisher發送的訊息.Sub接收完通知伺服器. |
一對一的訊息發布接收策略,一個sender發送的訊息,只能有一個receiver接收.receiver接收完後,通知伺服器已接收,伺服器對queue裡的訊息採取刪除或其他動作.
|
文章轉至:http://www.cnblogs.com/chenying99/archive/2013/07/01/3164637.html