我们是一个完整的SOA研讨会（仅限Java），我们使用SOAP进行数据传输。目前，我们正在集中管理特定组件的数据库工作，以便其他组件可以使用SOAP从一个应用程序获取数据。
我的论点是集中化很好，但是在数据库调用之间添加soap时会增加很多延迟。我想要一个RMI / EJB类型的实现，所以我们得到序列化对象，它减少了编组开销。我喜欢Ejbs的实现方式，并希望使用它。但是我们返回的数据根本不是来自一个表，因此，我无法返回数据库表实体，数据可能来自其他20个表或更多。
因此，在我们当前的系统中，我们创建了自定义实体，以映射到繁重的SQL查询。 （与一张桌子无关）
ejbs能用于这种环境吗？如果是这样，是否有可用于将查询结果映射到实体的库？
不幸的是我们的内部系统很老，我们使用的是java 1.4。
答案 0 :(得分：1)
这可以做到，但这将是痛苦的。创建EJB 3.0实体bean是有原因的。这是因为处理这些复杂的需求实际上很难通过旧的2.x实体bean xml文件进行映射。
如果您真的要构建一个新的SOA层来表示您的数据库内容，那么为什么要使用已经过时了近10年的技术来实现这一目标呢？
更糟糕的是，使用EJB 2.x构建它然后使用RMI / EJB会将所有其他应用程序绑定到同样过时的技术。很少有人会选择启动 new EJB 2.1项目。
老实说，我相信你最好不要使用SOAP代替EJB，至少它不会把你联系到一个过时的平台。当前的最佳实践更喜欢用于实体传输的REST，并且为RPC样式的交互保存SOAP，但是有很多好的库可以将数据库表用于SOAP映射，其中许多是RDMS的开箱即用的。
最后，如果你决定这样做，我建议你先做一个测试。构建一个测试框架，以实际查看SOAP反序列化是否是一个重要的成本组件。将其与网络传输的成本进行比较。除非这些实体在兆字节范围内，否则反序列化将只占整个应用程序时间的一小部分。