SOA 探索之 ：数据服务层如何加速 SOA 实现

了解如何消除面向服务的体系架构（Service-Oriented Architecture，SOA）的复杂性。在这个有关 SOA 探索的系列的第 3 部分中，国际知名的软件工程和系统体系架构专家 Mark Davydov 深入研究了数据服务层（Data Services Layer，DSL）及其在 SOA 中的作用。他还将讨论在规划 DSL 解决方案时的重要设计问题。

概述

引入面向服务的体系架构 (SOA) 的概念是为了使工作更简单——松散耦合的接口、更紧密的管理和操作控制、封装的异构性等等。但是许多 SOA 实现正在变得比它们要取代的体系架构更加复杂。

存
在许多导致 SOA
复杂性的因素，出现在脑海中的第一个因素就是“您如何处理数据？”关系数据库是面向数据的，不是面向服务的。相反，轻量级目录访问协议
（Lightweight Directory Access Protocol，LDAP）存储库是面向服务的，仅提供了特定的查找
API。各种类型的文件又怎么样呢：XML、分隔文本、二进制等等？让所有这些分散和异构的数据源支持 SOA
不是一件小事情。除了创建服务来封装现有的企业信息系统（Enterprise Information
System，EIS）或本地数据库这个任务以外，还存在大量的挑战。

要利用 SOA 中实现最大的效益，创建一种公共数据管理方法是至关重要的，以便全面处理在企业中集成通过不同自主服务来公开的信息的工作。使用这样的方法，使积极推动简单性和 SOA 项目加速变成可能的。

为了处理这些问题，本系列的这一部分将讨论数据服务层 (DSL)。明确地说，您将考虑如何通过创建 DSL 来消除 SOA 的复杂性，并将研究要在规划 DSL 解决方案时处理的最重要设计问题。

回页首

引言

采用 SOA 是一项大型工程，要求组织在沿用多年的不同数据集成解决方案的设计和实现方式方面做出重大改变。我曾经有幸和许多组织在转换到 Web 服务和 SOA 时进行密切合作，他们的经验突出了预先规划高效和可靠的数据访问策略的重要性。

通常，IT 部门基于以下三个选项创建数据集成需求框架，如下面的图 1 所示：

应用程序通过存储过程直接访问后端数据源。
应用程序直接访问后端应用程序（通常基于 CICS®/COBOL 技术），后者又管理对不同 EIS 或数据源的访问。
应用程序连接到一个集成组件，后者处理对其控制下的特定 EIS 或数据源的数据请求。

图 1. 典型数据集成选项



由于在转向 SOA 时，通常不会将数据访问的重建视为一个基本要求，因此往往继续使用现有的框架来进行数据集成——明确地说就是上面图 1 中的选项二和选项三——具体方法是为它们提供一个 Web 服务接口作为前端，如下面的图 2 所示。

本文转自IBM Developerworks中国

请点击此处查看全文