Ursula 说明了将“将信息作为服务 SOA 场景”引入 JKHLE 的好处。她指出，信息服务可以将信息使用者和信息提供者分离开来。信息服务规定面向服务的接口可以利用各种信息管理模式和技术访问信息。将信息作为服务意味着服务的定义和使用具有以下一组重要特征：

• 在检索信息时并且跨多个存储库潜在地更新信息时，提供的信息质量是已知的，信息的完整性也是有保证的。
• 信息的来源是已知的。例如，服务使用者可以通过访问元数据来确定信息的来源。
• 信息的异构是透明的。例如，服务使用者不需要知道数据源的多样性及这些数据源的不同信息格式。
• 信息的流通性是已知的，并且可达到服务质量要求期望值。
• 信息的结构和语义是已知的，通常在不同的体系结构层上表示。
• 对服务和基础信息所做的更改是以整体、统一且一致的方式管理的。

　　JKHLE 将使用“将信息作为服务 SOA 场景”中的以下实现模式：

• 生命周期建模
• 基本信息服务支持
• 数据联合
• 数据整合
• 数据清理
• 内容集成
• 主数据管理
• 管理生命周期

　　生命周期建模

　　Sandy 告诉 Ursula，JKHLE 的主要决策者一直在抱怨与 JKHLE 客户相关的服务质量太差。Sandy 概述了以下三个特定问题：

• getCustomer 服务不返回业务需要的数据。

　　由于没有对客户的特定定义达成一致意见，因此并非所有合适的客户都包括在其中。

• getCustomer 服务也会返回质量很差的数据。决策者接收到的数据通常包括重复的条目或缺失的值。这在很大程度上意味着最终得到的客户数据来自多个系统。
• 与客户相关的多项服务具有不同的消息传递格式，这给转换带来了挑战。

　　Ursula 告诉 Sandy，她知道问题所在并且重点介绍了导致这一情况的主要 IT 问题：

• 术语不明确

　　业务与 IT 之间存在不一致的术语概念。例如，在 JKHLE 中，术语“客户”在不同的部门中被赋予不同的内涵。在一些领域中，客户是指订阅帐户持有者，而在另外一些领域中，术语“客户”用于描述订阅帐户持有者以及表示对开立帐户感兴趣的潜在帐户持有者。不同类型的客户没有明确的定义导致了这些不一致性。

• 数据质量不明确

　　为实现某一服务需要集成在一起的各种信息源之间存在许多数据不一致性。Ursula 指出了帐户数据示例。帐户数据中的地址元素是以多种不一致的格式表示的。

• 模型不一致

　　消息模型(描述服务的输入和输出)在多个服务中不一致。这是消息模型与概念数据模型之间一致性方面的基本缺陷。

　　建议的解决方案

　　Ursula 建议使用“生命周期建模”实现模式来解决这些问题(请参见图 1)。

　　图 1 生命周期建模

　　Ursula 告诉 Sandy，业务术语表能够帮助解决术语不明确的问题。业务术语表定义了与流程、服务和数据相关的术语。例如，它可以提供“客户”的一般定义。业务术语表建立了一个通用词汇表，用于控制术语的定义。每个术语的定义中都包括描述和其他元数据，并对其进行了分类。指派术语管理员管理这些术语。这些术语管理员帮助定义术语并负责管理这些术语。

　　通过在服务分析和设计过程中执行数据质量评估(有时候称为数据概要分析)，可以首先解决由数据质量不明确所带来的问题。在执行了评估之后，Ursula 可以开始研究数据源的数据质量问题。Ursula 可以验证是否存在数据重复，以及这一重复问题是否能在数据匹配和聚合过程中得以解决。在进行了这些类型的分析之后，Ursula 可以采取适当的措施来确保服务实现选择满足潜在服务使用者上下文中要求的数据准确性和含义级别。

　　Ursula 建议使用规范的数据模型来解决帐户开立流程所使用的数据模型与消息模型之间的不一致性。规范的数据模型为各种系统(其用于保存与 SOA 项目相关的数据)中的关键实体、这些实体的属性和关系提供了一致的定义。规范的数据模型在数据层上建立了一种通用格式，而规范的消息模型在服务层上定义了这一统一的格式。

　　Ursula 建议 JKHLE 使用以下 IBM® 产品：

• IBM WebSphere® Business Glossary 和 IBM WebSphere Metadata Server，用于实现业务术语表以及存储业务术语表定义的底层元数据数据库。
• IBM Rational® Data Architect，用于数据建模。
• IBM WebSphere Information Analyzer，用于执行数据质量分析。
• Ursula 还建议使用 IBM Industry Models 来帮助定义数据和流程模型，如 IBM Information Framework。

