Web Services vs EJB vs RMI，优缺点？

Posted 2023-02-16

【中文标题】Web Services vs EJB vs RMI，优缺点？

【英文标题】：Web Services vs EJB vs RMI, advantages and disadvantages?

【发布时间】：2011-01-02 02:19:12

【问题描述】：

如果所有工作都在那里完成，我的网络服务器将很快超载。我要在它后面架起第二台服务器来处理数据。

EJB 与 RMI 相比有什么优势，反之亦然？

Web 服务（SOAP、REST）呢？

【参考方案1】：

EJB 构建在 RMI 之上。两者都暗示 Java 客户端和 bean。如果您的客户端需要使用其他语言（例如 .NET、php 等）编写，请使用 Web 服务或其他与平台无关的有线协议，例如 HTTP 或 XML over HTTP 或 SOAP。

如果您选择 RMI，则不需要 Java EE EJB 应用服务器。您必须使客户端和服务器 JVM 保持同步；不升级服务器就无法升级客户端。您必须编写 EJB 应用服务器为您提供的所有服务（例如，连接池、命名和目录服务、池、请求队列、事务等）。

仔细想想，RMI 是相当低的水平。为什么你会一直回到 CORBA？

一个更好的选择是 EJB 3.0 与 Spring。这取决于您是否喜欢 POJO 开发，是否想要选择 ORM 和 JPA 之外的关系技术等。

您可以为 Java EE 应用服务器付费（例如，WebLogic、WebSphere）或使用开源服务器（JBOSS、Glassfish 和 OpenEJB 和 ActiveMQ），或者您可以坚持使用 Spring 并部署在 Tomcat、Jetty、Resin 或任何其他 servlet/JSP 引擎。

Spring 通过与技术无关，提供了很多选择：持久性（Hibernate、iBatis、JDBC、JDO、JPA、TopLink）、远程处理（HTTP、Hessian、Burlap、RMI、SOAP Web 服务）等。

EJB 3.0 是一个有许多供应商的规范； Spring 只能从 Spring Source 获得。

我会推荐Spring。它非常坚固，有很大的牵引力，不会去任何地方。它使您的所有选择都保持开放。

Web 服务在理论上很棒，但有一些问题需要注意：

延迟。福勒的分布式对象第一定律：“不要！”由许多细粒度的分布式 SOAP 服务组成的架构将优雅、美观且像糖蜜一样缓慢。分发前请仔细考虑。 从 XML 编组到对象并返回会消耗 CPU 周期，除了允许您的客户端使用与平台无关的协议之外，这些周期没有提供任何业务价值。 SOAP 是一个每天都变得越来越臃肿和复杂的标准，但它有很多工具支持。供应商喜欢它，因为它有助于推动 ESB 的销售。 REST 很简单，但没有那么好理解。工具不支持。

Spring 的 web 服务模块非常好，但要小心选择这种方式部署。用 POJO 服务接口来写。这些将允许您获得所需的概念隔离，将部署选择推迟到最后一刻，如果第一个想法表现不佳，您可以改变主意。

【讨论】：

Spring Web 服务？春天是一个值得搜索的大词。 :-)

【参考方案2】：

在 EJB 和 RMI 之间，EJB 肯定会更好 - 它拥有 RMI 所拥有的一切，并且通过容器（对象池、事务管理等）提供更多功能

在 EJB 和 Web 服务之间，如果您希望将来能够从非 Java 应用程序调用 Web 服务，那么 Web 服务将为您提供更多的可移植性。 EJB 再次为您提供了诸如事务管理和池之类的东西，您可能无法通过 Web 服务“开箱即用”。

就个人而言，如果我这样做，我可能会使用 EJB 或一些类似的远程对象框架（我也想到了 spring 远程处理）。如果您需要从非 Java 应用程序调用对象的能力，您可以随时根据需要在您的 EJB 前面使用简单的 Web 服务代理。

【讨论】：

您能快速比较一下 Spring Remoting 和 EJB 吗？我不需要使用非 Java 应用程序的能力，但过去发现 EJB 很笨拙，而 Web 服务感觉更直接，更易于编写/维护。

@Dean J - EJB 在旧版本的 J2EE 中相当复杂，但在 3.0 中已大大简化。 spring remoting我用的不多，但是这里有一篇文章比较一下两者：onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html?page=1

我会看看那篇文章，并重新评估 EJB3； EJB2 感觉很丑。

@Dean J - Spring Remoting 和 EJB 不必是单独的选择。 Spring 只是为远程服务调用提供抽象层，其中隐藏了实际的远程协议。我们将 Spring Remoting over HTTP、EJB 和 JMS 用于当前系统中的相同服务接口。协议只是根据调用者的位置而改变（Http 用于客户端应用程序，EJB 用于容器内的另一个服务，JMS 来自受信任的非 JEE 服务器）。

【参考方案3】：

关于：Web 服务（SOAP、REST） 如果您的后端服务器不打算公开，那么您不会从使用独立于平台的 Web 服务接口（例如 SOAP/REST）中获得任何好处。 实际上，您会因为在远程调用中包装数据的 XML 标记所增加的所有开销而受到惩罚，更不用说将 XML 编组和解组为 java 对象所产生的影响了。 尽管任何分布式调用都需要某种程度的序列化——甚至是 RMI/EJB，但在序列化为人类可读的 XML 时代价更高。

您可能根本不需要在 java 中编写远程调用，您可以在服务前面使用一个普通的 apache httpd 实例，该实例被配置为使用 mod_jk 或 mod_proxy 跨多个 java 服务器进行负载平衡。 这些模块可用于跨 servlet 容器（如 tomcat/jetty）或 ejb 容器（如 jboss/glassfish）进行负载平衡。

【讨论】：

事实上，有了 Node.js 服务器和 JSON REST API，我 100% 确信 javascript 对象的序列化和反序列化会破坏任何 Java。