Java Web Services vs EJB vs RMI，优缺点？

Web Services vs EJB vs RMI, advantages and disadvantages?

提问by Dean J

My web server would be overloaded quickly if all the work were done there. I'm going to stand up a second server behind it, to process data.

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

What's the advantage of EJB over RMI, or vice versa?

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

What about web services (SOAP, REST)?

Web 服务（SOAP、REST）怎么样？

采纳答案by duffymo

EJBs are built on top of RMI. Both imply Java clients and beans. If your clients need to be written in something else (e.g., .NET, PHP, etc.) go with web services or something else that speaks a platform-agnostic wire protocol, like HTTP or XML over HTTP or SOAP.

EJB 构建在 RMI 之上。两者都意味着 Java 客户端和 bean。如果您的客户端需要使用其他语言（例如 .NET、PHP 等）编写，请使用 Web 服务或其他使用与平台无关的有线协议的语言，如 HTTP 或 XML over HTTP 或 SOAP。

If you choose RMI, you don't need a Java EE EJB app server. You have to keep client and server JVMs in synch; you can't upgrade the client without upgrading the server. You have to write all the services that the EJB app server provides for you (e.g., connection pooling, naming and directory services, pooling, request queuing, transactions, etc.).

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

RMI is quite low level when you think about it. Why would you drop all the way back to CORBA?

仔细想想，RMI 是相当低的水平。为什么你会一路退回到 CORBA？

A better choice is EJB 3.0 versus Spring. It depends on whether you like POJO development, want a choice of relational technologies besides ORM and JPA, among other things.

更好的选择是 EJB 3.0 与 Spring。这取决于你是否喜欢 POJO 开发，是否想要选择除 ORM 和 JPA 之外的关系技术等等。

You can pay for a Java EE app server (e.g., WebLogic, WebSphere) or use an open source one (JBOSS, Glassfish and OpenEJB and ActiveMQ), or you can stick to Spring and deploy on Tomcat, Jetty, Resin or any other servlet/JSP engine.

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

Spring offers a lot of choice by being technology agnostic: persistence (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), remoting (HTTP, Hessian, Burlap, RMI, SOAP web service), etc.

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

EJB 3.0 is a spec with many vendors; Spring can only be had from Spring Source.

EJB 3.0 是一个有很多供应商的规范；Spring 只能从 Spring Source 获得。

I would recommend Spring. It's very solid, has lots of traction, isn't going anywhere. It leaves all your options open.

我会推荐春天。它非常坚固，有很大的牵引力，不会去任何地方。它让您的所有选择都保持开放。

Web services are great in theory, but there are some gotchas that you need to watch out for:

Web 服务在理论上很棒，但您需要注意一些问题：

1. Latency. Fowler's first law of distributed objects: "Don't!" An architecture consisting of lots of fine-grained distributed SOAP services will be elegant, beautiful, and slow as molasses. Think carefully before distributing.
2. Marshalling from XML to objects and back consumes CPU cycles that aren't providing any business value besides allowing your clients to speak a platform-agnostic protocol.
3. SOAP is a standard that is becoming more bloated and complex every day, but it has lots of tool support. Vendors like it because it helps drive sales of ESBs. REST is simple but not as well understood. It's not supported by tools.

1. 潜伏。福勒分布式对象第一定律：“不要！” 由大量细粒度分布式 SOAP 服务组成的体系结构将优雅、美观且缓慢。分发前请仔细考虑。
2. 从 XML 到对象再到对象的编组会消耗 CPU 周期，除了允许您的客户端使用与平台无关的协议之外，这些周期不会提供任何商业价值。
3. SOAP 是一个每天都变得越来越臃肿和复杂的标准，但它有很多工具支持。供应商喜欢它，因为它有助于推动 ESB 的销售。REST 很简单，但不是很容易理解。它不受工具支持。

Spring's web service module is very good, but do be careful about choosing to deploy this way. Write in terms of POJO service interfaces. These will allow you to get the conceptual isolation you want, defer the deployment choice until the last moment, and let you change your mind if the first thought doesn't perform well.

Spring 的 web 服务模块非常好，但是选择这种方式部署时要小心。根据 POJO 服务接口来编写。这些将允许您获得所需的概念隔离，将部署选择推迟到最后一刻，如果第一个想法表现不佳，您可以改变主意。

回答by Eric Petroelje

Between EJB and RMI, EJB would certainly be better - it has everything RMI has and much more via the container (object pooling, transaction management, etc.)

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

Between EJB and web services, web services would give you more portability if you want to be able to call them from non-java apps in the future. EJB again gives you things like transaction management and pooling that you might not get "out of the box" with web services.

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

Personally, if I were doing it, I would probably use EJB or some similar remote object framework (spring remoting comes to mind as well). If you need the ability to call the objects from a non-java app, you can always front your EJBs with simple web service proxies as needed.

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

回答by crowne

Re: web services (SOAP, REST) If your back end servers are not going to be exposed publicly, then you are not getting any benefit from using platform independent web service interfaces such as SOAP/REST.
In fact you'll be incurring a penalty with all of the overhead added by the XML tags wrapping the data across a remote call, not to mention the hit you'll take from marshalling and unmarshalling the XML to java objects.
Although any distributed call is going to require some level of serialization - even RMI/EJB, but the price is greater when serializing to human readable XML.

回复：Web 服务（SOAP、REST）如果您的后端服务器不会公开，那么您不会从使用平台独立的 Web 服务接口（例如 SOAP/REST）中获得任何好处。
事实上，您将因通过远程调用包装数据的 XML 标记增加的所有开销而受到惩罚，更不用说将 XML 编组和解组为 java 对象所带来的影响了。
尽管任何分布式调用都需要一定程度的序列化——甚至是 RMI/EJB，但在序列化为人类可读的 XML 时代价更高。

You may not need to code remote calls in java at all, you could front your service with a plain apache httpd instance, which is configured to load balance across multiple java servers using mod_jkor mod_proxy.
These modules can be used to load balance across servlet containers such as tomcat/jetty, or ejb containers such as jboss/glassfish.

您可能根本不需要在 Java 中编写远程调用代码，您可以使用一个普通的 apache httpd 实例在您的服务前面，该实例配置为使用mod_jk或mod_proxy在多个 Java 服务器之间进行负载平衡。
这些模块可用于跨 servlet 容器（例如 tomcat/jetty）或 ejb 容器（例如 jboss/glassfish）进行负载平衡。