java - Web Services vs EJB vs RMI，优缺点？

Question

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

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

Web 服务(SOAP、REST)呢？

Answer 1

EJB 构建在 RMI 之上。两者都暗示 Java 客户端和 bean。如果您的客户端需要使用其他语言(例如 .NET、PHP 等)编写，请使用 Web 服务或其他与平台无关的有线协议(protocol)，例如 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 周期，除了允许您的客户使用与平台无关的协议(protocol)之外，这些周期并没有提供任何商业值(value)。
3. SOAP 是一个每天都变得越来越臃肿和复杂的标准，但它有很多工具支持。供应商喜欢它，因为它有助于插入 ESB 的销售。 REST 很简单，但没有那么好理解。工具不支持。

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