在 Web 层和业务层之间使用 RMI 或 JMS 有何优缺点？

题

对于典型的 Web 客户端到 Servlet/WS 到业务层（Spring 或 EJB）应用程序，除了 Web (Servlet) 层到远程业务层的远程 RPC 或消息传递等方法之外，还有哪些权衡基本同步/异步方面？

解决方案

网络客户端是指网络浏览器吗？如果是这样，我的建议是查看 DWR 或 JAX-RS 之类的东西。RMI 或 JMS 仅当双方都是 Java 代码时才真正起作用。

对于任何远程技术，使用它们的最大问题往往是该技术对您的业务对象的侵入程度。例如在任何地方使用 RMI 接口/异常或在业务代码中使用 JMS API。

我的建议是在 Java 中到处使用 POJO，然后使用类似的技术春季远程处理分层在您的中间件上，无论是 RMI 还是 JMS 还是其他什么 - 但将中间件代码与您的业务逻辑完全分离，以便您可以随时在技术之间切换（并使您的业务逻辑代码更简单并专注于您的业务问题）。

例如，请参阅 Spring Remoting 的 Camel 实现然后您可以使用这些传输和协议中的任何一个例如 RMI、JMS 甚至普通的 HTTP、电子邮件、文件或 XMPP - 然后使用简单的 URI 字符串更改在它们之间轻松切换。

其他提示

我们通过 Spring 使用 RMI，发现它非常易于使用、相当健壮且快速。尽管我们的要求是具有相当响应性的链接，并且没有真正需要添加消息传递组件。

SUN RMI为我们打破了。

具有连续消息传递的长时间运行的应用程序的设置和垃圾收集。我们正在修补以使其持续工作。我们运行的 JMS 应用程序不会像 RMI 那样出现内存不足错误或 gc 问题。任何需要定期调用 System.gc() 并且不能使用增量收集来恢复资源的代码都是错误的。

RMI 可靠性随着 JDK 6 和正确的属性设置而提高，但是 JHC，它是一个 bodgey 框架。通过使用 nio 中的通道并修复 sun nio 对 system.gc() 的使用，RMI 将得到极大的改进。

正确的答案 - 将通信（机制）与域代码分开。RPC 是紧密耦合的，协议和应用程序可能会相互干扰。JMS 将协议与应用程序分开，这是一个更好的范例。

许可以下： CC-BY-SA 和归因