请问java RMI的意义？ [关闭]

Posted 2023-02-16

【中文标题】请问java RMI的意义？ [关闭]

【英文标题】：the significance of java RMI please? [closed]

【发布时间】：2012-12-28 21:53:23

【问题描述】：

人们为什么使用 RMI，或者我应该什么时候使用 RMI？我在 oracle 的网站上阅读了有关 RMI 的那些教程。但它没有提供足够的实际例子。

据我了解，软件的模块应尽可能“不相关且分离”。在我看来，RMI 似乎是高耦合的一个例子。为什么这不是一个糟糕的编码实践？我认为客户端应该只触发指令，而对象的所有实际操作都是由服务器完成的。

【问题讨论】：

任何技术都会受到某种形式的耦合影响。您可以选择直接使用套接字，这是一种耦合形式 - 或者 HTTP 或 FTP - 您已经将自己缩小到协议的功能。 RMI 是一种解决方案，旨在允许传输对象和对象状态，而无需转换层。如果您只需要与其他 Java 服务进行通信，RMI 不是一个糟糕的解决方案。但是，如果您需要（或您的服务想要）使用其他语言进行交流，那么还有其他选择。这将取决于您的要求。

这就是它设计的目的，但它实际上并非如此。透明地序列化任意对象图的梦想早已不复存在。 RMI 真正提倡的是令人尴尬的大量样板文件，称为数据传输对象，它实际上模拟了面向文档的进程间通信，但代价是荒谬的。

好问题@Will。在你的整个职业生涯中不断提出这些问题，以找出所有这些只因为某些营销人员认为这是个好主意而存在的废话技术

IMO，你能得到的最好的徽章是它被关闭了，因为它没有建设性：D

【参考方案1】：

任何时候你有一个功能需要一些大型集中计算能力或一些昂贵的资源（例如一个巨大的数据库），但你的输出需要很多地方无法部署这样的工作负载，那么你会看看远程方法调用。考虑一下网络，您的桌面上没有 Google 的副本来进行您可能想要计算的任何搜索，您在需要结果的那一刻远程调用 Google 的服务器。 RMI 是一种协议/系统，用于跨服务器分发您的应用程序并分离出需要访问该代码结果的客户端。

RMI 还可以作为保护应用程序各个方面的一种方式（如专有算法）。 RMI 不是唯一的方法，您还可以使用 HTTP、SOAP 等。许多其他方法提供了其他功能，例如真正的语言透明性、更简单、更高效的实现以及更好的解耦。

这是来自 documentation 的 RMI 既定目标

Java 编程中支持分布式对象的目标 语言是：

支持无缝远程调用不同虚拟机中的对象 支持从服务器到小程序的回调 以自然的方式将分布式对象模型集成到 Java 编程语言中，同时保留大部分 Java 编程 语言的对象语义 使分布式对象模型和本地 Java 平台的对象模型之间的差异明显 尽可能简单地编写可靠的分布式应用程序 保留 Java 平台运行时环境提供的类型安全性 支持远程对象的各种引用语义；例如实时（非持久）引用、持久引用和惰性引用 激活 维护由安全管理器和类加载器提供的 Java 平台的安全环境 所有这些目标的基础是 一般要求RMI模型既简单（易于使用） 并且自然（非常适合该语言）。

【讨论】：

抱歉，您的帖子听起来对 RMI 太积极了。投票给你以强调其他答案中的怀疑声音

如果我能和 2013 年的自己交谈，我会说的大致相同:)

哈哈，让我开心：D

【参考方案2】：

RMI 是针对完全相反的情况，在这种情况下您想要紧密绑定，紧密到看起来像是一个本地方法调用。如果您不想要，请不要使用它。整个 RPC 范式并不适合所有人，包括我，尽管我写了一本关于 RMI 的书，但每个工具都有其用途。例如，Java EE 是基于 RMI 模型构建的。

【讨论】：

