Web Services vs EJB vs RMI，优缺点？

Question

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

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

Web 服务（SOAP、REST）呢？

Answer 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 服务在理论上很棒，但有一些问题需要注意：

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

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

Answer 2

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

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

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

Answer 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）进行负载平衡。