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所拥有的一切以及更多通过容器（对象池，事务管理等）

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

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

Answer 3

Re：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）进行负载均衡。