关于数据访问和连通性服务的注释

    访问数据资源的数据访问服务通常被总称为企业信息系统（EIS），也叫数据库和文件系统。它们可以是遗留系统、记录系统，包装好的商业应用程序、用户、伙伴、第三方应用程序和服务，以及Web services。它们的共同之处是向其他应用程序提供数据和/或信息（在本文中的意思是行为）。因此，这些应用程序在通过数据访问层被访问时就是数据的另一种形式或另一个数据源。在一个更高的抽象层上，数据服务与消费应用程序看上去一样，这是SOA RA的数据服务层的主要目标（标准化/一致性）之一。公开的接口与一个或多个数据库、表、后台、遗留系统、快速收缩的系统和/或外部系统交互，这是数据服务层封装的一个实现细节。

    连通性服务以基于标准的方式将应用程序和数据库公开为应用程序服务。

    将数据转换成信息

    假设您的组织正计划向 SOA转换。 SOA RA的所有层和所有方面（见图1）的研究和规划已经开始，您的任务是数据服务层的实现。现在该怎么办？想想下面的几个步骤：

    1.盘点现有的数据和系统访问资源
    2.确定依赖关系矩阵
    3.建立基线度量/SLA
    4.设置资源优先级
    5.执行数据建模
    6.创建逻辑建模
    7.设置信息规则
    8.建立应用程序规范

    图2是SOA RA数据服务的一组可能的内部抽象层示例，这里将采用我们的9个步骤来映射这些需求和性能。

    图2：数据服务层——内部层抽象

    基于现在和将来的需要，您可以为一组不同的抽象层定义需求。至少，您应该分离物理层和逻辑层，并相应地分配规则类型。

    现在，让我们更具体地看一下每一个步骤。

    1）盘点现有的数据和系统访问资源

    第一步是确定数据内容，即您您当前的数据和信息系统访问资源。您您的组织拥有哪些数据和信息资源（本文后面，简称为“资源”）？例如，数据库、信息资源和应用程序（指遗留系统、记录系统）。对于每一个资源，您需要了解支撑元数据，如文档、历史、技术／工具／产品／平台、版本、所有权／管理部门、位置、安全性和访问机制。根据资源及其元数据的数量，您可能想考虑某些元数据目录或者储存库，也可能是一个或一组标准模板，能够以一致的方式获取元信息并允许进行检索。

    2）确定依赖关系矩阵

    一旦您已经开始创建资源目录，第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分，它获取关于资源的使用者、使用时间、使用频率、使用目的（例如，CRUD）和使用地点（即，访问类型——成批的、在线的、实时的或报告式的）的信息。了解用户为何使用某个特殊的资源也是很重要的，这将有助于任务优化，而且为新的数据模型提出要求。

    一旦您得到了使用某个资源的每个已知用户的情况——“使用者、使用内容、使用地点、使用时间、如何使用以及为什么使用”，您就可以开始分析和形成所有资源用户的概括。这样做的目的是要找到在现有资源向SOA构建块转换的过程中进行简化和重用的可能。它们包括，但不限于，那些面向服务的、自描述的和可发现的资源，这些资源能够便捷地应用于采用开放的、公共的、行业和／或企业标准的SOA生态系统。

    在这组SOA构建块中包含的一个定义是您的服务定义。要使用什么样的标准、规格和版本呢？例如，可能会要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一个的特定版本，而其它的则可以是可选项／推荐项。数据和信息访问资源很可能会采用与基本SOA构建块定义（即服务）一致的格式。（使用您喜欢的搜索引擎搜索“Service Identification”和“Service Definition”这两个主题可以找到这方面的内容。）