在 Web 层和业务层之间使用 RMI 或 JMS 有何优缺点？
对于典型的 Web 客户端到 Servlet/WS 到业务层（Spring 或 EJB）应用程序，除了 Web (Servlet) 层到远程业务层的远程 RPC 或消息传递等方法之外，还有哪些权衡基本同步/异步方面？
For a typical Web client -to- Servlet/WS -to- Business Tier (Spring or EJB) app, what are the trade-offs of approaches like remote RPC or messaging for Web (Servlet) tier to remote Business tier, aside from the basic sync/async aspects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
网络客户端是指网络浏览器吗？ 如果是这样，我的建议是查看 DWR 或 JAX-RS 之类的东西。 RMI 或 JMS 仅当双方都是 Java 代码时才真正起作用。
对于任何远程技术，使用它们的最大问题往往是该技术对您的业务对象的侵入程度。 例如，在任何地方使用 RMI 接口/异常或在业务代码中使用 JMS API。
我的建议是在 Java 中到处使用 POJO，然后使用类似 的技术Spring Remoting 将您的中间件分层，无论是 RMI 还是 JMS 还是其他什么 - 但将中间件代码与您的业务逻辑完全解耦，以便您可以随时在技术之间切换（并使您的业务逻辑代码更简单、更集中）关于您的业务问题）。
例如，请参阅 Spring Remoting 的 Camel 实现，它允许您使用 < a href="http://activemq.apache.org/camel/components.html" rel="nofollow noreferrer">任何这些传输和协议，例如 RMI、JMS 甚至纯 HTTP、电子邮件、文件或 XMPP - 然后使用简单的 URI 字符串更改在它们之间轻松切换。
By web client do you mean web browser? If so looking at stuff like DWR or JAX-RS are my recommendations. RMI or JMS only really work when both sides are Java code.
With any remoting technology the biggest issue using them tends to be how intrusive the technology becomes on your business objects. e.g. using RMI interface/exceptions everywhere or using the JMS APIs inside your business code.
My recommendation is to use POJOs everywhere in Java then use a technology like Spring Remoting to layer on your middleware whether its RMI or JMS or whatever - but totally de-couple the middleware code from your business logic so you can switch between technologies at any time (and keep your business logic code simpler and focussed on your business problem).
For example see the Camel implementation of Spring Remoting which then allows you to use any of these transports and protocols such as RMI, JMS or even plain HTTP, email, files or XMPP - then switch between them trivially using a simple URI string change.
SUN RMI为我们打破了。
具有连续消息传递的长时间运行的应用程序的设置和垃圾收集。 我们正在修补以使其持续工作。 我们运行的 JMS 应用程序不会像 RMI 那样出现内存不足错误或 gc 问题。 任何需要定期调用 System.gc() 并且不能使用增量收集来恢复资源的代码都是错误的。
RMI 可靠性随着 JDK 6 和正确的属性设置而提高，但是 JHC，它是一个 bodgey 框架。 通过使用 nio 中的通道并修复 sun nio 对 system.gc() 的使用，RMI 将得到极大的改进。
正确的答案 - 将通信（机制）与域代码分开。 RPC 是紧密耦合的，协议和应用程序可能会相互干扰。 JMS 将协议与应用程序分开，这是一个更好的范例。
SUN RMI broke for us.
The settings and garbage collection for a very long running application with continuous meassaging. We are patching to make it work continuously. JMS applications we run don't get the out of memory errors or gc problems that RMI does. Anything that needs to call System.gc() periodically and doesn't work with incremental collection to recover resources is coded wrong.
RMI reliability improves with the JDK 6 and the correct property settings, but JHC, it's a bodgey framework. RMI would be vastly improved by using channels in nio and fixing the sun nio uses of system.gc().
The correct answer - seperate communication (mechanism) from the domain code. RPC is tightly coupled, and the protocol and application can interfere with each other. JMS seperates the protocol from the application, a much better paradigm.
我们通过 Spring 使用 RMI，发现它非常易于使用、相当健壮且快速。 尽管我们的要求是具有相当响应性的链接，并且没有真正需要添加消息传递组件。
We use RMI via Spring and find it very easy to use, fairly robust and fast. Although our requirements were for a fairly responsive link and there was no real need to add a messaging component.