需要关于面向服务架构的建议

Question

我们是一个完整的SOA研讨会（仅限Java），我们使用SOAP进行数据传输。目前，我们正在集中处理特定组件的数据库工作，以便其他组件可以使用SOAP从一个应用程序获取数据。

我的观点是集中很好，但是在数据库调用之间添加soap时会增加很多延迟。我想要一个RMI/EJB类型的实现，以便我们获得序列化对象，并减少了编组开销。我喜欢Ejbs的实施方式，并希望使用它。但是我们返回的数据根本不在一张表中，因此，我无法返回数据库表实体，数据可能来自其他20个或更多表。

因此，在我们当前的系统中，我们创建了自定义实体以映射到繁重的sql查询。 （不涉及一个表）

ejbs可以用于这种类型的环境吗？如果是这样，是否有可以随时将查询结果映射到实体的库？

不幸的是我们的内部系统很旧，我们使用java 1.4。

Answer 1

这可以完成，但这将是痛苦的。有一个原因是由EJB 3.0实体bean创建的。这是因为处理这些复杂的需求非常难以通过旧的2.x实体bean xml文件进行映射。

如果您真的在构建一个新的SOA层来表示您的数据库内容，那么为什么要使用已经过时近10年的技术来​​做到这一点？

更糟的是，使用EJB 2.x构建此应用程序，然后使用RMI/EJB将您的所有其他应用程序绑定到相同的过时技术。很少有人会选择启动新的 EJB 2.1项目。

我真的相信你最好使用SOAP来代替EJB，而不是使用SOAP，至少它不会将你与一个过时的平台耦合在一起。当前的最佳实践更喜欢REST进行实体传输，并将SOAP保存为RPC风格的交互，但是有许多优秀的库用于将数据库表用于SOAP映射，其中很多都是RDMS的开箱即用的。

最后，如果你决定这样做，我建议你先做一个测试。构建一个测试框架以真正了解SOAP反序列化是否是一个重要的成本组件。将其与网络传输的成本进行比较。除非这些实体在兆字节范围内，否则反序列化只是整个应用程序时间的一小部分。