为什么人们使用RMI,或者何时应该使用RMI?我读过Oracle网站上关于RMI的教程,但它没有提供足够的实际示例。
据我所知,软件应尽可能将其模块“无关且分离”。 RMI似乎对我来说是高度耦合的示例。为什么这不是一种糟糕的编码实践?我认为客户端应该只触发指令,而对象的所有实际操作都是由服务器执行的。
为什么人们使用RMI,或者何时应该使用RMI?我读过Oracle网站上关于RMI的教程,但它没有提供足够的实际示例。
据我所知,软件应尽可能将其模块“无关且分离”。 RMI似乎对我来说是高度耦合的示例。为什么这不是一种糟糕的编码实践?我认为客户端应该只触发指令,而对象的所有实际操作都是由服务器执行的。
如果你正在构建应用程序,今天你真的不应该使用RMI,基本上是因为你刚才列出的原因。
在某些情况下(深入遗留或“企业”应用程序),你别无选择。
然而,如果你正在开始一个新项目,其他选项包括:
用于远程服务通信的事实标准。它最大的优点是轻量级且易于理解概念。
理论上,它应该比RMI需要更多的工作,因为你必须手动制定可用的URL、每个URL中接受的动词等。实际上,我认为RMI的样板并没有真正帮助任何人。
坚持使用Java,Jersey是一个出色的库,可以编写自己的RESTful web服务。
如果你想要一个包含电池的解决方案,以便在java中使用RESTful web服务,Yammer公司的Dropwizard提供了一个完整的服务器和框架,只需插入您的业务逻辑,并提供日志记录、数据库连接、序列化、请求路由,甚至度量收集等一切。
与远程服务通信的以前标准。除非你有理由使用它,否则我会坚持使用REST。
Thrift将创建客户端和服务器存根,从而完成大部分工作。通信采用高效的二进制协议。在Java世界中,它正在变得越来越受欢迎,因为许多开源项目在“大数据”领域中使用它。例如Cassandra、HBase(切换到Avro)。Scrooge是Twitter项目,旨在为Scala创建成语存根。
Akka是一个为Scala和Java实现Actor模型的框架。它提供了服务间通信的支持,并且处理了许多底层细节。
根据您的需求,一些框架可能比其他框架更适合。
ClassNotFoundException
掩盖了真正发生的错误。RMI以及类似的EJB都是过去的技术,那个时代相信"透明分布式对象"的幻想。
今天的远程服务基于与RMI完全相反的方法:REST和JSON。
RMI的使用场景则与RPC完全相反,它适用于需要紧密绑定的情况,甚至紧密到仿佛是本地方法调用一样。如果您不需要这种紧密绑定,请勿使用它。整个RPC范式并不适用于所有人,包括我在内,即使我写了一本关于RMI的书,但每种工具都有其用途。例如,Java EE就是建立在RMI模型之上的。