我们是一个完整的SOA研讨会（仅限Java），我们使用SOAP进行数据传输。目前，我们正在集中特定组件的数据库工作，以便其他组件可以使用 SOAP 从一个应用程序获取数据。
我的论点是，集中化是件好事，但是在数据库调用之间添加肥皂时会增加很多延迟。我想要一个RMI/EJB类型的实现，以便我们得到序列化对象，并减少封送开销。我喜欢 Ejbs 的实现方式，并希望使用它。但是我们返回的数据根本不来自一个表，因此，我无法返回数据库表实体，数据可能来自其他 20 个表或更多。
因此，在我们当前的系统中，我们有自定义实体，这些实体被创建以映射到繁重的SQL查询。（不与一个表相关）
ejbs 可以用于这种类型的环境吗？如果是这样，是否有现成的库可以将查询结果映射到实体？
不幸的是，我们的内部系统非常古老，我们使用java 1.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 反序列化是否是一个重要的成本组件。 将其与网络传输的成本进行比较。 除非这些实体在兆字节范围内，否则反序列化将只占整个应用程序时间的一小部分。