jms p2p和PubSub模型總結

首先先總結下jms規範下定義的實現介面：

使用者用來建立到jms提供者的連線的被管物件。jms客戶通過可移植的介面訪問連線，這樣當下層的實現改變時，**不需要進行修改。管理員在jndi名字空間中配置連線工廠，這樣，jms客戶才能夠查詢到它們。根據訊息型別的不同，使用者將使用佇列連線工廠，或者主題連線工廠。

連線代表了應用程式和訊息伺服器之間的通訊鏈路。在獲得了連線工廠後，就可以建立乙個與jms提供者的連線。根據不同的連線型別，連線允許使用者建立會話，以傳送和接收佇列和主題到目標。

目標是乙個包裝了訊息目標識別符號的被管物件，訊息目標是指訊息發布和接收的地點，或者是佇列，或者是主題。jms管理員建立這些物件，然後使用者通過jndi發現它們。和連線工廠一樣，管理員可以建立兩種型別的目標，點對點模型的佇列，以及發布者/訂閱者模型的主題。

由會話建立的物件，用於接收傳送到目標的訊息。消費者可以同步地（阻塞模式），或非同步（非阻塞）接收佇列和主題型別的訊息。

由會話建立的物件，用於傳送訊息到目標。使用者可以建立某個目標的傳送者，也可以建立乙個通用的傳送者，在傳送訊息時指定目標。

是在消費者和生產者之間傳送的物件，也就是說從乙個應用程式傳送到另乙個應用程式。乙個訊息有三個主要部分：

訊息頭（必須）：包含用於識別和為訊息尋找路由的操作設定。

一組訊息屬性（可選）：包含額外的屬性，支援其他提供者和使用者的相容。可以建立定製的字段和過濾器（訊息選擇器）。

乙個訊息體（可選）：允許使用者建立五種型別的訊息（文字訊息，對映訊息，位元組訊息，流訊息和物件訊息）。

訊息介面非常靈活，並提供了許多方式來定製訊息的內容。

表示乙個單執行緒的上下文，用於傳送和接收訊息。由於會話是單執行緒的，所以訊息是連續的，就是說訊息是按照傳送的順序乙個乙個接收的。會話的好處是它支援事務。如果使用者選擇了事務支援，會話上下文將儲存一組訊息，直到事務被提交才傳送這些訊息。在提交事務之前，使用者可以使用回滾操作取消這些訊息。乙個會話允許使用者建立訊息生產者來傳送訊息，建立訊息消費者來接收訊息。

p2p(point-to-point)模型：

其中包含幾個比較重要的概念：訊息佇列（queue），傳送者（sender），接受者（receiver），每個訊息被傳送到規

定的訊息佇列中，並且該訊息會被持久化。每個訊息只能對應乙個消費者，即使傳送訊息時，消費者沒有在執行，仍然不影

響該訊息被傳送到訊息佇列，當消費者執行時，該訊息就會被消費者接受到。下面以乙個例項說明p2p模型的執行機制。

伺服器端**：

@messagedriven(
activationconfig=
)public class mdbbeantest01 implements messagelistener  catch (jm***ception e) 
}}

上面的「queue/leadfarqueue」佇列可以在jboss的配置檔案中進行配置，具體路徑如下：

jboss_home\server\default\deploy\messaging\destinations-service.xml

在此檔案中新增：

jboss.messaging:service=serverpeer
jboss.messaging:service=postoffice

這樣伺服器端的測試**就完成了。

客戶端**：

try  catch (namingexception e)  catch (jm***ception e)

這樣就可以進行測試，測試結果：

伺服器端除錯資訊：19:39:56,234 info [stdout] 伺服器接收到了資訊：mdbbean ，你好

驗證p2p模式下訊息的持久化的特性：

首先停止伺服器端ejb的執行，再次執行客戶端測試**。此時，該訊息仍然會傳送到指定的訊息佇列，這時再次啟動服務

器端的執行，訊息仍然會傳送到伺服器端。說明，佇列會將訊息持久化。

pubsub模型

其中包含的幾個概念：主題（topic），發布者（publisher），訂閱者（subscriber）。與p2p模型不同，p2p模型中消

息與接收者是一對一的關係，而在pubsub模型中，主題與訂閱者是一對多的關係，也就是乙個topic會傳送給多個訂閱者

，但是主題並不會被持久化，也就是說如果在topic傳送時，訂閱者程式沒有執行，那麼等到訂閱者下次再次執行時，該

topic也不會再傳送給該訂閱者，該topic對該訂閱者來說已經丟失。測試**如下：

@messagedriven(
activationconfig=
)public class topicmdbbeantest01 implements messagelistener  catch (jm***ception e) 
}}

「topic/leadfartopic」選項還是在上面的xml檔案中進行指定，這個例項中，在伺服器端定義了多個ejb，都是使用「

topic/leadfartopic」。

客戶端**：

try  catch (namingexception e)  catch (jm***ception e)

與上面的客戶端**類似，這個測試結果如下：

伺服器端除錯資訊：

20:24:57,281 info [stdout] 伺服器接收到了資訊：topicmdbbean ，你好

20:24:57,281 warn [interceptorsfactory] ejbthree-1246: do not use interceptorsfactory with a managedobjectadvisor, interceptorregistry should be used via the bean container

20:24:57,281 info [stdout] 伺服器接收到了資訊：topicmdbbean ，你好

可見，伺服器端的三個ejb都收到了該topic。

如果將伺服器端程式停止執行，再執行客戶端程式，再重新啟動伺服器端程式，也不會收到該topic，也就是說topic被丟

失了。也可以將topic持久化，方法如下：在@messagedriven的配置中增加幾個配置選項：

@messagedriven(
activationconfig=
)

經過這樣的配置後，該topic對於配置成這樣的ejb來說就進行了持久化，這樣，這個ejb在topic傳送後再執行也能接收到

。以上就是兩種模型各自的特點。

jms p2p和PubSub模型總結

JMS（三）PTP和Pub Sub模型

伺服器模型 C S模型和P2P模型

P2P網路模型

jms p2p和PubSub模型總結

JMS（三）PTP和Pub Sub模型

伺服器模型 C S模型和P2P模型

P2P網路模型

相關推薦