Web服务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引擎。持久性（Hibernate的，iBatis的，JDBC，JDO，JPA的TopLink），远程（HTTP，黑森州，粗麻布，RMI，SOAP Web服务）等

：

春天由是技术无关提供了很多的选择

EJB 3.0是许多供应商的规范;春天只能从Spring Source获得。我会推荐Spring。这是非常坚实的，有很多的牵引力，不会去任何地方。它会让所有选项都打开。

Web服务是在理论上很好，但也有一些需要注意的陷阱：

1. 延迟。福勒的第一个分布式对象定律：“不要！”由许多细粒度的分布式SOAP服务组成的体系结构将如蜜糖般优雅，美丽和缓慢。分发前仔细考虑。
2. 从XML到对象和回程的编组会消耗CPU周期，除了允许您的客户说出平台无关的协议外，这些CPU周期不提供任何业务价值。
3. SOAP是一种每天都变得更加臃肿和复杂的标准，但它有很多工具支持。供应商喜欢它，因为它有助于推动ESB的销售。 REST很简单，但不太了解。它不受工具支持。

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

Answer 2

EJB和RMI之间，EJB肯定会更好 - 它的一切RMI拥有和更多通过容器（对象池，事务管理等）

EJB和Web服务之间，Web服务将给予如果您希望将来能够从非Java应用程序中调用它们，那么您便于携带。 EJB再次为您提供事务管理和池化等功能，您可能无法通过Web服务“开箱即用”。就个人而言，如果我这样做了，我可能会使用EJB或类似的远程对象框架（Spring Remoting也浮现在脑海中）。如果您需要从非Java应用程序调用对象的功能，则可以根据需要随时使用简单的Web服务代理将EJB对准。

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