Web Services vs EJB vs RMI，优缺点？

Question

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

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服务将为您提供更多可移植性。 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 /码头，或EJB容器例如JBoss / glassfish的平衡。