Web服务vs EJB vs RMI，优点还是缺点？

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

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

那么Web服务（SOAP，REST）呢？

EJB是build立在RMI之上的。两者都意味着Java客户端和bean。如果你的客户需要用别的东西（例如，.NET，PHP等）编写的话，可以使用Web服务或者其他可以说与平台无关的有线协议的东西，比如HTTP或XML over HTTP或者SOAP。

如果您selectRMI，则不需要Java EE EJB应用程序服务器。您必须保持客户端和服务器JVM同步; 不升级服务器就无法升级客户端。您必须编写EJB应用程序服务器为您提供的所有服务（例如，连接池，命名和目录服务，池化，请求排队，事务处理等）。

当你考虑这个时，RMI是相当低的水平。为什么要一路回到CORBA？

EJB 3.0和Spring比较好。这取决于你是否喜欢POJO开发，除了ORM和JPA之外还需要关系型技术的select。

您可以支付Java EE应用服务器（例如WebLogic，WebSphere）或使用开放源代码（JBOSS，Glassfish和OpenEJB和ActiveMQ），或者您可以坚持使用Spring并在Tomcat，Jetty，Resin或其他任何servlet上部署/ JSP引擎。

Spring通过技术无关性提供了很多select：持久化（Hibernate，iBatis，JDBC，JDO，JPA，TopLink），远程处理（HTTP，Hessian，Burlap，RMI，SOAP Web服务）等等。

EJB 3.0是许多供应商的规范; Spring只能从Spring Source获得。

我会推荐spring 。这是非常坚实的，有很大的牵引力，不会去任何地方。它会让所有选项都打开。

Web服务在理论上是伟大的，但是有一些问题需要注意：

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

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

在EJB和RMI之间，EJB肯定会更好 – 它拥有RMI所有的东西，还有更多的通过容器（对象池，事务pipe理等）

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

就个人而言，如果我这样做，我可能会使用EJB或一些类似的远程对象框架（弹簧远程也想到）。如果您需要从非Java应用程序调用对象的function，则可以根据需要始终使用简单的Web服务代理来对您的EJB进行前置处理。

回复：Web服务（SOAP，REST）如果您的后端服务器不会公开的暴露，那么您使用独立于平台的Web服务接口（如SOAP / REST）没有任何好处。
事实上，你将会受到惩罚，XML标记通过远程调用来包装数据所带来的所有开销，更不用说从编组和将XML解组到Java对象所带来的冲击。
尽pipe任何分布式调用都需要一定程度的序列化 – 甚至是RMI / EJB，但是当序列化为可读的XML时价格更高。

您可能不需要用java编写远程调用代码，您可以使用简单的apache httpd实例来提交服务，该实例被configuration为使用mod_jk或mod_proxy在多个java服务器之间进行负载平衡。
这些模块可用于在servlet容器（如tomcat / jetty）或ejb容器（如jboss / glassfish）之间进行负载平衡。