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

Question

我原本以为在这方面有很多信息，但我没有找到真正回答我问题的任何信息。

制作EJB而不是Web服务有什么好处？我能想出的唯一明显优势是性能。即便如此，我也找不到有关EJB效率更高的任何硬数据。

通过Web服务，我可以想到很多优点，包括java / .net之间的互操作性以及通过防火墙/代理更容易联网，因为它使用http。使用更新的标准，如WS-ReliableMessaging，WS-AtomicTransactions，MTOM等（假设要对Sun和MS之间的互操作性进行全面测试），EJB提供的Web服务没有提供什么？

我从未使用过基本网络服务以外的任何其他内容，所以也许拥有更高级网络服务标准经验的人可能会告诉我，这一切都不如供应商声称的那样有效吗？

Answer 1

首先，EJB和WebServices不是唯一的替代方案，它实际上非常适合创建EJB并让它公开IIOP和Web服务接口。

所以这里有两个问题：

1. 对于可重用的业务逻辑，什么是良好的实施技术。
2. 哪种调用样式用于一个业务逻辑？像RMI / IIOP什么时候这样的考虑是个不错的选择？什么时候是SOAP / HTTP？当SOAP / JMS ......等等。

编写EJB3 EJB非常简单，并且提供诸如事务性，安全性，实例池和托管，可伸缩基础架构等优点 - 这可以为严肃的企业逻辑带来回报。 （您还可以查看其他框架，例如Spring作为替代方案。）

现在作为调用风格。显然，当需要与（例如）.NET交互时，Web服务很有用。但是，在纯Java世界中，特别是当Logic和“客户端”可以部署在同一个JVM中时，使用本地EJB接口确实比Web服务更具性能。远程调用时，RMI / IIOP和Web服务之间的性能比较并不是那么明确，在某些情况下，Web服务实际上做得很好。对我来说，使用Web服务的反驳论点是，历史上存在许多互操作问题，不同供应商之间的标准版本偏差一直是个问题 - 尽管如果你正在进行互操作，那么我猜你总会遇到这类问题。

Answer 2

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

服务实施 如果您想要一个容器提供的功能，例如事务管理，那么使用EJB来实现服务。

Answer 3

我不想讽刺，但我在EJB 3之前看到的大多数EJB实现似乎都是为了保持工作安全。这是我的轶事，因为它的价值。