为什么要做EJB而不是Web服务呢？

Question

我本以为有很多关于这方面的信息，但我还没有找到任何真正回答我问题的东西。

创建EJB而不是web服务的优势是什么？我能想到的唯一明显的优势就是性能。即便如此，我也找不到任何关于EJB效率有多高的确凿数据。

对于web服务，我可以想到很多优点，包括java/.net之间的互操作性，以及更容易通过防火墙/代理进行联网，因为它使用http。对于WS-ReliableMessaging、WS-AtomicTransaction、MTOM等较新的标准(应该对Sun和MS之间的互操作性进行全面测试)，EJB提供了哪些web服务没有提供的功能？

除了基本的web服务之外，我从来没有使用过任何其他的东西，所以也许一些有更高级web服务标准经验的人可以告诉我，它并不像供应商声称的那样工作得很好？

Answer 1

首先，EJB和WebServices并不是排他性的选择，创建一个EJB并使其公开IIOP和Web Service接口实际上是非常合理的。

所以这里有两个问题：

1. 对于可重用的业务逻辑块，什么是好的实现技术。
2. 对于业务逻辑块使用哪种调用风格？注意事项，比如什么时候RMI/IIOP是一个好的选择？什么时候是SOAP/HTTP？当SOAP/JMS ...等。

编写EJB3 EJB3非常简单，并且提供了诸如事务性、安全性、实例池和管理的、可伸缩的基础设施等好处--这对于严肃的企业逻辑来说往往是值得的。(您也可以将Spring等其他框架作为替代。)

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

Answer 2

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

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

Answer 3

我不想讽刺，但我在EJB3之前看到的大多数EJB实现似乎都是为了保证作业安全而设计的。这就是我的轶事，不管它有没有价值。