> 'Java EE 建立在 RMI 模型之上'听起来有点值得商榷。我的意思是，Java EE 由许多部分组成，其中大多数与 RMI 无关。即使是最初构建为更高级别 RMI 抽象的 EJB 现在也很少使用它，直到 Java EE 速度负责人提议完全删除它。

@ArjanTijms 好的，是基于 RMI 模型构建的，至少就 EJB 而言。在部署数量之前仍然是一项非常重要的工作。我不知道你引用的提案：你有参考吗？

at least as far as EJB are concerned - 这已经更准确了一点；) 同样，Java EE 不仅仅是 EJB。无论如何，这是参考：java.net/jira/browse/JAVAEE_SPEC-16 它是修剪 CORBA 的一部分，并且作为附属品整个 @Remote 和因此 RMI/IIOP 都在修剪的桌子上。

@ArjanTijms 链接断开。

我没有看到 Rest 和 Soap 的耦合比 RMI 更紧密，唯一的区别是，RMI 在幕后耦合并让编译器检查客户端-服务器接口，而 Rest 和 Soap 让你耦合并签入应用程序代码。如果在 Json 或 XML 中不满足客户端-服务器接口，它会破坏您的应用程序，因此您必须检查代码或 xsd 中的所有内容。

【参考方案3】：

您确实不应该将 RMI 用于您今天构建的任何应用程序，主要是出于您刚刚列出的原因。

在某些情况下（潜入旧版或“企业”应用程序）您别无选择。

但是，如果您要开始一个新项目，其他选项是：

基于 HTTP 的 REST + JSON

与远程服务通信的事实标准。它最大的优点是重量轻，易于掌握概念。

理论上它应该比 RMI 需要更多的工作，因为您必须手动制作可用的 URL、每个 URL 中接受的动词等。在实践中，我会说 RMI 的样板文件并不能真正帮助任何人。

坚持使用 java，Jersey is a brilliant library 编写自己的 RESTful Web 服务。

如果您想要一个包含电池的解决方案，用于使用 java 的 RESTful Web 服务，Yammer 的好人Dropwizard 为您提供了一个完整的服务器和框架，准备好插入您的业务逻辑，并提供日志记录、数据库连接、序列化、请求路由，甚至是开箱即用的指标收集。

肥皂

与远程服务通信的先前标准。除非你有理由使用它，否则我会坚持使用 REST。

节俭

Thrift 将创建一个客户端和一个服务器存根，基本上完成大部分工作。通信采用高效的二进制协议。它在 Java 世界中越来越受欢迎，因为它被“大数据”领域的许多开源项目使用。例如，Cassandra、HBase（切换到 Avro）。 Scrooge 是一个 twitter 项目，用于为 scala 创建惯用的 thrift 存根。

Akka 演员

Akka is framework 为 Scala 和 Java 实现了 Actor model。包括服务间通信的规定，并处理许多底层细节。我

---

根据您的需要，有些会比其他的更合适。

【讨论】：

更新了我的答案以表明有时，没有办法解决它:)

如果我想构建一个客户端-服务器应用程序，其中客户端和服务器是用 java 编写的。我还应该使用 REST、JSON 吗？

即使您的客户端和服务器是用 java 编写的，我仍然会坚持使用 HTTP + JSON。如果有一天，您想要一个 android 或 ios 应用程序怎么办？如果您需要将服务公开给另一个不是用 Java 编写的服务怎么办？即使您永远不需要做任何这些，RMI 也是一种痛苦，它的基本前提是有缺陷的，我不会使用它。

【参考方案4】：

您是对的，RMI 是服务提供者和服务消费者之间耦合过紧的一个例子。它甚至比乍一看更糟糕：您永远不知道您可能会被推送到客户端，从而导致ClassNotFoundException 掩盖了发生的真正错误。 RMI 和类似的 EJB 是过去的技术，过去相信“透明分布的对象”的错觉。

今天的远程服务基于与 RMI 完全相反的方法：REST 和 JSON。