请问javarmi的意义是什么？

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

---

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

任何时候你有一个功能需要一些大型集中计算能力或一些昂贵的资源（例如一个大型数据库），但您的输出需要在许多无法部署此类工作负载的地方，然后您可以查看远程方法调用。考虑一下Web，你的桌面上没有一个谷歌的拷贝，你想计算的任何搜索，在你想要结果的时候远程调用谷歌的服务器。RMI是一种协议/系统，用于跨服务器分发应用程序，并分离需要访问该代码结果的客户端

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

以下是RMI从

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

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

---

您是对的，RMI是服务提供者和服务使用者之间耦合过紧的一个例子。而且它甚至比乍一看更糟糕：您永远不知道可能会将什么异常推送到客户端，从而导致一个

ClassNotFoundException

，它掩盖了发生的真正错误。RMI和类似的EJB都是过去的技术，过去相信“透明分布对象”的错觉

---

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

您真的不应该在今天构建的任何应用程序中使用RMI，基本上是因为您刚才列出的原因

在某些情况下（跳入遗留或“企业”应用程序），您别无选择

但是，如果您正在启动一个新项目，其他选项包括：

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

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

坚持使用java，编写自己的RESTful web服务

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

肥皂 以前用于与远程服务通信的标准。除非你有理由使用它，否则我会坚持休息

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

阿克卡演员 它实现了针对Scala和Java的。包括服务间通信的规定，并处理引擎盖下的许多细节。我

---

---

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

RMI适用于完全相反的情况，您需要紧密绑定，紧密到看起来像是本地方法调用。如果你不想那样，就不要用它。虽然我写了一本关于RMI的书，但整个RPC范式并不适合所有人，包括我，但每个工具都有它的用途。例如，Java EE是基于RMI模型构建的。

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