　　基本信息服务支持

　　Sandy 提出了如何通过 SOA 访问 JKHLE 环境中存储在 DB2 和 IMS 中的数据这一问题。Ursula 解释说信息服务可用于 SOA 解决方案中，用法类似于任何其他服务，并且能够从流程(如帐户开立流程)或门户应用程序中进行调用。

　　Sandy 解释了她为何想要转而使用 SOA 方法。传统上，JKHLE 应用程序代码依赖于对数据存储方式和位置及这一数据访问逻辑的嵌入式详细信息的直接了解，例如，在访问应用程序时，需要知道如何利用 JDBC™ 适配器进行 SQL 调用，使用什么数据源，采用何种业务规则(如果有)进一步清理数据，等等。此方法导致应用程序与数据源和数据模型直接耦合在一起。

　　面向服务的信息访问提供了应用程序到数据源的松散耦合，从而可以获得 SOA 在实现业务灵活性方面的好处。

　　建议的解决方案

　　Ursula 一股脑地列出了多个为“将信息处理任务作为信息服务公开”选择项目的方法：

• 第一种选择是使用一个战略性平台，该平台使用单一产品公开各种访问多种不同类型数据源的信息服务。此方法提供了一些增强功能，例如，元数据管理、监视、管理、安全映射、可伸缩性和负载平衡，以及集成的开发环境(请参见图 2)。

　　图 2 基本信息服务支持

　　Ursula 建议使用 IBM Information Server 系列产品，特别是 IBM WebSphere Information Services Director，通过对所有数据(无论是结构化数据、非结构化数据、应用程序数据还是大型机数据)执行标准的验证服务，提供关键业务信息在整个企业范围内的可见性。IBM Information Server 还包含其他可选择的产品组件，这些组件可用于其他信息服务模式，如联合、整合、清理和信息概要分析。

• 第二种选择是从使用本机服务支持功能开始，无需额外的投资。本机功能往往最小，因此有一定的局限性。此外，由于存在多个堆栈，致使维护成本增加。

　　Ursula 重点介绍了 DB2 和 IMS 都提供入门级的“将存储的过程和事务作为服务公开”功能。Ursula 指出，此方法确实是为现有数据提供服务支持的低成本方法，但是，此方法未必是最适合 JKHLE 的，因为 JKHLE 寻求的是一种可伸缩性更强、允许访问多种不同类型数据源的解决方案。

• 第三种选择采用自行构建的服务从基本应用程序服务器开始。在深入分析此选择后，Ursula 认识到，此选择在开发和测试方面可能需要相当长的时间和精力，并且还缺乏标准的方法和控制。

　　Sandy 及其团队现在确信，选择使用 IBM Information Server 对 JKHLE 来说是最可行的，因为此选择可以满足 JKHLE 在管理、集成管理和集成开发环境方面的要求，从而有助于快速启动开发。它还具有以下优点：

• 作为企业信息体系结构的全面、统一的基础，可以进行扩展，以便满足任何数量和处理要求。
• 通过元数据驱动的集成来集成和丰富信息，从而提供更高的工作效率和灵活性。
• 可以最广泛和最深入地连接来自各种数据源(包含结构化、非结构化、大型机和应用程序数据)的信息。

　　数据联合

　　为了改进帐户开立流程，Sandy 指出要创建的服务可以完整而实时地查看与特定客户关联的所有帐户的状态。访问此信息的响应时间应符合小于 5 秒的标准，该标准是用于与客户服务关联的其他复杂查询的标准。

　　Ursula 与数据管理团队讨论了获取完整和当前帐户状态的问题。她指出，JKHLE 帐户信息的最大问题之一是其分散在整个组织中。此外，对各个客户、业务合作伙伴和组织而言，JKHLE 存储帐户信息的方式也不相同。

　　Sandy 不希望 JKHLE 帐户管理人员花费时间手动搜索、聚合、关联和更正帐户状态信息。

　　不过，JKHLE 当前的许多应用程序和工具都要求数据位于其所在的位置。Sandy 在寻找既能用于帐户开立流程又能用于未来项目的解决方案。

　　建议的解决方案

　　Ursula 建议，数据联合模式非常符合这些要求。Ursula 解释说，在此情况下，通过将数据复制到一个位置来集成数据并不可行。保持数据最新的需求将导致大量的复制开销，特别是在更新频率取决于 JKHLE 订单量时更是如此。因此，非常好的的解决方案是使用数据联合服务器(请参见图 3)。

