关于jakarta ee：在Web和业务层之间使用RMI或JMS有什么优缺点？

对于典型的Web客户端到Servlet / WS到业务层(Spring或EJB)应用程序，在诸如远程RPC或用于Web(Servlet)层的消息传递到远程业务层的方法之间需要权衡取舍，除了基本的同步/异步方面？

---

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

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

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

例如，请参阅Spring Remoting的Camel实现，然后允许您使用这些传输和协议中的任何一个，例如RMI，JMS甚至纯HTTP，电子邮件，文件或XMPP-然后使用简单的URI字符串轻松地在它们之间进行切换变化。

---

我们通过Spring使用RMI，发现它非常易于使用，相当健壮和快速。尽管我们的要求是要有一个响应能力强的链接，并且实际上并不需要添加消息传递组件。

---

SUN RMI为我们破产了。

一个非常长时间运行的应用程序的设置和垃圾收集，并进行连续的测量。我们正在修补程序，以使其能够连续工作。我们运行的JMS应用程序不会遇到RMI出现的内存不足错误或gc问题。需要定期调用System.gc()且不与增量收集一起工作以恢复资源的所有内容都被编码为错误。

通过JDK 6和正确的属性设置，RMI的可靠性得以提高，但是JHC是一个坚固的框架。通过在nio中使用通道并修复system.gc()的sun nio使用，可以极大地改善RMI。

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

---