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

Question

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

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

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

除了基本的 Web 服务之外，我从未使用过任何其他东西，因此也许具有更高级 Web 服务标准经验的人可以告诉我，这一切并不像供应商声称的那样有效？

Answer 1

首先，EJB 和 WebService 并不是唯一的替代方案，创建 EJB 并让它公开 IIOP 和 Web Service 接口(interface)实际上是相当合理的。

这里有两个问题:

1. 对于可重用的业务逻辑来说，什么是好的实现技术。
2. 业务逻辑应使用哪种调用方式？诸如 RMI/IIOP 什么时候是好的选择之类的考虑因素？ SOAP/HTTP 什么时候出现？当 SOAP/JMS...等时

编写 EJB3 EJB 非常简单，并且具有事务性、安全性、实例池和托管、可扩展基础设施等优势 - 这往往会给严肃的企业逻辑带来返回。 (您还可以考虑其他框架，例如 Spring 作为替代方案。)

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