SOA 设计的信息透视图，第 1 部分: 面向服务体系结构的信息透视图简介

SOMA（和许多其他 SOA 方法）主要依靠业务过程分析和用例设计，以适当的粒度级别解决服务接口设计、促进重用等等。通常，SOA 的信息透视图只用于实现少量的数据库查询服务，并作为 Web 服务公开。这种 “狭窄的” 视图提供的价值非常有限，完全不能与信息体系结构概念和模式可以给 SOA 解决方案带来的价值相比。为了完全支持可伸缩、一致且可重用的信息访问，SOA 解决方案需要包含更多的设计元素，以实现信息体系结构的最佳实践。

Information as a Service 应用一组结构化的技术来解决 SOA 设计在信息方面的需求。其目标是，通过了解解决方案中存在的业务信息，做出合理决策，确保以最适合支持 SOA 解决方案的技术和业务目标的方式使用信息：

服务可以跨整个企业重用。
向消费者公开的业务数据是准确、完整和及时的。
跨业务领域和技术层共享的数据具有共同的结构，对于所有参与方具有共同的含义。
将企业的各个业务领域链接在一起的核心数据实体跨所有业务线保持一致和可信。
企业能够从它的数据和数据系统获得最大的业务价值。

无论 SOA 解决方案采用什么技术和实现，这些都是它们的目标。例如，如果将现有的应用程序编程接口（API）作为服务公开，就需要了解公开的数据：它可靠且准确吗？它与企业中的其他数据是什么关系？它是否表示为消费者可以理解的格式？在 SOA 项目中，应用结构化方法进行数据分析、建模和设计就是要让解决方案的实现更好地满足现有的业务需求，以及更好地适应新的业务需求。

SOA 设计的信息透视图中讨论的大多数模式可以应用于任何服务。这些模式独立于服务的实现方式，而且不仅限于信息服务。后面一节将描述这些模式。

但是，信息体系结构概念（尤其是 IBM 的 Information on Demand 方式）也可以为一些 SOA 组件提供最好的实现选择。例如，如果需要用一个 SOA 组件实时地聚合来自不同系统的数据，并通过一个通用服务接口公开数据，那么 Data Federation 模式常常是最好的选择（参见参考资料）。本文将讨论与信息服务的实现相关的一些考虑因素。

与信息相关的一般性 SOA 设计模式

图 1 显示 SOA 设计的信息透视图所基于的三个支柱：

通过业务术语表定义数据语义
通过规范化建模定义数据的结构
分析数据质量

图 1. 概况

在本系列的后续文章中，将讨论模式对于这些方面的作用和价值。然后介绍与模式对应的 IBM 技术。

业务术语表

任何成功的 SOA 都需要建立一个通用的容易访问的业务术语表，业务术语表定义与过程、服务和数据相关的术语。在学习组织中公认的业务语言和缩写词时，常常会在术语方面发现不一致的地方。如果客户、通道、收入等关键术语的定义不一致，就不可能实现与这些术语相关的服务。如果相关人员对服务的参数（即服务获得的数据集）的含义有不同的解释，服务的实现就不可能成功。

关键在于，业务分析师和技术人员必须对 SOA 领域的所有方面（包括过程、服务和数据）使用的术语有共同的理解。业务术语表可以消除在描述核心业务概念时出现歧义的可能性，从而避免误解数据需求。

业务术语表建立一个通用的词汇表来控制词汇的定义，从而消除误解。每个词汇的定义包含描述和其他元数据，以及它在分类法中的位置。由专人负责术语的定义：他们帮助定义术语并支持对术语的管理。有关业务术语表模式的细节将在本系列的后续文章中讨论。

业务术语表的关键成功因素是，它必须容易访问，链接到其他重要的建模工件，还要能够在项目的设计阶段有效地使用。IBM Information Server 中的 WebSphere ® Business Glossary 支持这个模式。关于该产品的更详细的信息将在本系列的后续文章中讨论。

除了用来管理和共享术语表的工具之外，IBM 还以模型形式提供与行业相关的智能属性。这些模型包含数以千计的明确定义的业务术语，相关人员可以用这些词汇讨论和分析数据需求。

规范化数据模型

在设计服务时，一致的术语表是一个好的起点，但是仅有术语表还不够。还必须清楚地了解业务信息的结构。服务的输入和输出参数（即消息）常常比单一数据类型复杂得多。它们表示实体及其关系的复杂定义。如果 SOA 架构师在设计公开的服务模型数据格式时使用规范化模型，那么可以大大改进 SOA 项目的开发时间和质量。过程、服务/消息和数据模型的规范化会加快设计速度，利用数据建模的规范化方针，避免不必要的转换。同样重要的是，可以在 SOA 生命周期的早期向相关人员展现详细的服务数据模型。这有助于识别出可以跨多个业务领域重用的数据集，从而产生能够满足不同服务消费者需要的服务定义，因此可以减少重复的服务。

