為JMS客戶端指定消息持久性

Question

我正在閱讀Java EE教程的這一部分。 http://download.oracle.com/javaee/6/tutorial/doc/bncfu.html#bncfy

並且有一個問題：如果我有一個生成消息的JMS客戶端（而不是服務器）並將它們發送到服務器上的目標隊列，那么這個producer.setDeliveryMode（DeliveryMode.PERSISTENT）; 仍然適用？

我的意思是JMS客戶端是否支持任何持久化消息的機制，或者只提供提供者/服務器軟件？

謝謝

Answer 1

由於JMS只是一個規范，因此沒有什么能阻止實現在客戶端提供某種級別的消息持久性。 但是，在實踐中，所有實現（無論如何我都知道）將其委托給代理。

請記住，消息傳遞最初設計為在每個節點上都有一個代理，就像每個節點也有一個TCP / IP，LU6.2或其他傳輸堆棧一樣。 從這個意義上講，消息傳遞嚴格地說是一種傳輸，而不是像數據庫這樣的中央服務。 其目的是提供一種本地服務，使應用程序與網絡不可用以及可用的無數同步傳輸協議隔離開來。 在此模型中，代理始終是本地的，唯一的網絡通信是在兩個代理之間。

多年來，消息傳遞增加了客戶端功能，但這更多地是關於許可成本而不是架構。 消息傳遞客戶端連接重新引入了對傳輸最初旨在保護應用程序的同步網絡連接的依賴性。 正如您的問題所示，我們現在已經完全循環 - 需要本地排隊來保護應用程序免受網絡不可用的影響。 除了現在需要消息的本地持久性的應用程序實際上是（假設的）異步消息傳遞應用程序。

我們當然可以構建一個本地迷你代理來在消息到達中央代理之前對消息進行排隊。 但在我們開始使客戶端代碼變得更加復雜之前（並且邀請無限遞歸來支持我們的異步消息傳遞以及更多異步消息傳遞）我建議再看看原始消息傳遞體系結構 - 將代理本地放在需要的應用程序中那種持久性。

一種方法是將服務提供商應用程序與服務消費者應用程序區別對待。 服務提供者需要深度，持久的消息存儲，並且因為它們通常是事務性的，所以不能允許故障轉移到代理的不同實例（在這種情況下，由XA資源管理器識別的“不同”）。

另一方面，簡單的請求/回復應用程序可以繼續通過網絡匿名連接到輕量級的代理，而不需要永久隊列。 這些應用程序在同步點之外發出請求消息，並等待動態隊列上的回復。 如果他們進行故障轉移，他們可以重新發出請求，並且回復將轉到新節點。 這些是聯網的基於客戶端的消息傳遞的理想候選者，因為它們與特定代理沒有親和力。 只要客戶端和服務器應用程序之間存在網絡跳躍，就不需要確保客戶端使用服務器等進行故障轉移。服務提供商擁有本地代理，服務使用者可以連接兩個（或更多）輕量級中央代理。

當然，這不符合每個異步消息傳遞要求，但它確實提供了一種解決方案，為記錄系統提供了最高的可靠性，並且通過允許服務請求者共享集中式代理，仍然可以節省許可證成本。

Answer 2

哇，T.Rob的很多信息，雖然不確定他是否清楚地回答了這個問題。 :)

簡短的回答是肯定的，它確實適用。 實際上，它意味着由生成客戶端的消息指定，以告訴代理如何處理它。

保持本地持久性沒有多大意義，因為如果代理（服務器）關閉，在嘗試使用producer.send（..）時會遇到JMSException。

-Ed Y.