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

Question

如果所有的工作都在那里完成，我的web服务器很快就会超载。我要在它后面架设第二台服务器，来处理数据。

EJB相对于RMI的优势是什么，反之亦然？

那么web服务(SOAP、REST)呢？

Answer 1

EJB是建立在RMI之上的。两者都包含Java客户端和bean。如果您的客户端需要用其他语言编写(例如，.NET、PHP等)。使用web服务或其他与平台无关的连接协议，比如HTTP或基于HTTP或SOAP的XML。

如果选择RMI，则不需要Java EE EJB应用服务器。您必须使客户端和服务器JVM保持同步；如果不升级服务器，则无法升级客户端。您必须编写EJB应用服务器为您提供的所有服务(例如，连接池、命名和目录服务、池、请求队列、事务等)。

如果你仔细想想，RMI是相当低的级别。为什么你要一直放弃使用CORBA呢？

更好的选择是EJB3.0而不是Spring。这取决于你是否喜欢POJO开发，除了ORM和JPA之外，还想要选择关系技术。

您可以购买Java应用服务器(例如，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 service)等。

EJB3.0是一个包含许多供应商的规范；Spring只能从Spring Source获得。

我推荐Spring。它非常坚固，有很大的牵引力，不会有任何进展。它给你留下了所有选择的余地。

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

1. 延迟。分布式对象的福勒第一定律：“不要！”由许多细粒度的分布式SOAP服务组成的体系结构将是优雅、美丽和缓慢的。在distributing.
2. Marshalling之前要仔细考虑，从XML到对象再返回会消耗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

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 )之间实现负载平衡。