我们是一个完整的 SOA 研讨会（仅限 Java），我们使用 SOAP 进行数据传输。目前，我们正在为特定组件集中数据库工作，以便其他组件可以使用 SOAP 从一个应用程序中获取数据。
我的论点是集中化很好，但是在数据库调用之间添加soap时会增加很多延迟。我想要一个 RMI/EJB 类型的实现，这样我们就可以得到序列化的对象，它可以减少编组开销。我喜欢 Ejb 的实现方式，并希望使用它。但是我们返回的数据根本不是来自一个表，所以，我不能返回一个数据库表实体，数据可能来自其他 20 个或更多的表。
因此，在我们当前的系统中，我们创建了自定义实体以映射到繁重的 sql 查询。 （与一张表无关）
ejbs 可以用于这种类型的环境吗？如果是这样，是否有现成的库可以将查询结果映射到实体？
不幸的是，我们内部的系统很旧，我们使用 java 1.4。
【问题讨论】：
标签： java architecture ejb ejb-2.x java1.4
这可以做到，但会很痛苦。创建 EJB 3.0 实体 bean 是有原因的。这是因为处理这些复杂的需求确实很难通过旧的 2.x 实体 bean xml 文件进行映射。
如果您真的要构建一个新的 SOA 层来表示您的数据库内容，为什么要使用已经过时近 10 年的技术来做这件事？
更糟糕的是，使用 EJB 2.x 构建它然后使用 RMI/EJB 会将所有其他应用程序绑定到相同的过时技术。很少有人会选择开始新 EJB 2.1 项目。
老实说，我相信您最好使用 SOAP 而不是 EJB 来提供服务，至少它不会将您耦合到一个过时的平台。当前的最佳实践更喜欢 REST 进行实体传输，并为 RPC 样式的交互保存 SOAP，但是有很多好的库可以将您的数据库表映射到 SOAP 映射，其中许多对于 RDMS 来说是开箱即用的。
最后，如果你下定决心，我建议你先做一个测试。构建一个测试框架来实际查看 SOAP 反序列化是否是一个重要的成本组件。将其与网络传输的成本进行比较。除非这些实体在兆字节范围内，否则反序列化将只占整个应用程序时间的一小部分。
【讨论】：
There was a reason EJB 3.0 entity beans were created. It's because dealing with these sorts of complex requirements 是否意味着来自多个表的列被映射到一个实体？