java - 需要有关面向服务的架构的建议

Question

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

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

因此，在我们当前的系统中，我们创建了自定义实体来映射到繁重的 SQL 查询。 (与一张表无关)

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

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

Answer 1

这可以做到，但会很痛苦。创建 EJB 3.0 实体 bean 是有原因的。这是因为处理这些复杂的需求确实很难通过旧的 2.x 实体 bean xml 文件进行映射。

如果您确实要构建一个新的 SOA 层来表示您的数据库内容，为什么要使用已经过时近 10 年的技术来​​实现此目的？

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

老实说，我相信您最好在服务中使用 SOAP，而不是 EJB，至少它不会将您与过时的平台结合起来。目前的最佳实践更喜欢使用 REST 进行实体传输，并使用 SOAP 来进行 RPC 风格的交互，但是有很多优秀的库可用于将数据库表映射到 SOAP，其中许多库对于 RDMS 来说都是开箱即用的。

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