　　注意：数据联合服务器负责接收定向到各种源的集成视图的查询。它将该查询转换为针对适当源的子操作，从每个源中收集结果，然后进行组装并返回集成的结果。

　　此处理顺序是同步实时执行的，有效地向查询发布者隐藏了实际操作的复杂性。

　　图 3 数据联合服务器

　　Ursula 解释了数据联合服务器如何满足 JKHLE 的需求：

• 上市时间是 Ursula 考虑的首要开发优先级之一，数据联合可以提供对信息源的快速访问，而不需要更改冗长的信息管理基础结构。
• 数据联合通过支持对位于数据源中的数据的访问，不需要复制和重复数据，因此可以满足 Ursula 的需求。
• Ursula 需要像从单一数据源那样对分布式信息(包括结构化数据和非结构化数据)进行实时访问。
• JKHLE 是一个动态变化的环境，要求使用灵活的和可扩展的信息集成方法，特别是模式发展。

　　由于数据联合减少了数据冗余，因此在联合模式中的更改减少了更改对集成系统的影响。

• Ursula 的环境特征可以用适当的请求数来描述，该请求数是根据有限结果大小从多个类似的补充数据源接收的。在此类环境中，Ursula 可以充分利用数据联合的好处。

　　Ursula 告诉 Sandy，IBM Information Server 产品系列可以满足建议的解决方案的所有需求。可以使用 IBM WebSphere Information Services Director 将信息管理功能作为服务公开。它将信息集成逻辑、清理规则和信息访问等打包为服务，将开发人员与该功能的基本提供者有效地隔离开来。其中与 JKHLE 环境最相关的是其通过面向服务的接口(如 EJB、JMS 或 Web 服务)公开联合访问的能力。该产品为信息服务提供了基础结构(包括负载平衡和故障转移)。

　　Ursula 建议使用其他两个产品。IBM WebSphere Federation Server 充当分布式平台上数据联合服务器的角色。

　　JKHLE 通过 SQL 接口可以访问来自所有现有数据源的联合信息。JKHLE 还需要访问有关大型机的一些信息，因此 Ursula 推荐了 IBM WebSphere Classic Federation Server for z/OS®。

　　数据整合

　　为改进帐户开立流程，Sandy 指定要创建的服务应提供 JKHLE 客户的统一帐户历史记录。访问此信息的响应时间应符合小于 5 秒的标准，该标准是用于与客户服务关联的其他复杂查询的标准。

　　Ursula 描述了组合统一帐户历史记录的独特问题。

　　她告诉 Sandy，由于存在许多帐户信息，因此，如果 JKHLE 尝试实时访问所有这些数据，将会影响许多其他数据库操作的响应时间。Ursula 补充说，还可能很难实时处理这些信息，并且难以满足 Sandy 的 5 秒钟的要求。

　　Sandy 回答说不需要实时检索信息。数据刷新间隔为 24 小时就可以满足要求。

　　建议的解决方案

　　通过数据整合实现模式可以很好地满足解决方案检索帐户历史信息的需求。数据联合模式对多个数据源执行实时查询，而数据整合模式可以通过在非高峰时段将数据复制到一个位置来集成数据，因此数据量的大小不会影响其他数据库操作的性能。这一数据整合过程通过数据整合服务器完成(请参阅图 4)。

　　图 4 数据整合服务器

　　Ursula 解释了数据整合服务器如何满足 JKHLE 的需求：

• Ursula 必须集成来自具有高度异构性的各种源中的数据。对于此类环境，数据整合服务器具有强大的功能，可以消除数据之间的不一致性并将其合并在一起。
• Ursula 的数据使用者要求具有高数据可用性、高度并发访问、高可伸缩性和高性能的集成信息。数据整合服务器在新的目标副本中对集成信息具体化，她的使用者可以独立于转换和集成过程而访问该副本。

　　Ursula 还可以将数据整合模式与数据清理模式合并在一起来解决整合过程中数据的质量问题。

　　为实现此解决方案模式，Ursula 推荐了 IBM WebSphere DataStage™。这是一个用于进行数据清理、转换和重新定位的高容量数据集成平台。JKHLE 将使用 WebSphere DataStage 来充当数据整合服务器的角色。WebSphere DataStage 提供并行处理功能，如支持动态重新分区、并行数据库和网格配置，使得在较短的时间范围内能够处理大量的数据。源和目标支持所有 JKHLE 源，包括关系数据库管理系统、ERP 系统、大型机现有系统、XML 和专用数据格式。

　　为了将这些信息管理功能作为服务公开，Ursula 建议使用 WebSphere Information Services Director。