SOA 设计中数据访问层 (DAL) 的使用答案

【问题标题】：Usage of a Data Access Layer (DAL) in a SOA designSOA 设计中数据访问层 (DAL) 的使用
【发布时间】：2011-11-02 21:08:43
【问题描述】：

由于我们正处于将应用程序恢复到 SOA 设计的初始阶段，所以我有一些问题无法得到明确的答案/图片。

我一直在阅读大量书籍，主要围绕 Thomas Erl 的书籍，并遵循理解什么是任务服务、实体服务和实用服务的设计模式。

我不明白的是整个 DAL 的外观概念。因此，这更多是对理解的验证或澄清，以帮助为我们的平台制定最佳方法。

所以背景。我们目前有几个基于 Web 的电子商务应用程序，它们几乎都是在孤岛中构建的，并且几乎是彼此的副本。我们有支持应用程序，例如守护程序和其他 Web 服务。其中许多应用程序的使用时间超过 5 年，并且仅基于技术（模型 1）。我们所有的应用程序都以进行拍卖销售为中心。因此，在销售活动期间，我们将接受用户的出价，确定谁赢了并显示该信息。每个销售活动都有一定的时间可供用户使用。

公司正在转向 SOA 解决方案，因为我们最终做的很多事情不仅可以在我们的团队之间共享，而且可以在其他团队之间共享。

所以我对 DAL 的理解是，它本身就是一项位于数据之上的服务，在这种情况下是不同的数据库 - MSSQL、ORACLE、MSSQL。这些数据库中的每一个都有不同的架构（Oracle）等。

因此服务（任务、实体、实用程序和表示层，如果需要）将调用 DAL 以检索数据。 DAL 有责任从消息的内容中知道它需要做什么才能满足请求。

例如，我们有一个安全服务候选人。此服务需要通过 LDAP 进行身份验证，并根据为给定应用程序存储的数据进行授权。

这里的想法是，将创建一个实用程序服务来包装与 LDAP 通信所需的所有操作，并且安全服务将调用实用程序服务和 DAL 以获取授权数据。 DAL 然后有责任去正确的数据库/模式来检索信息。信息将采用 XML 格式（标准 SOA 通信）。

那么，我在正确的轨道上吗？其他人有没有做过类似的事情？我还需要考虑哪些其他事情（目前正在获取关于我们在一小时内接受多少出价的统计数据 - 平均）。

每个服务是否应该有自己的 DAL - 例如，安全服务是否应该将 DAL 作为服务的一部分，或者 DAL 是否应该是所有服务都可以使用的共享服务？

【问题讨论】：

标签： java soa data-access-layer

【解决方案1】：

在您的情况下，用于基于 SOA 的完整部署的方法是使用 ESB、身份提供程序和数据服务解决方案。

为了分解它，DAL 应该使用数据服务来实现，这样，该服务将以语言中立的方式成为一个全局可访问的服务，并且支持重用和松耦合。因此，您的所有数据访问逻辑都可以作为数据服务中的 Web 服务操作来实现。

所以对于身份验证和授权管理，在 SOA 世界中，有一个标准叫做XACML，用于细粒度的授权管理。所以你需要一个 XACML 服务器，它会根据特定的标准授权用户，它还应该能够通过 LDAP 进行身份验证。

然后，您的“安全服务”将在 ESB 的服务中实现，该服务将向身份提供者查询身份验证/授权，并根据其响应，使用合适的参数调用数据服务中的适当操作获取数据，并将其返回给用户。

以上场景可以分别使用WSO2 Data Services Server、WSO2 Identity Server和WSO2 ESB来实现，都是开源产品，可以免费使用，找到here。

【讨论】：

这是一个很好的方向 - 购买（免费）与构建 - 审查产品，似乎它会让我的生活更轻松。现在只需要卖掉理想。

【解决方案2】：

我曾经参与（开发）一个使用“数据服务”的 soa 项目。那是前段时间，我只是稍微参与其中，但我的回忆是它最终变得太复杂和缓慢。

特别是我们并没有真正需要数据服务 - 将相同的抽象放在库层中会更有意义，这样可以提高效率并且不会真正损失数据功能（满足我们的特殊需求）。数据往往以许多小“块”的形式被请求，这一事实加剧了这种情况。

我想这归结为实施中涉及的权衡。在我们的案例中，使用相对封闭的系统和单一的底层数据库技术，我们可以很容易地利用数据库提供的分布式访问支持；相反，我们最终在更慢、更通用的消息总线中复制了它，除了复杂性之外什么也没增加。但我可以很容易地想象访问数据更“遥远”的不同情况。

【讨论】：

【解决方案3】：

如何在设计中使用 SOA 取决于它的要求。

通常，您可以编写粗粒度服务并将它们公开为 Web 服务。在您的情况下，您可以编写一些调用数据库并产生结果的服务。在这种情况下，授权逻辑也可以用服务逻辑编写。

另一种方法是使用 ESB 或 BPEL 引擎来编写集成逻辑并将集成服务公开为 Web 服务。在这种情况下，您可以使用一些数据服务以 xml 格式公开数据库数据并集成它们。您可以为不同的 sachem 使用服务，并使用请求数据调用正确的服务。并且授权逻辑也可以添加到服务集成逻辑中。

身份验证、机密性、完整性等安全方面被视为非功能性要求，因此无需编写显式安全服务即可用于任何服务。

以下文章描述了第二种方法中提到的此类可能的服务集成示例。

http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel

http://wso2.org/library/articles/2011/06/securing-web-service-integration

【讨论】：