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里的消息采取刪除或其他操作. |
OK,here it is.Over.繼續第三章.