信息服务模式.doc

信息服务模式Mei Y. Selvage (), SOA 数据架构师，Enterprise Integration Solutions, EMCMei Selvage 是一名 SOA 数据架构师，在各个信息管理领域和面向服务的体系结构 (SOA) 领域拥有丰富的实践经验。她的目标是帮助跨越 SOA 与信息管理之间的鸿沟。她的研究兴趣包括信息管理和集成模式（结构化数据和非结构数据）、数据建模、元数据、面向方面的研究、人员协作和 SOA。Eoin Lane (), 高级解决方案工程师, EMCEoin Lane 博士是高级解决方案工程师，负责对主要 IBM SOA 工作的应用程序开发模式进行收集和制订，并通过 IBM 模式控制流程对这些模式进行处理，以促进其推广应用。Eoin 也是用于帮助 SOA 开发的模型驱动的开发（Model Driven Development，MDD）、基于资产的开发和可重用资产规范（Reusable Asset Specification，RAS）方面的专家。Dr. Guenter Sauter (), Senior IT Architect and Manager, IBM CorporationGuenter Sauter 博士是高级 IT 架构师兼经理，其负责的团队正在进行信息服务模式（处理信息管理和 SOA 之间的联系）方面的工作。他同时也是信息管理演示架构师，负责向客户演示完整的 IBM Information Management 产品组合的各项功能。Bill Mathews (), Senior IT Architect, IBM Corporation第 1 部分: 数据联合模式简介：数据联合模式可对来自多个异类信息源的数据进行虚拟化。该模式为分布式信息创建了集成视图，且在联合结构化和非结构化的信息时不会造成数据冗余。本文描述 SOA 上下文中的结构化信息（数据）联合。此模式规范可帮助数据和应用程序架构师明智地确定数据体系结构和文档决策指导原则。引言信息的不一致和分散让很多组织十分烦恼。在很多情况下，用户花费了大量的时间搜索并手动聚合、关联和更正相关信息，而不能直接根据从信息获得的要点采取行动。这个被广泛认识的挑战也出现在实现面向服务的体系结构（Service-Oriented Architecture，SOA）时。通常，核心服务需要使用来自多个不同源的已聚合的高质量信息。现有多个概念和技术专门用于满足这种集成需求。数据联合就是其中的一个。数据联合的目标是有效地联接来自多个异类源的数据，合理利用现有的数据不会造成数据冗余。数据联合模式支持在集成的临时（虚拟）视图上进行数据操作；在此类视图中，实际数据存储在多个不同的源上。源数据仍然在源系统的控制之下，会根据需要进行提取，以进行联合访问。本文重点强调了数据联合方法的价值。描述了应用数据联合的上下文后，我们将讨论此模式所针对的问题及其解决方案。我们根据非功能需求对此模式的适用性特点进行了说明（请参见注意事项部分）。此模式的一些已知用法源自我们应用此模式的经验。最后，我们将总结此模式的重点、风险以及限制。数据联合方法的价值主张l 基础异类系统透明性通过使用数据联合，使用者将看到的是单个统一接口。位置透明性意味着使用此模式的应用程序不需要注意数据存储的位置。得益于调用透明性，它也不需要知道源数据库所支持的语言或编程接口。例如，如果使用了 SQL，应用程序则不必知道源支持的是哪种 SQL 分支。由于具有物理数据独立性、碎片和复制透明性，因此应用程序不需要知道数据的物理存储方式；而源于其网络透明性，应用程序也不需要知道所使用的是什么网络协议。 l 上市时间优势作为数据联合服务器使用者的应用程序可以与单个虚拟数据源通过接口进行通信。如果不使用联合模式，应用程序必须通过不同的接口和不同的协议与多个源分别交互。研究表明，当必须集成多个源时，使用数据联合模式可帮助大幅度减少开发时间。有关更多信息，请参见参考资料部分。l 减少开发和维护成本很多使用者可能会使用相同（或非常相似）的集成信息。可以采用这样的方法处理此问题：每个使用者采用自己的实现来聚合来自不同源的信息。或者，可以一次性开发集成视图，然后在单个位置对其重复利用和维护，从而实现单点更改。此方法可减少开发和维护成本。l 性能优势与内部开发的信息聚合方法相比，特别关注高级数据处理技术的数据联合模式实现在很多情况下都已证明具有卓越的性能特征（有关更多信息，请参见参考资料部分）。通过利用高级查询处理功能，联合服务器可以在联合服务器本身和各个源之间最优地分布工作负载。它将确定工作负载的哪个部分由哪个服务器执行最高效，以实现响应时间最优化。l 可重用性优势将数据联合模式应用到特定集成场景后，此特定联合访问的结果可作为服务向多个服务使用者提供。例如，某个集成场景可能要求从各种源检索结构化和非结构化保险索赔数据。在此示例中，数据联合模式可以提供集成索赔数据的解决方案，以便随后将集成索赔数据通过门户提供给索赔代理人。可以随后将相同的联合访问作为服务提供给其他使用者，如标准索赔应用程序的自动流程或面向 Web 应用程序的客户机等。l 改善控制控制是 SOA 生命周期的关键基本要素。通过执行具有可预测结果的最佳实践，控制流程可通过使用模式得到增强。在系统的开发和创建过程中重用经过验证的灵活模式可同时确保一致性和高质量，并同时通过使用单个源来更新更改，从而减少维护成本。上下文公司和组织间的合并和收购通常要求数据和应用程序架构师将异类数据源集成到数据的统一视图中。此类集成信息的使用者是直接与数据库交互的传统应用程序，需要能够访问经过扩展的数据源集。有关如何最好地提供此统一视图的决策通常是根据组织中的工具可用性、经验、专业知识以及企业文化做出的。使用传统遗留体系结构时，与集成关联的时间、工作量以及成本可能会超过所带来的业务好处。在基于服务的环境中实现了基于模式的信息服务方法后，可以增强系统长期的可重用性特征。信息服务是 SOA 的核心中枢的一部分。这些信息服务提供了对域信息的创建、读取、更新和删除 (CRUD) 访问。它们还可提供各种信息处理功能，如通过分析和评分算法、数据清理规则等进行处理。对于本文，我们将重点讨论可提供统一数据视图的信息集成服务，而这通常会涉及到对各种异类后端源和服务进行集成。应用数据联合模式时，我们需要对两个上下文进行区分：传统的非 SOA 上下文（由很多以前的应用程序加以处理）和 SOA 上下文（本文的重点）。务必记住，SOA 是一种体系结构方法，可通过其得到可重用服务，能在很多情况下扩展现有非 SOA 实现的功能。 传统上下文在我们称为传统上下文的环境中，银行的报表应用程序可能需要分析信用卡事务。考虑到此数据的量（每天数百万事务），将所有这些信息存储在分析数据仓库中并不是有效的办法。会频繁访问很多旧数据，将其作为特定的上下文信息，如旅行路线等。将所有信用卡事务数据当前的和过期的、核心的和相关的存储在数据仓库中会对性能造成负面影响。一种更好的解决方案是将两种类型的数据加以分离：例如，可将常用、最近使用的信息库事务存储在数据仓库中，而将旧信息存储在磁带上。不过，报表应用程序应该不需要知道这种可通过联合方法提供的数据分布。图 1. 传统数据联合模式在此传统上下文中，应用程序通常使用标准关系接口和协议来与联合服务器（如 SQL 和 JDBC/ODBC）交互。联合服务器将随后通过各种适配器或包装连接到各种数据源，如关系数据库、XML 文档、已打包的应用程序和内容管理及协作系统。联合服务器是一个虚拟数据库，具有关系数据库的所有功能。请求应用程序或用户可以在其访问权限内执行任何查询请求。查询完成后，将返回一个结果集，其中包含满足选择条件的所有记录。此过程如图 1 中所示。此图旨在演示可以基于使用 SQL (JDBC/ODBC) 或 XQuery 的关系应用程序编程接口的传统实现。 SOA 上下文在 SOA 上下文中，服务 getCustomerCreditCardData 可能需要检索有关客户及其信用卡事务的全面信息。此信息可能并不是驻留在单个系统中。客户信息可能存储在客户主数据管理系统或多个存储库中，而信用卡事务则可能存储在另一个数据源中。数据联合将对来自多个源的信息进行联接，以便能作为服务向使用者提供。在此 SOA 上下文中，联合服务器充当使用 SOA 一致接口的服务提供者和/或服务使用者。请注意，这并不排除服务器还会提供对传统关系接口的支持。支持的深度是一项实现决策，这超出了本文所讨论的范围。当数据联合服务器将集成信息作为服务提供者公开时，服务使用者可以通过服务接口（如 WSDL 和 HTTP/SOAP 或其他事前确定的绑定）来访问此集成信息。数据联合服务器可以使用（为了集成）多个信息源提供的服务。 在 SOA 上下文中使用数据集成模式的基本想法是利用和重用集成信息，即，信息集成服务能以可扩展的方式供各种使用者使用。服务的建模和定义是 SOA 的关键方面。一个受到广泛认可的最佳实践是，将服务设计为能提供信息或功能的重用和/或跨企业互操作性和/或业务流程支持。很多（如果不是大多数）成功的 SOA 项目都将重点放在作为服务公开的最重要、最广泛使用的业务功能上。由于这些服务扮演着关键的角色，因此经常会涉及多个后端系统。因此，从多个异类源收集信息是 SOA 依赖的一项重要需求和功能。服务并不是传统数据访问上下文中的查询，而是对业务实体的请求，可以由联合服务通过一系列查询和其他服务加以满足。图 2. SOA 上下文中的数据联合模式在 SOA 内启用信息集成服务需要使用额外功能，以在面向服务的接口中封装联合访问。这是通过 Information Service Enablement 实现的。此组件用于在面向服务的接口中提供一些联合查询。例如，可以使用 SQL 编写联合查询，并可以指定对产品信息的访问。通过 Information Service Enablement 组件，此联合查询可以作为使用特定机制（如 SCA 或 WSDL）定义的服务提供。实现对产品数据的访问的服务可以随后在整个企业内和企业外进行共享。在传统上下文中应用数据联合模式的解决方案可以利用 SQL 的声明性和灵活性特征。通过使用恰当的安全凭据，使用者可以访问源中的任何数据，而此过程可能涉及的不同 SQL 查询的数目几乎没有限制。使用者在访问的内容及结果返回的格式方面具有极大的灵活性。尽管在很多情况下，这个灵活性是一个很大的优势，但也增加了使用者所面临的复杂性。使用者必须了解源数据模型以及如何从这个基础源数据模型构造结果。源数据模型越大，此任务就会变得越复杂。 SOA 方法的重点是首先将数量相对有限的最关键业务功能定义为服务，并在整个企业内和企业外进行共享。因此，面向服务的接口更多的是关注数量有限的需向外提供的特定信息请求。这个清楚而集中的重点可为开发人员带来好处，因为这样可以减少他们设计信息请求的时间。他们可以直接从数量相对有限的选项中选择恰当的服务。问题说明在当今业务驱动的环境中，架构师和开发人员要实现数据联合解决方案的情况非常普遍。他们所面临的挑战通常受到一系列体系结构决策的影响，而后者实际上又受到技术、业务或合同方面约束的影响。此场景中包含多个此类常见约束。首先，支持项目的信息访问要求所必需的数据驻留在多个源中，必须对其进行集成，并作为单个结果向用户提供。其次，无法对目标数据源进行复制来满足访问需求。最后，解决方案必须在现有 SOA 内集成，并仍然支持传统的非 SOA 应用程序，如图 3 中所示。 图 3. 异类接口访问解决方案目标正如问题说明中所述，此方法的目标是避免提供异类源的集成视图时出现数据冗余。数据联合服务器即实现数据联合模式的组件必须针对传统非 SOA 上下文提供标准查询接口。这可确保各种各样的传统数据库应用程序能够使用联合数据。联合服务器还必须提供查询优化功能，以最高效地响应请求。此上下文中数据的分发和异类性特征决定了必须重点强调如何最好地转换对集成视图的访问，以及如何分解和分布工作负载。支持对此集成视图的写访问时，联合服务器必须将各个源中的数据操作同步到逻辑工作单元中。这可确保满足事务的原子性、一致性、隔离和持久性 (ACID) 标准，且保证引用完整性。除了针对传统上下文的这些目标外，此方法还必须适合在 SOA 中使用。这将允许企业内外的各个用户能够有效地重用集成视图。SOA 中的联合访问的潜在使用者是需要访问分布式信息的应用程序、门户和业务流程中的活动。例如，制造商可能定义从异类源检索实时库存信息的服务。内部应用程序和外包业务合作伙伴可以访问相同的服务，从而利用此联合访问的一致且最高效的实现。解决方案描述在传统上下文和 SOA 上下文中，数据联合服务器提供了有效联接和处理来自异类源的信息的解决方案。此模式实现了处理分布式数据的同步实时集成方法。数据联合服务器负责接收定向到各种源的集成视图的查询。它会使用复杂的优化算法对其进行转换，从而将查询拆分为一系列子操作（称为查询划分与重写），然后对相应的源应用子操作，从每个源收集结果，组装集成结果，并最后将集成结果返回到原始查询。此处理序列将以同步的方式实时完成。设计时特征数据联合模式要求对集成视图范围内来自各个数据源的数据元素进行映射。例如，上面示例中提到的保单持有人姓名和地址等客户信息可以存储在一个数据库内的单个表中，也可以存储在另一个数据库内的多个表中。为了构建集成视图，需要将这些不同类型的表示形式映射到公共视图中。映射可以由相关人员手动执行，也可以采用基于各种映射算法（还会捕获任何必要的转换需求）的最新工具辅助完成。这就允许数据联合服务器接收对集成视图的查询和计算要执行的最优子操作数量和类型。 在 SOA 上下文中应用数据联合模式时，需要在 SOA 内将一组联合查询作为服务启用并注册。例如，用于检索保单持有人的关键结构化和非结构化信息（如姓名、地址、状态、索赔文档、维修费用预估和风险评级等）的集成视图可以作为服务启用，并在多个用户间共享。设计时的映射结果通常为联合视图，与关系数据库视图类似，可以随后在联合服务器上进行部署或创建。运行时数据联合服务器接收对集成视图的请求。根据映射定义，联合服务器将联合查询拆分为多个子操作。多个因素会对此步骤造成影响： 响应联合查询所必需的数据驻留在何处？ 为了将异类源表示形式（如不同的数据类型、规范化模型与非规范化模型）转换为公共集成视图，必须执行哪些操作？联合服务器使用映射信息来解决这些问题。还有很多其他因素会影响联合查询处理，这将要求使用映射规范之外的其他信息，如： 系统管理数据源支持哪些操作，哪些操作必须由联合服务器提供补偿机制？ 在源中执行一系列操作与在联合服务器上执行这些操作的性能影响如何？联合服务器应将哪些操作委派给源，以便更好地利用源的功能、减少数据传输以及优化总体性能？回答这些问题需要使用源系统及其查询处理功能方面的知识。为了处理后一个问题，联合服务器还必须使用一系列关于操作环境的信息以及源数据的统计数据。 联合服务器确定了所有子操作的最佳执行策略后，将连接到数据源包括结构化和非结构化信息的数据源以检索相关数据（可能会使用源特定的接口）。根据总体查询执行计划，将随后对数据源执行各个子操作。将接收结果并聚合为集成视图的结果。然后会将此结果返回给使用者。在 SOA 上下文中，使用者通过预定义的请求格式向联合服务器提交请求。联合服务器将请求转换为对应的 SQL 查询或视图定义，以支持服务。从此时开始，将执行与以上所述相同的查询分解、优化和执行步骤。SOA 中唯一的区别在于最后一步。联合服务器会将传统数据联合方法的结果转换为服务响应，并随后通过预定义的服务接口将其返回给服务使用者。图 4. 数据联合的序列图数据联合模式的功能可以通过使用数据相关的技术（如优化器或补偿）或自己开发的应用程序来实现。由于异类源上的查询优化的复杂性，行业最佳实践是使用数据联合实现来利用大多数数据库管理系统提供的查询优化技术。注意事项应用数据联合模式时，务必理解其特征以及其受以下所述的非功能要求的影响情况。一定要注意，我们列出的功能要求并不考虑缓存和数据复制模式。我们认为，当采用以基本模式（本例中为数据联合）为基础模式时，可以随后通过其他模式对其进行扩展，以便满足服务的额外非功能要求和功能要求。可以使用缓存和数据复制模式来补充数据联合或形成组合模式。应小心使用这些模式以及可以在总体实现中使用的其他模式，因为它们可能会妨碍最初选择数据联合来解决的一些非功能要求的实现。例如，它们可能会增加数据延迟和导致数据冗余。需要了解非功能要求和体系结构决策之间的得失。非功能要求的所有特征既适用于传统的非 SOA 上下文，也适用于 SOA 上下文。其包括：l 数据安全性只有具有所集成源中的恰当凭据的用户和应用程序才允许访问集成视图。可以对此进行进一步的限制。应用此模式的一个主要原因是要利用现有源系统的数据和功能。因此，架构师经常还希望利用现有的安全机制，如源系统的身份验证和授权。由于此环境具有异构和分布式的特点，可能会出现数据联合模式外的有关单点登录和全局访问控制的挑战。为了应对这些挑战，架构师将需要把数据联合模式与其他安全相关的模式结合使用。l 数据延迟数据联合模式允许以实时集成的方式访问源，具有最高的数据并发级别。l 源数据易变性由于能在接收到集成视图请求时实时地访问源数据，因此数据联合将始终返回最新的源信息。由于数据联合模式并不会创建源数据的副本，因此源更改并不一定要采用这种方法进行传播或处理。l 数据一致性和质量由于需要执行的复杂数据清理、标准化和转换操作的频率增加，因此对总体响应时间造成负面影响的概率也会增加。这是由于数据联合模式中的请求对应的响应的实时同步特征造成的。任何额外的转换都将意味着响应集成查询时会存在额外的工作负载。最好的做法是尽可能减少所需的字段转换的复杂性和数量。l 数据可用性集成数据的可用性依赖于数据联合服务器和集成源服务器在请求时的可用性。如果某个服务器或联合与源服务器间的任何连接失败，集成视图就不可用。 l 模型更改对集成模型的影响数据联合模式的一个非常重要的好处是，能够屏蔽在源系统中实现的很多模型更改。如果能够将更改限制在联合服务器中，就可以减少将这些更改向服务的发起方或使用者公开的可能性。此外，还能够在无需将更改传播给数据源模型的情况下在集成视图中进行更改。 l 事务执行的频率对联合服务器的请求是采用同步方式执行的。只要接收到响应，请求者就可以调用后续请求了。联合服务器应支持由多个请求者发起的并发请求。频繁的后续请求应该与单个请求具有相同的性能特征。如果源或联合服务器和源之间的连接器具有特定特征，在访问频繁时会导致响应性能下降，则可能会出现异常。联合服务器高速执行事务的能力是由联合服务器访问源系统的速度以及这些源系统响应的能力决定的。l 事务并发性在很多情况下，数据联合服务器都具有与数据库或内容服务器很类似的特征。有效管理并发访问的能力由数据联合服务器和所集成的源服务器的性能特征决定。 l 性能和事务响应时间事务响应时间由很多因素决定，包括： 联合查询的复杂性：为了执行查询，联合服务器需要执行多少筛选、联接、排序之类的子操作 数据联合服务器的查询优化和处理功能：联合服务器的设计用于处理以下方面的成熟程度接收联合查询，将其拆分为子操作并进行优化（例如，首先应用筛选器等一些子操作来减少数据集大小，然后执行排序等子操作） 数据量：数据量越高，每个子操作执行的时间越长，因此查询的完成时间也就越长 网络带宽：联合服务器和源之间的网络连接的吞吐量将影响联合服务器访问源的速度，因此也会影响联合查询的总体响应时间 CPU 使用率：联合服务器和数据源所在的计算机上的资源使用率的差异需要影响总体联合查询的哪些子操作在联合服务器上执行、哪些在源上执行（如果可能） 源服务器的查询处理能力：有些源服务器在其处理和优化影响总体性能的查询方面具有特定的特征和限制 联合服务器标识每个数据源的最后查询策略的能力：如果联合服务器能了解源服务器的查询处理能力，则可以确定可委派何种类型的子操作以及何种子操作要在联合服务器层执行数据联合模式（从分布源获取数据）实现的虚拟数据库的查询响应时间可能比在具有相同功能的单个物理数据库上执行相同的查询长。响应时间的差异将根据上面列出的各个元素的不同而有所变化。因此，在单个物理数据库中提供集成数据集的替代模式的响应时间会有所改善。数据联合模式的有些实现可以将部分或全部子操作（子查询）以并行方式发送到集成源系统。子操作的并行处理能够大幅度改进响应时间。 l 创建、读取、更新、删除 (CRUD) 概要大部分联合实现都支持不同程度的读写访问。有些实现会对写入操作的逻辑工作单元进行协调，这被称为两阶段提交。在大多数情况下，由于写访问非常复杂，因此数据联合模式主要用于进行读访问。如果没有两阶段提交支持，请求者需在更新数据时负责确保源中的一致性。由于两阶段提交通常要求使用事务管理器，写访问的支持程度可能会根据事务管理器实现的不同以及源服务器在应用和提交更改方面的功能的差异而有所不同。l 每个事务的数据量响应时间受到每个事务需要从远程源传输到联合服务器的数据量的影响：数据量越大，响应时间越长。优化联合查询对联合服务器非常重要，能尽可能减少必须在联合服务器和源之间传输的数据量，特别在联合数据量很大时更要如此。另外，务必还要了解网络基础设施所支持的功能和带宽以及可能对所传输的数据的数量和频率的影响。 l 解决方案交付时间正如价值主张中提到的，数据联合可以大幅度改进集成各种源时的交付时间。 l 技能和经验数据联合模式的重点是数据源的集成和通过面向数据的接口提供单个系统映像。当将集成信息作为服务提供时，开发人员还将需要理解各个 SOA 概念、标准和技术。l 可重用性有关定义数据访问和聚合的逻辑可以在不同的项目中加以重用。 l 维护多个数据源的成本数据联合并不会减少维护多个数据源的成本，但由于对现有数据源进行了集成和重用，可以获得更大的好处。l 开发成本假定已经配备了联合服务器基础设施，则使用最好的联合引擎会相对较为廉价。l 目标模型的类型本文的重点是结构化数据的联合。目前，最常见的模型是采用 SQL 标准的关系模型。XML 和 XQuery 则是两项新兴标准，正越来越多地在信息管理中采用。数据联合模式的实现通常至少支持其中一种模型，有时候会同时支持这两类模型。数据联合模式的大部分实现都比较强调一个（或数量很有限的）目标模型，以最有效地处理请求。 l 有保证的交付和逻辑工作单元在 IBM SOA 参考体系结构中，企业服务总线（Enterprise Service Bus，ESB）是基础设施中的一个关键组件。ESB 的责任之一是提供有保证的交付。由于协调逻辑工作单元（如在联合环境中通过两阶段提交协议进行协调）的复杂性，并非数据联合模式的所有实现都支持此功能。当使用支持此功能的联合服务器时，需要对其数据库锁定策略进行仔细分析，以避免对源系统的性能造成负面影响。l 资源使用率联合服务器仅在处理从使用者接收到的请求时才会使用资源。联合服务器的资源使用率水平是由请求的复杂性决定的：请求越复杂，查找将此联合请求分解为子操作的最优计划的任务就越复杂。资源使用率的另一个影响因素是需要在联合服务器上执行的子操作（如补偿源系统所缺少的功能）与可以下推到源系统的子操作的百分率比值。另外，从源系统接收到的数据量和需要通过联合服务器的数据量也影响资源使用率。l 转换功能联合模式的重点是让数据保持在原来的位置，并提供实时的虚拟集成视图。此模式中的解决方案对可以应用何种转换并没有限制。可以在很多实现中使用基本转换来将异类源格式转换为联合层的公共视图。不过，复杂转换对联合模式的性能有负面影响，从而会降低此模式对此类场景的适用性。因此，大部分数据联合模式的实现对复杂转换功能的关注相对较少，而更强调查询优化技术。l 源模型、接口、协议的类型数据联合处理有关集成来自异类源模型的数据的问题，包括将这些不同的源模型映射到联合层的公共模型的概念。数据联合模式的实现在其可以集成的具体源模型的能力方面各有不同。l 源模型的范围和大小当在运行时期间将基础源映射到集成视图时，源模型的大小、属性的数量和类型可能对映射任务造成负面影响。范围越大（例如要访问的属性数量越多），标识对应元素的时间可能越长。 l 联合服务器工作负载（事务量）对源系统的影响联合服务器会将其接收到的每个请求的子操作转发到源系统。这将对源系统的资源使用率造成负面影响，因为需要对来自联合服务器的子操作做出响应。联合服务器接收到的请求越多，发送到所集成的源系统的子操作越多。结束语我们在本文中对数据联合模式进行了说明，此模式是一种处理对集成临时（虚拟）视图的数据操作的方法，而此类视图中的实际数据都存储在多个不同源系统中。我们在本文中主要讨论的是 SOA 上下文中的情况。我们最后将总结何时应用数据联合模式及何时不应用此模式，并将列出重要的约束。应用数据联合模式的重点领域 上市时间是具有顶级优先级的开发目标之一，数据联合可快速提供对信息源的访问，而不需要进行长时间的信息管理基础设施变更。 数据联合通过允许按照数据驻留在源上的方式访问数据，从而支持与数据复制和重复相关的要求。这些要求可能是为了响应法律法规或规则对数据移动或复制的限制，如订阅数据或来自不同国家的个人信息混合存在的情况。 像访问单个源的数据一样实时访问分布式信息。信息可以为结构化和非结构化数据。 用于动态更改环境（特别是模式更改的情况）的灵活的可扩展信息集成方法：由于没有数据冗余，联合模式中的更改会减少更改对所集成系统的影响。 当接收到的请求数量适中，而来自多个异类互补数据源的结果大小有限时，可最佳地利用数据联合的优势。不应该应用数据联合模式的领域 需要复杂转换来构建集成视图的场景将对响应时间造成负面影响，尤其是采用这种方法时。 源服务器可能在必须返回联合查询中请求的数据时受到工作负载增加的负面影响。为了将请求处理到集成视图中，联合服务器将向所集成的源发送子操作。这些子操作越复杂，其发送到源系统的频率越高，源服务器需要管理的额外工作负载也就越多。 导致大量过渡结果集从目标数据源移到联合服务器的情况可能带来很大的性能影响。 应用程序要求相对较高的集成数据可用性的情况可能不适合应用这种模式。集成数据的可用性完全依赖于过程中涉及的所有联合服务器和源服务器的可用性以及网络的可用性、容量和响应能力。 应用数据联合模式时的约束 数据联合的很多实现具有受限的数据操作功能。很多将 SQL 作为编程语言使用，且仅支持 SQL 转换。 性能很大程度上依赖于供应商特定的实现在缓存功能、理解异类数据源和确定最佳联合查询和执行路径方面所表现出来的成熟度。 不同信息源的读写访问（特别在对逻辑工作单元进行协调时）将受到供应商特定的支持的约束。产品映射以下 IBM 产品实现了此模式： IBM WebSphere Information Integrator Standard Edition、Advanced Edition、Advanced Edition Unlimited 允许应用程序对来自分布式平台上 (LINUX / UNIX / WINDOWS) 的源的数据进行联合。用户可以通过 SQL 接口访问来自各种数据源的联合信息，如 Informix、Cloudscape、Oracle、SQL Server、Microsoft Excel、XML 文件等。此产品还可以与以下两个产品组合使用，以聚合结构化、非结构化数据以及来自大型机平台的宝贵资产。 WebSphere Information Integrator Classic Federation 提供了一个 SQL 接口，可在大型机上的各种数据源上使用，如 DB2、IMS、VSAM、IDMS、Adabas 等。此产品的主要功能之一是在无需编码的情况下将大型机数据结构映射到关系模型，以便具有非常有限大型机知识的开发人员可以灵活而高效地访问大型机数据。 WebSphere Information Services Director 可将信息管理功能作为服务提供。它可将信息集成逻辑、清理规则、信息访问等打包为服务。这样就使得开发人员无需费神考虑此功能的基础提供者了。其中与本文最为相关的就是将通过面向服务的接口（如 EJB、JMS 或 Web 服务）提供联合访问的功能。此产品为 Information Services 提供了基本的基础设施，包括负载平衡和容错功能。它实现了图 2 中所示的 Information Service Enablement 组件。 WebSphere Information Integrator Content Edition 提供了联合内容管理系统上的统一接口。提供了各种内容源上的典型内容访问操作，其中包括 IBM DB2 Content Manager。第 2 部分: 数据整合模式简介：数据整合模式规范帮助数据和应用程序架构师基于可靠信息做出有关架构方面的决策，并改进决策指导原则。在本文中，您将了解如何在 SOA 上下文中应用这种模式。数据整合模式（也称为数据填充模式）的主要业务驱动因素是在需要使用信息之前，首先收集和协调来自多个数据源的数据。为了完成这项任务，它从一个或多个数据源提取数据，将该数据转换为所需的目标格式，然后将其加载到持久数据目标中。持久目标的预填充是这种模式和本系列第 1 部分中介绍的数据联合模式之间的主要区别。引言业务增长迫使公司必须提高其自身的 IT 能力，以满足变化的业务需求。引入一些新的应用程序以支持这种新型的需求。以新的方式对现有的信息进行处理和分析，以便更好地把握关键性的业务挑战。有些公司并购了其他的公司，进一步地加速了它们在新的领域中的增长。遗憾的是，信息/数据方面却不能始终以一种受到严格控制和有组织的方式发展，以支持这种增长。因此出现了冗余和不一致的信息孤岛。为了能够在特定的领域中实现最高的效率，对于相同的数据，不同的应用程序以不同的方式进行表示。许多公司正采用面向服务的体系结构 (SOA) 来处理各种各样的问题，如减少系统集成的成本、优化现有信息的重用和功能。采用和实现 SOA 的关键步骤之一是标识最关键的业务功能（服务）及其设计。常见的做法是，重点关注那些由企业之间和企业外部的许多使用者使用的服务。这种服务最有可能需要来自许多不同系统中的数据，而这些系统包含着各自所需的那部分信息。例如，大多数公司不会只将客户信息存储在某一个地方。如果不清楚应该从何处获取相应的信息，以及哪个系统中保存着最新的并且最精确的信息，那么这就会成为一个很大的问题。如果不清楚这些问题的答案，就不可能实现返回一致的用户相关信息的服务。本文描述了使用数据整合模式作为集成来自不同数据源的信息的一种方式。首先从各种数据源收集相关的信息。然后对数据进行处理，以消除冲突并创建表示目标模型的公共结构。最后，将经过转换的信息应用于目标数据存储。数据整合模式的价值主张l 底层异构的透明性使用者只看到单个统一的接口。使用该模式的应用程序无需了解下面的内容： 原始源数据存储在何处（位置透明性） 源数据库支持什么样的语言和编程接口，例如，是否使用了 XQuery 或 SQL，或者数据源支持何种 SQL 方言（调用透明性） 如何对数据进行物理存储（物理数据独立、分片和复制透明性） 使用了什么网络协议（网络透明性）l 性能和可伸缩性 预填充数据整合模式将数据集成任务从数据访问任务中分离出来。访问目标数据库不需要执行数据整合过程。通常，整合过程可以按天、周等时间计划执行，与使用者访问目标数据无关。因为已经将所需的数据收集到了统一的位置，所以可以为数据使用者确保最高的性能和可伸缩性。l 单个版本的真实数据当对来自异构数据源的数据进行集成时，这种方法应用强大的功能来解决其中的冲突。然后，相关的服务可以从这个整合的数据存储库中提取数据，并满足高数据质量需求。l 可重用性在将数据整合模式应用到特定集成场景后，可以将整合过程的结果作为服务提供给多个服务使用者。例如，在某个场景中可能需要集成来自多个区域的财务信息。在应用了数据整合模式之后，可以将不同的数据整合到单个位置，然后通过财务仪表板对其进行公开。然后，信息服务可以利用相同的整合数据为其他使用者提供服务，如为标准申报应用程序或面向客户的 Web 应用程序实现自动化的过程。l 改进的管理在 SOA 生命周期中，管理是一个关键的基础。通过对常见的做法加以强化以确保其具有可预测的结果，模式可以用来提高管理过程。在系统的开发和创建过程中，重用经过证明具有相当灵活性的模式，可以确保一致性和高质量，并且减少维护成本（因为只需要对一个数据源进行更新）。上下文这种模式部署到各种传统的和非 SOA 上下文的场景中已有相当长的时间了。由于人们对 SOA 的兴趣越来越浓，现在我们可以看到将这种模式应用到 SOA 上下文中的情况。传统的、非 SOA 上下文应用数据整合模式的传统的、最典型场景包括： 应用程序迁移：应用程序迁移发生在现有的遗留系统中，例如由于业务或技术原因，需要使用新的应用程序来替换自己创建的客户关系管理 (CRM) 系统。数据整合为应用程序迁移过程提供了支持，以便将数据从遗留环境中移动到未来应用程序的数据库中，并对模型和数据本身进行任何所需的调整。 应用程序整合：整合应用程序的任务之一是整合基础的数据库，例如，将各种企业资源规划 (ERP) 系统的数目减少到一个或非常有限的数目。这意味着将来自各种现有遗留系统的数据合并到一个或多个整合数据库中。 决策支持：许多决策支持场景，如那些处理财务分析和报告的场景，需要访问分布于各种数据源中的数据。决策的质量取决于基础信息的质量和全面性。因此，需要对分布式的数据进行集成，并使其可以用于进行各种各样的分析。在许多情况下，可以通过历史（副本）快照来分析某个时间段内的发展趋势。数据整合为公司提供了来自于各种数据源的单个版本的真实数据。数据仓库可以用来支持决策制定，这是数据整合模式应用的一种典型的示例。 主数据管理：主数据管理的目标是使得主信息从不同的应用程序中分离出来，其中主信息定义为描述核心业务实体（如客户和产品）的事实。这种主数据、或单个版本的真实数据的创建，可以通过一组规则、技术和解决方案来实现，它们可以用来为所有的信息保管者创建和维护一致的、完整的、上下文相关的和精确的业务数据。主数据可能位于许多隔离的系统中，以不同的格式进行存储和维护，从而导致高度的不一致性和不完全性，这是主数据管理的驱动因素。为了生成精确的和一致的信息集（可以在中央主数据管理系统中对其进行管理），需要对数据进行收集、将其转换为主数据模型、并整合到主数据存储库中。所有这些场景都具有下列共同点： 源信息分布于多个异构的和自治的系统 源信息可能存在不一致或不完整的格式 对源数据应用了不一致的规则 更改信息源和格式的灵活性受到相当的限制必须将源数据整合到单个持久的目标，以便通过将这些数据集成为公共的和一致的格式来解决这些问题。数据整合模式的核心功能通过下面三项活动来处理这种需求：收集（从数据源提取数据），处理（对源数据进行转换，以匹配定义目标的模型），应用（将经过整合和协调处理的数据加载到目标数据存储或系统）。图 1 中阐释了整个过程。 图 1. 传统的数据整合模式SOA 上下文SOA 上下文出现了许多与传统上下文类似的问题，所以我们相信，重用这些经过证实的、现有的方法并对其进行增强以应用于 SOA，这是非常重要的。第一个 SOA 用例： 整合数据访问第一个 SOA 用例是前面在传统上下文中描述的场景的扩展。在这个用例中，将目标数据的整合过程公开为一项服务。例如，对于汽车制造商，主数据管理解决方案可能集中于零件信息或车辆信息。因为零件/车辆信息非常重要，所以许多使用者都需要从整合的主数据管理系统中访问这类信息。服务，如 getVehicleData，可以为实现可重用服务的整合模式的实例化。然后，可以在企业之间和企业外部访问这个服务，例如由雇员和外部零件销售商来访问。通过服务对这类信息进行公开，可以增加对该实现进行重用的可能性；当多个使用者（目标系统的实现者）需要单独地和重复地执行集成任务时，往往会引入对源格式的派生、转换和变形，而这种方法可以减少与此相关的开销和不一致性。在 SOA 方法中，企业服务总线 (ESB) 可以对各种使用者和信息服务提供者之间的消息（服务请求和响应）进行代理，如 图 2 所示，从而实现服务的一致的和标准的调用。图 2. SOA 对整合数据的访问在 SOA 中启用信息集成服务，需要有附加的功能将信息访问封装到面向服务的接口中。这可以通过信息服务支持 来实现。这种组件的任务是在面向服务的接口中公开经过整合的数据。例如，可以将经过整合的车辆数据存储于关系数据库中。通过信息服务支持组件，可以将这种关系型的车辆数据公开为服务，例如，使用服务组件体系结构 (SCA) 或 Web 服务描述语言 (WSDL) 进行定义。然后，可以在企业之间和企业外部访问这个实现了车辆数据访问的服务。第二个 SOA 用例： 数据整合过程重用第二个 SOA 用例描述了由使用者调用整合过程的情况。通常，以相对固定的时间计划来运行整合过程，常常在每周或每天的维护窗口内执行。整合与业务流程是相互分离的，后者通常并不按照很严格的时间计划运行。在 SOA 上下文中，业务流程中的某个步骤或应用程序可以直接调用整合过程。下面是这个用例的两个示例： “Refresh my DataMart Now”可能是一个按钮，而业务分析员可以“根据需要”，仅在需要更新信息的时候使用它。自动刷新可能会带来问题，因为只需要对财务数据进行指定时间点的分析。这些更新应该根据主题专家的规定是“实时的”，而不是在技术上可行时进行。通过这样的按钮来调用数据整合过程，为这种需求提供了一种解决方案。 大型的制药公司可以在 SOA 上下文中使用数据整合模式以支持远程试验统计数据的收集和研究。对试验数据收集进行标准化处理，可以帮助缩短目前较长的和昂贵的制药产品研发生命周期。在使用了这种模式的应用程序中，各个实验室在需要向隔离的事务型系统中插入研究细节信息时调用整合服务，并将图形（演示文稿和 JPG 文件）放入到中央存储库中以进行核准。整合服务收集来自给定实验室的统计数据，并将它们存储到公司的集中式的跟踪系统中。统计数据由多种不同的工具生成，而存放在唯一的数据存储中。在实现这种模式之前，只能通过各种手工、自制电子和基于纸张的系统来完成统计数据和支持材料的收集，其效率比较低。图 3 说明了业务流程中的活动（在图中称为“invoke”）如何将请求发送到（可能通过 ESB）实现信息服务支持的组件。该组件接收服务请求，并调用整合过程。随后，从不同的数据源收集相关数据并对其进行处理，并将结果应用于相应的目标。图 3. SOA 可访问的和可重用的数据整合过程第三个 SOA 用例： 数据整合+CDC第三个 SOA 用例代表了两种模式的组合：数据整合和数据事件发布或更改数据捕获，如图 4 所示。图 4. 数据整合和数据事件发布许多公司面临着实现有效的库存管理的问题。产生这个问题的部分原因是，库存相关信息存储在许多异构的数据库中。然而为了优化库存，需要以一种集成的和一致的方式来访问这些信息。例如，在针对库存信息访问和分析进行信息整合时，需要解决相同零件的不同零件编号的问题。有些库存相关信息变化很频繁，例如供不应求的产品，而其他的数据可能维持不变。这种情况需要将分布的、异构的和经常变化的信息整合到单个存储库中。数据事件发布和针对目标存储库的数据“供给”，是应用数据整合模式的另一个重要的上下文。使用这种方法的驱动因素包括： 目标系统以接近实时的方式与数据源进行同步。这对于决策支持应用程序或协作操作系统可能非常重要。目标的使用者可以立即看到结果。 这种模式排除了在批量窗口中长时间彻底搜索源系统的需要。这种彻底搜索可能会降低数据源的性能，并影响到其他应用程序。 仅通过网络发送“更改的”信息，并对其进行进一步的转换处理，从而减少了网络和执行相关操作的系统的负担。问题陈述SOA 使用者请求需要访问来自多个异构数据源的信息的服务。这些数据源经过了独立地设计、开发和改进，以至对于相同类型的数据，它们使用了截然不同的表示方式。异构性可能出现在实例级，例如缺少公共的键（因为使用了不同的格式），或模型级，例如将相同的现实世界实体建模为各种不同的数据库实体。SOA 使用者不必了解基础异构性，但必须能够透明地访问集成的信息。 （数据模型和数据表达的异构性，甚至是语义异构）许多应用这种模式的情况都需要集成信息具有高度的可用性。通常，由于资源利用率和应用程序更改灵活性的限制，源系统受到了一定的约束。同时，为了提供所请求的服务，需要执行相当复杂的数据处理操作。解决方案目标具体目标包括： 集成来自高度异构的不同数据源的信息，支持对集成信息的只读访问，同时提供很好的数据可用性、可伸缩性和性能。 提供各种转换功能，以处理不同数据源之间的冲突，并将源数据重建为所需的目标数据模式。 分离对集成目标数据的访问与将不同来源的数据集成和转换到目标的过程，以提供好的可伸缩性和性能。启用需要对整合数据进行更新的场景（如操作型主数据管理系统），以便将这种模式与能够将目标系统中的更新传播回数据源的其他方法结合起来，从而保持这些系统之间的同步。解决方案描述数据整合方法包括三个主要阶段。在第一个阶段中，整合服务器（实现数据整合模式的组件）收集（或“提取”）来自不同数据源的数据。接下来，对源数据进行集成并将其转换为目标模型，这可能需要多步操作来完成。最后，整合服务器将经过转换的数据应用于目标数据存储。 这个过程可以按时间计划（重复地）运行，或者由业务流程或任何其他服务使