本文和后续文章讨论的关键问题是，如何确保信息的格式在水平方向（跨服务）和垂直方向（在 SOA 上下文中的过程、服务和数据层之间）上保持一致。对于包含 SOA 项目的相关数据的各个系统，规范化数据模型为关键实体、它们的属性和关系提供一致的定义。规范化数据模型在数据层建立这种统一的格式，而规范化消息模型在服务层定义这种统一的格式。规范化数据模型和消息模型的模式将在本系列的后续文章中讨论。

Industry Models 提供一组过程、服务和数据模型，可以使用它们进行服务体系结构的分析和设计，确保跨建模领域准确地调整数据定义。它们定义对特定行业领域进行建模的最佳实践，并提供一个可扩展的框架，这样在添加更多服务时不必重新设计 SOA。

后续文章将详细讨论相关的数据建模工具 Rational Data Architect 和模型产生的相关结构。

数据质量分析

如果考虑了上面描述的概念，设计师就可以让服务设计在模型和元数据工件之间保持高度的一致性。但是，这并不能够保证服务返回的数据质量是可接受的。数据即使满足它原来的存储库和应用程序的规则和约束，也不一定能够满足企业级的需求。例如，一个标识符在某个系统中可能是唯一的，但是在整个企业范围内不一定真的唯一。在将数据通过 SOA 向企业范围公开时，在原来的应用程序中无关紧要的质量问题可能会变成很严重的问题。例如，缺少值、冗余条目和不一致的数据格式在原来的应用程序中可能不会造成什么问题，但是在向 SOA 中的新消费者公开时就可能出现问题。

因此，问题就是：公开的数据的质量是否满足 SOA 项目的需求，以及如何有效地做出这一判断？建议的解决方案是在服务分析和设计期间进行数据质量评估。在对支持服务的源系统进行分类之后，就可以开始研究它们的数据质量问题。例如，应该检查数据是否符合相关的完整性规则。应该检查是否存在重复的数据，研究在数据匹配和聚合期间如何解决重复的数据。以这些分析为基础，可以采取适当的措施来确保服务的实现能够满足潜在服务消费者对数据精确性和含义的要求。本系列后续的一篇文章将讨论这个模式。

选择合适的工具可以大大改进数据质量评估的效率。IBM Information Server 中的 WebSphere Information Analyzer 支持数据质量分析模式，本系列的一篇文章将专门讨论这个工具。

到目前为止描述的问题和概念可以应用于 SOA 中的任何服务。无论服务是什么类型的，规范化建模和数据质量分析都有助于保证服务及其输出数据的一致性。

信息服务特有的模式

信息服务 的实现依赖于信息体系结构（即 Information on Demand），它们将信息从应用程序和过程中分离出来，从而提供业务价值。

大多数 SOA 项目并不是从头创建的，而是基于现有的 IT 环境。有一些难题是 SOA 特有的，但是人们常常把传统信息体系结构中的已知问题也归入 SOA 的范围。典型的信息环境常常不处于进行 SOA 转换的理想状态。从企业的角度来看，常常缺少一个权威性的数据源，所以无法为组织的核心数据提供一个完整且准确的视图。相反，对于不同的业务线、通道或产品类型，常常使用不同的技术以不同方式存储和处理数据。许多大型组织的核心企业信息分散在多个垂直系统上，而且存在重复的数据，每个系统根据自己的上下文维护信息，而不考虑整个企业的上下文。这进一步加重了业务过程中的不一致性 —— 业务过程本身在企业的不同部分中常常很不一致。可以利用 Information On Demand（尤其是数据、内容、信息集成、主数据和分析服务）实现信息服务，从而在正确的上下文中提供精确、一致且集成的信息。

请考虑一下缺少权威性的可信的数据源或单一记录系统，会怎么样？假设在一个组织的供应链系统中，有五个系统都在内部存储供应商信息。每个系统在各自所属的部门中都是供应商数据的有效数据源。那么，在构建服务来共享供应商数据时，应该使用哪个数据源呢？

是拥有自己的供应商数据拷贝的五个系统之一吗？如果是这样，是哪一个系统？
是否要为服务创建一个新的数据库？这个数据源与现有的数据源是什么关系？
是否必须同时从五个系统获取数据？如果是这样，那么由谁负责将数据组合和转换为消费者所需的格式？数据架构师、服务设计师、业务过程设计师还是业务分析师？

