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

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

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

多年来，消息传递增加了客户端功能，但这更多的是许可成本，而不是体系结构。消息传递客户端连接重新引入了对同步网络连接的依赖关系，而传输最初是用来屏蔽应用程序的。正如您的问题所表明的那样，我们现在已经全面发展了-需要本地排队以保护应用程序免受网络不可用的影响。除了现在，要求消息具有本地持久性的应用程序实际上是（应该是）异步消息传递应用程序。

我们当然可以建立一个本地迷你经纪人，以在消息到达中央代理之前对其进行排队。但是，在使客户端代码变得更加复杂（并邀请无限异步递归来支持异步消息传递和更多异步消息传递）之前，我建议您再看一看原始消息传递体系结构-将代理本地化为需要这样的持久性。

一种解决方法是将服务提供商应用程序与服务使用者应用程序区别对待。服务提供者需要深度，持久的消息存储，并且由于它们通常是事务性的，因此不能被允许故障转移到代理的其他实例（在这种情况下，XA资源管理器可以识别为“不同”）。

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

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