为什么要创建一个EJB而不是Web服务？

Question

我原以为这里有很多信息，但我还没有找到真正解决我的问题的东西。

制作EJB而不是Web服务的优点是什么？我能想到的唯一明显优势是性能。即便如此，我无法找到关于EJB效率如何的任何硬性数据。

Web服务，我能想到很多的优点，包括Java/.NET，更容易网络之间的互操作性在防火墙/代理服务器，因为它使用HTTP的。随着WS-ReliableMessaging，WS-AtomicTransactions，MTOM等新的标准（这些标准被假设完全通过Sun & MS之间的互操作性测试），EJB为Web服务提供了什么？

我从来没有比基本的网络服务以外的任何工作，所以也许有人用更先进的Web服务标准的经验可以告诉我，这一切都没有工作，以及供应商要求？

Answer 1

首先，EJB和Web服务是不是唯一的选择，它实际上是相当reaonable创建EJB，并让它暴露既IIOP和Web服务接口。

所以这里有两个问题：

1. 什么是好implmentation技术，可重复使用的一块业务逻辑的。
2. 哪种调用样式用于某个业务逻辑？诸如RMI/IIOP何时是一个很好的选择？什么时候是SOAP/HTTP？当SOAP/JMS ...等

写作EJB3的EJB是很容易的，并给出了好处，如事务性，安全性，实例池和和管理，可扩展的基础设施 - 这往往还清严重的企业逻辑。 （你也可以看看Spring等其他框架作为替代）。

现在作为调用样式。显然，当需要（如说）.NET的inter-op时，Web服务是有用的。但是，在纯Java世界中，特别是当逻辑和“客户端”可以部署在同一个JVM中时，使用本地EJB接口确实会比Web服务更高效。当远程调用RMI/IIOP和Web服务之间的性能比较并不那么明确时，在某些情况下，Web服务确实做得很好。对我来说，使用Web服务的反面论点是历史上存在很多互操作问题，不同厂商之间的标准版本偏差是一个问题 - 尽管如果你在互操作，那么我想你总会遇到这样的问题。

Answer 2

我不想讽刺，但在此之前我看到了最EJB实现到EJB 3似乎旨在确保工作安全。这是我的轶事，它是值得的。

Answer 3

服务访问 如果要支持Java服务的非Java使用者，请使用web服务。对于Java消费者来说，IIOP可能是一种选择。

服务实现 如果你想有一个容器提供的功能，如交易管理，然后使用EJB实现的服务。