为了了解这些分散的数据定义，往往必须映射到一个参考模型（常常是逻辑数据模型），因此可能与将要确定的数据定义出现重叠、遗漏和不一致的地方。可重用的战略性的企业信息应该被看作业务实体的集合，它们应该是标准化的，可以跨整个企业重用，并符合行业标准结构、语义和服务契约。目标是要创建一组信息服务，以它们作为访问企业信息的权威的、唯一且一致的方法。如果只允许通过一个应用程序访问信息，就会把信息的范围限制在这个应用程序的上下文中，而不是 SOA 所需的企业上下文。在这种面向目标服务的环境中，组织的业务功能和数据可以作为企业资产，可以跨多个部门和业务线重用。这为信息服务提供了以下特性：

提供单一的逻辑数据源，可以通过服务接口从这个数据源获得一致且完整的信息视图。这常常称为交付可信信息。
在信息服务层下面可能存在不同的底层结构和技术，在需要时相关的复杂性会被隐藏起来（比如在运行时）。但是，在需要时也可以使用信息的 “血统” —— 逻辑业务实体到实际数据存储的映射（例如，用来支持数据管理、影响分析等等）。
在整个企业范围内，清楚地识别和有效地使用信息服务的权威性数据源。
可以使用关于信息服务的重要元数据：
- 通过服务公开的信息的质量是已知的，并能够满足业务的需要。信息服务符合已经定义的数据标准。
- 信息的当前状态（数据的 “年龄”）是已知的。可以使用有效的机制以所需的延迟交付信息。
- 信息的结构和语义是已知的，而且在不同的体系结构层（数据持久化层、应用层、服务/消息层和处理层）上以同样的方式表示。
可以根据适当的过程、策略和组织结构来管理信息服务：
- 信息的安全性能够得到保证，并且合并到解决方案中，而不是在实现解决方案之后才实现，而且符合安全性和保密性策略。
- 可以审计对服务的修改。
- 整个组织中的潜在消费者可以轻松地发现信息服务。
- 可以理服务和信息层进行整体管理。

Information as a Service 关注的问题是如何在 SOA 环境中使用（通过 Information On Demand 定义的）信息体系结构概念和功能。在 SOA 中，有一些重要的功能和概念是 Information On Demand 中没有的，反之亦然。但是，它们之间也有许多重叠的内容，比如使用内容、信息集成和主数据服务，这会显著改进 SOA 项目的交付。下图对比了 SOA 参考体系结构（左边，另外可以参阅参考资料）和 Information On Demand 参考体系结构（右边）。

图 2. SOA 中的信息服务

作为 SOA 的设计阶段的一部分，架构师需要根据项目的需求决定使用哪些模式。表 1 列出一些可以应用的关键的高层模式。

表 1. 信息服务模式的高层分类

名称问题解决方案

数据服务	如何以服务的形式公开结构化数据？	实现一个以所需的格式收集相关数据的查询，然后以服务的形式公开它。
内容服务	如何管理非结构化信息（可能是分布式的，而且有多种类型），从而让服务消费者能够有效地访问内容？	为驻留在任何地方的内容提供一个一致的服务接口，并维护内容和主数据之间的关系。
信息集成服务	如何让服务消费者能够对不同数据源中的数据进行一致的访问？	了解遗留数据及其质量，对它进行清理和转换并以服务的形式交付。
主数据服务	消费者如何访问一致、完整、上下文相关且精确的主数据（即使数据驻留在不同类型且不一致的系统中）？	建立和维护一个权威性的主数据源，将它作为企业主数据的记录系统。
分析服务	如何访问从原始的不同类型的结构化数据和非结构化数据生成的分析数据？	对结构化数据和非结构化数据进行集成、聚合和汇总，计算分析数据，比如分数、趋势和预测。

IBM Information Server 提供一个统一的元数据管理平台，它在 SOA 设计阶段扮演着重要角色。这个平台由一个存储库和一个框架组成，允许各种设计工具访问和维护它们的工件，并与其他 IBM Information Server 组件和第三方工具共享这些工件。这个共享的元数据平台的价值在于，可以在工具之间轻松地共享元数据工件，并使工件保持一致。

结束语

本文的目的是介绍 SOA 的信息透视图和一些关键的模式 —— 业务术语表、规范化模型、数据质量分析和信息服务。您应该能够看出在这些设计活动中使用行业模型的作用。如果对这些主题感兴趣，那么请务必阅读本系列的后续文章。

分享到：