Java RMI 和 JMS 有什么区别？
在用 Java 设计分布式应用程序时，似乎有一些技术可以解决同类问题。我已经简要阅读了 Java 远程方法调用 和 Java 消息服务，但很难真正看出区别。 Java RMI 似乎比 JMS 耦合更紧密，因为 JMS 使用异步通信，但除此之外我没有看到任何大的差异。
- 它们之间有什么区别？
- 其中一个比另一个新吗？
- 哪一种在企业中更常见/受欢迎？
- 他们相比彼此有什么优势？
- 什么时候一个人比另一个人更受青睐？
- 它们的实施难度有很大差异吗？
我还认为 Web 服务 和 CORBA 解决了同样的问题。
When designing an distributed application in Java there seem to be a few technologies that address the same kind of problem. I have briefly read about Java Remote Method Invocation and Java Message Service, but it is hard to really see the difference. Java RMI seems to be more tightly coupled than JMS because JMS uses asynchronous communication, but otherwise I don't see any big differences.
- What is the difference between them?
- Is one of them newer than the other one?
- Which one is more common/popular in enterprises?
- What advantages do they have over each other?
- When is one preferred over the other?
- Do they differ much in how difficult they are to implement?
I also think that Web Services and CORBA address the same problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您已经了解方法调用。如果您想要调用该方法的对象位于另一台计算机上怎么办？您使用 RMI 将调用从一台计算机（客户端）发送到另一台计算机（服务器）。客户端将等待（或“阻塞”），直到结果从服务器返回。这称为同步操作。
JMS 不同：它允许一台计算机向另一台计算机发送消息，例如电子邮件。第一个不需要等待响应：它可以继续做它想做的任何工作。甚至可能没有回应。两个计算机系统不一定完全同步工作，因此这称为异步。
另一种思考差异的方式是：RMI 就像打电话，而 JMS 就像发送短信。
RMI 比 JMS 稍微老一些，但这并不重要。这两个概念比java要古老得多。
复杂程度没有太大区别。我认为你应该尝试为每一个都做一个教程。 RMI 和 RMI sun.com/products/jms/tutorial/index.html" rel="noreferrer">JMS
如果您从头开始一个项目，并且不确定要使用哪一个，那么可能会使用同步/异步问题是最好的决策因素。如果您正在开发现有系统，那么最好不要引入太多新技术。因此，如果他们已经在使用其中一种，那么我建议最好还是坚持使用那个。
You already know about method calls. What if the object that you want to invoke the method on is on a different computer? You use RMI to send the call from one computer (client) to the other (server). The client will wait (or "block") until the result comes back from the server. This is called synchronous operation.
JMS is different: it lets one computer send a message to another - like email. The first one doesn't have to wait for a response: it can keep doing whatever work it wants. There may not even be a response. The two computer systems don't necessarily work exactly in step, so this is called asynchronous.
Another way of thinking about the difference: RMI is like making a phone call, and JMS is like sending a text message.
RMI is a little older than JMS, but that's not really relevant. The two concepts are much much older than java.
There's not much difference in the complexity. I think that you should try doing a tutorial on each one. RMI and JMS
If you're starting a project from scratch, and you're not sure which one to use, then probably the synchronous/asynchronous issue is the best decision factor. If you're working on an existing system, it's probably best not to introduce too many new technologies. So if they're already using one, then I'd suggest it's probably best to stick with that one.
你无法真正比较这两者，即苹果和橙子。
RMI 是远程过程调用 (RPC) 的一种形式。它是一个轻量级的、Java 特定的 API，希望调用者和接收者在通信时可用。
JMS 是一个可靠的消息传递 API。 JMS 提供程序适用于各种消息传递系统。如果提供者实现了这一点，即使其中一方不可用，也可以传递消息。我熟悉的两个是TIBCO和IBM MQ。
RMI 不处理保证交付或异步响应，JMS 可以，具体取决于提供者。
JMS 允许可用性意义上的松耦合。
“Web 服务”允许协议和数据意义上的松散耦合，但没有详细说明可靠消息传递的方式，尽管有些实现确实包括这一点（Windows Communication Foundation），有些则没有。
编辑：根据评论进行修改。当我在 2010 年写下这个答案时，我的经历实际上只有一个 JMS 提供程序，而且我实际上并不知道没有默认的 JMS 提供程序。
You cannot really compare the two, its apples and oranges.
RMI is a form of Remote Procedure Call (RPC). It is a lightweight, Java specific API that expects the caller and receiver to be available at the time of communication.
JMS is a reliable messaging API. JMS providers exist for various messaging systems. Messages can be passed even if one of the parties is not available if the provider implements that. The two I am familiar with are TIBCO and IBM MQ.
RMI doesn't deal with guaranteed delivery or asynchronous responses, JMS may, depending on the provider.
JMS allows loose coupling in the sense of availability.
"Web Services" allows loose coupling in the sense of protocol and data but doesn't specify much in the way of reliable messaging, though some implementations do include this (Windows Communication Foundation) and some don't.
EDITED: Revised per comments. When I wrote this answer in 2010 my experience was actually with only one JMS provider and I didn't actually know there was no default JMS provider.