3

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

4

3 回答 3

3

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

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

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

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

于 2008-09-16T14:21:51.760 回答
1

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

于 2008-09-16T13:01:19.253 回答
0

SUN RMI 为我们打破了。

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

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

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

于 2010-05-17T14:31:45.533 回答