java - 为 JMS 客户端指定消息持久性

Question

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

还有一个问题:如果我有一个 JMS 客户端(不是服务器)生成消息并将它们发送到服务器上的目标队列，那么这个 producer.setDeliveryMode(DeliveryMode.PERSISTENT);还适用吗？

我的意思是 JMS 客户端是否支持任何机制来持久化消息，或者只有提供者/服务器软件附带的机制？

谢谢

Answer 1

由于 JMS 只是一个规范，因此没有什么可以阻止实现在客户端提供某种级别的消息持久性。然而，在实践中，所有实现(无论如何我都知道)将其委托(delegate)给代理。

请记住，消息传递最初设计为在每个节点都有一个代理，就像每个节点也有一个 TCP/IP、LU6.2 或其他传输堆栈一样。从这个意义上说，消息传递严格来说应该是一种传输，而不是像数据库这样的中央服务。目的是提供一种本地服务，使应用程序免受网络不可用以及无数可用的同步传输协议(protocol)的影响。在此模型中，代理始终在本地，唯一的网络通信是在两个代理之间。

多年来，消息传递增加了客户端功能，但这更多的是许可成本而非架构。消息传递客户端连接重新引入了对同步网络连接的依赖，而传输最初旨在屏蔽应用程序。正如您的问题所说明的那样，我们现在已经绕了一圈 - 要求本地排队以保护应用程序免受网络不可用的影响。除了现在需要本地持久化消息的应用程序实际上是(假定的)异步消息传递应用程序。

我们当然可以构建一个本地迷你代理，在消息到达中央代理之前对消息进行排队。但是在我们让客户端代码变得更加复杂之前(并邀请无限递归来支持我们的异步消息传递更多的异步消息传递)我建议再看看原始消息传递架构 - 将代理放在需要的应用程序本地这种程度的坚持。

一种方法是区别对待服务提供者应用程序和服务消费者应用程序。服务提供者需要深度持久的消息存储，并且因为它们通常是事务性的，所以不能允许故障转移到代理的不同实例(在本例中为 XA 资源管理器识别的“不同”)。

另一方面，简单的请求/回复应用程序可以继续通过网络匿名连接到没有永久队列的轻量级代理层。这些应用程序在同步点之外发出请求消息，并在动态队列中等待回复。如果他们故障转移，他们可以重新发出请求，回复将到达新节点。这些是网络化的、基于客户端的消息传递的理想候选者，因为它们与特定代理没有亲和性。只要客户端和服务器应用程序之间存在网络跃点，就无需确保客户端通过服务器进行故障转移等。服务提供者有本地代理，服务消费者有两个(或更多)轻量级中央代理来连接.

当然，这并不能满足所有异步消息传递要求，但它确实提供了一种解决方案，该解决方案可为记录系统提供最高可靠性，并且通过允许服务请求者共享集中代理来节省许可成本。