1、信息服务模式Mei Y. Selvage (), SOA 数据架构师，Enterprise Integration Solutions, EMCEoin Lane (), 高级解决方案工程师, EMCDr. Guenter Sauter (), Senior IT Architect and Manager, IBM CorporationBill Mathews (), Senior IT Architect, IBM Corporation第 1 部分: 数据联合模式简介： 数据联合模式可对来自多个异类信息源的数据进行虚拟化。该模式为分布式信息创建了集成视图，且在联合结构化和非结构化的信息
2、时不会造成数据冗余。本文描述 SOA 上下文中的结构化信息（数据）联合。此模式规范可帮助数据和应用程序架构师明智地确定数据体系结构和文档决策指导原则。引言信息的不一致和分散让很多组织十分烦恼。在很多情况下，用户花费了大量的时间搜索并手动聚合、关联和更正相关信息，而不能直接根据从信息获得的要点采取行动。这个被广泛认识的挑战也出现在实现面向服务的体系结构（Service-Oriented Architecture，SOA）时。通常，核心服务需要使用来自多个不同源的已聚合的高质量信息。现有多个概念和技术专门用于满足这种集成需求。数据联合就是其中的一个。数据联合的目标是有效地联接来自多个异类源的数据，
3、合理利用现有的数据不会造成数据冗余。数据联合模式支持在集成的临时（虚拟）视图上进行数据操作；在此类视图中，实际数据存储在多个不同的源上。源数据仍然在源系统的控制之下，会根据需要进行提取，以进行联合访问。本文重点强调了数据联合方法的价值。描述了应用数据联合的上下文后，我们将讨论此模式所针对的问题及其解决方案。我们根据非功能需求对此模式的适用性特点进行了说明（请参见注意事项部分）。此模式的一些已知用法源自我们应用此模式的经验。最后，我们将总结此模式的重点、风险以及限制。数据联合方法的价值主张 基础异类系统透明性通过使用数据联合，使用者将看到的是单个统一接口。位置透明性意味着使用此模式的应用程序不需
4、要注意数据存储的位置。得益于调用透明性，它也不需要知道源数据库所支持的语言或编程接口。例如，如果使用了 SQL，应用程序则不必知道源支持的是哪种 SQL 分支。由于具有物理数据独立性、碎片和复制透明性，因此应用程序不需要知道数据的物理存储方式；而源于其网络透明性，应用程序也不需要知道所使用的是什么网络协议。 上市时间优势作为数据联合服务器使用者的应用程序可以与单个虚拟数据源通过接口进行通信。如果不使用联合模式，应用程序必须通过不同的接口和不同的协议与多个源分别交互。研究表明，当必须集成多个源时，使用数据联合模式可帮助大幅度减少开发时间。有关更多信息，请参见参考资料部分。 减少开发和维护成本很多
5、使用者可能会使用相同（或非常相似）的集成信息。可以采用这样的方法处理此问题：每个使用者采用自己的实现来聚合来自不同源的信息。或者，可以一次性开发集成视图，然后在单个位置对其重复利用和维护，从而实现单点更改。此方法可减少开发和维护成本。 性能优势与内部开发的信息聚合方法相比，特别关注高级数据处理技术的数据联合模式实现在很多情况下都已证明具有卓越的性能特征（有关更多信息，请参见参考资料部分）。通过利用高级查询处理功能，联合服务器可以在联合服务器本身和各个源之间最优地分布工作负载。它将确定工作负载的哪个部分由哪个服务器执行最高效，以实现响应时间最优化。 可重用性优势将数据联合模式应用到特定集成场景后
6、，此特定联合访问的结果可作为服务向多个服务使用者提供。例如，某个集成场景可能要求从各种源检索结构化和非结构化保险索赔数据。在此示例中，数据联合模式可以提供集成索赔数据的解决方案，以便随后将集成索赔数据通过门户提供给索赔代理人。可以随后将相同的联合访问作为服务提供给其他使用者，如标准索赔应用程序的自动流程或面向 Web 应用程序的客户机等。 改善控制控制是 SOA 生命周期的关键基本要素。通过执行具有可预测结果的最佳实践，控制流程可通过使用模式得到增强。在系统的开发和创建过程中重用经过验证的灵活模式可同时确保一致性和高质量，并同时通过使用单个源来更新更改，从而减少维护成本。上下文公司和组织间的合
7、并和收购通常要求数据和应用程序架构师将异类数据源集成到数据的统一视图中。此类集成信息的使用者是直接与数据库交互的传统应用程序，需要能够访问经过扩展的数据源集。有关如何最好地提供此统一视图的决策通常是根据组织中的工具可用性、经验、专业知识以及企业文化做出的。使用传统遗留体系结构时，与集成关联的时间、工作量以及成本可能会超过所带来的业务好处。在基于服务的环境中实现了基于模式的信息服务方法后，可以增强系统长期的可重用性特征。信息服务是 SOA 的核心中枢的一部分。这些信息服务提供了对域信息的创建、读取、更新和删除 (CRUD) 访问。它们还可提供各种信息处理功能，如通过分析和评分算法、数据清理规则等
8、进行处理。对于本文，我们将重点讨论可提供统一数据视图的信息集成服务，而这通常会涉及到对各种异类后端源和服务进行集成。应用数据联合模式时，我们需要对两个上下文进行区分：传统的非 SOA 上下文（由很多以前的应用程序加以处理）和 SOA 上下文（本文的重点） 。务必记住，SOA 是一种体系结构方法，可通过其得到可重用服务，能在很多情况下扩展现有非 SOA 实现的功能。 传统上下文在我们称为传统上下文的环境中，银行的报表应用程序可能需要分析信用卡事务。考虑到此数据的量（每天数百万事务） ，将所有这些信息存储在分析数据仓库中并不是有效的办法。会频繁访问很多旧数据，将其作为特定的上下文信息，如旅行路线等
9、。将所有信用卡事务数据当前的和过期的、核心的和相关的存储在数据仓库中会对性能造成负面影响。一种更好的解决方案是将两种类型的数据加以分离：例如，可将常用、最近使用的信息库事务存储在数据仓库中，而将旧信息存储在磁带上。不过，报表应用程序应该不需要知道这种可通过联合方法提供的数据分布。图 1. 传统数据联合模式在此传统上下文中，应用程序通常使用标准关系接口和协议来与联合服务器（如 SQL 和 JDBC/ODBC）交互。联合服务器将随后通过各种适配器或包装连接到各种数据源，如关系数据库、XML 文档、已打包的应用程序和内容管理及协作系统。联合服务器是一个虚拟数据库，具有关系数据库的所有功能。请求应用程
10、序或用户可以在其访问权限内执行任何查询请求。查询完成后，将返回一个结果集，其中包含满足选择条件的所有记录。此过程如图 1 中所示。此图旨在演示可以基于使用 SQL (JDBC/ODBC) 或 XQuery 的关系应用程序编程接口的传统实现。 SOA 上下文在 SOA 上下文中，服务 getCustomerCreditCardData 可能需要检索有关客户及其信用卡事务的全面信息。此信息可能并不是驻留在单个系统中。客户信息可能存储在客户主数据管理系统或多个存储库中，而信用卡事务则可能存储在另一个数据源中。数据联合将对来自多个源的信息进行联接，以便能作为服务向使用者提供。在此 SOA 上下文中，联
11、合服务器充当使用 SOA 一致接口的服务提供者和/ 或服务使用者。请注意，这并不排除服务器还会提供对传统关系接口的支持。支持的深度是一项实现决策，这超出了本文所讨论的范围。当数据联合服务器将集成信息作为服务提供者公开时，服务使用者可以通过服务接口（如 WSDL 和 HTTP/SOAP 或其他事前确定的绑定）来访问此集成信息。数据联合服务器可以使用（为了集成）多个信息源提供的服务。 在 SOA 上下文中使用数据集成模式的基本想法是利用和重用集成信息，即，信息集成服务能以可扩展的方式供各种使用者使用。服务的建模和定义是 SOA 的关键方面。一个受到广泛认可的最佳实践是，将服务设计为能提供信息或功能
12、的重用和/或跨企业互操作性和/或业务流程支持。很多（如果不是大多数）成功的 SOA 项目都将重点放在作为服务公开的最重要、最广泛使用的业务功能上。由于这些服务扮演着关键的角色，因此经常会涉及多个后端系统。因此，从多个异类源收集信息是 SOA 依赖的一项重要需求和功能。服务并不是传统数据访问上下文中的查询，而是对业务实体的请求，可以由联合服务通过一系列查询和其他服务加以满足。图 2. SOA 上下文中的数据联合模式在 SOA 内启用信息集成服务需要使用额外功能，以在面向服务的接口中封装联合访问。这是通过 Information Service Enablement 实现的。此组件用于在面向服务的
13、接口中提供一些联合查询。例如，可以使用 SQL 编写联合查询，并可以指定对产品信息的访问。通过 Information Service Enablement 组件，此联合查询可以作为使用特定机制（如 SCA 或 WSDL）定义的服务提供。实现对产品数据的访问的服务可以随后在整个企业内和企业外进行共享。在传统上下文中应用数据联合模式的解决方案可以利用 SQL 的声明性和灵活性特征。通过使用恰当的安全凭据，使用者可以访问源中的任何数据，而此过程可能涉及的不同 SQL 查询的数目几乎没有限制。使用者在访问的内容及结果返回的格式方面具有极大的灵活性。尽管在很多情况下，这个灵活性是一个很大的优势，但也增
14、加了使用者所面临的复杂性。使用者必须了解源数据模型以及如何从这个基础源数据模型构造结果。源数据模型越大，此任务就会变得越复杂。 SOA 方法的重点是首先将数量相对有限的最关键业务功能定义为服务，并在整个企业内和企业外进行共享。因此，面向服务的接口更多的是关注数量有限的需向外提供的特定信息请求。这个清楚而集中的重点可为开发人员带来好处，因为这样可以减少他们设计信息请求的时间。他们可以直接从数量相对有限的选项中选择恰当的服务。问题说明在当今业务驱动的环境中，架构师和开发人员要实现数据联合解决方案的情况非常普遍。他们所面临的挑战通常受到一系列体系结构决策的影响，而后者实际上又受到技术、业务或合同方面
15、约束的影响。此场景中包含多个此类常见约束。首先，支持项目的信息访问要求所必需的数据驻留在多个源中，必须对其进行集成，并作为单个结果向用户提供。其次，无法对目标数据源进行复制来满足访问需求。最后，解决方案必须在现有 SOA 内集成，并仍然支持传统的非 SOA 应用程序，如 图 3 中所示。 图 3. 异类接口访问解决方案目标正如问题说明中所述，此方法的目标是避免提供异类源的集成视图时出现数据冗余。数据联合服务器即实现数据联合模式的组件必须针对传统非 SOA 上下文提供标准查询接口。这可确保各种各样的传统数据库应用程序能够使用联合数据。联合服务器还必须提供查询优化功能，以最高效地响应请求。此上下文
16、中数据的分发和异类性特征决定了必须重点强调如何最好地转换对集成视图的访问，以及如何分解和分布工作负载。支持对此集成视图的写访问时，联合服务器必须将各个源中的数据操作同步到逻辑工作单元中。这可确保满足事务的原子性、一致性、隔离和持久性 (ACID) 标准，且保证引用完整性。除了针对传统上下文的这些目标外，此方法还必须适合在 SOA 中使用。这将允许企业内外的各个用户能够有效地重用集成视图。SOA 中的联合访问的潜在使用者是需要访问分布式信息的应用程序、门户和业务流程中的活动。例如，制造商可能定义从异类源检索实时库存信息的服务。内部应用程序和外包业务合作伙伴可以访问相同的服务，从而利用此联合访问的
17、一致且最高效的实现。解决方案描述在传统上下文和 SOA 上下文中，数据联合服务器提供了有效联接和处理来自异类源的信息的解决方案。此模式实现了处理分布式数据的同步实时集成方法。数据联合服务器负责接收定向到各种源的集成视图的查询。它会使用复杂的优化算法对其进行转换，从而将查询拆分为一系列子操作（称为查询划分与重写） ，然后对相应的源应用子操作，从每个源收集结果，组装集成结果，并最后将集成结果返回到原始查询。此处理序列将以同步的方式实时完成。设计时特征数据联合模式要求对集成视图范围内来自各个数据源的数据元素进行映射。例如，上面示例中提到的保单持有人姓名和地址等客户信息可以存储在一个数据库内的单个表中
18、，也可以存储在另一个数据库内的多个表中。为了构建集成视图，需要将这些不同类型的表示形式映射到公共视图中。映射可以由相关人员手动执行，也可以采用基于各种映射算法（还会捕获任何必要的转换需求）的最新工具辅助完成。这就允许数据联合服务器接收对集成视图的查询和计算要执行的最优子操作数量和类型。 在 SOA 上下文中应用数据联合模式时，需要在 SOA 内将一组联合查询作为服务启用并注册。例如，用于检索保单持有人的关键结构化和非结构化信息（如姓名、地址、状态、索赔文档、维修费用预估和风险评级等）的集成视图可以作为服务启用，并在多个用户间共享。设计时的映射结果通常为联合视图，与关系数据库视图类似，可以随后在
19、联合服务器上进行部署或创建。运行时数据联合服务器接收对集成视图的请求。根据映射定义，联合服务器将联合查询拆分为多个子操作。多个因素会对此步骤造成影响： 响应联合查询所必需的数据驻留在何处？ 为了将异类源表示形式（如不同的数据类型、规范化模型与非规范化模型）转换为公共集成视图，必须执行哪些操作？联合服务器使用映射信息来解决这些问题。还有很多其他因素会影响联合查询处理，这将要求使用映射规范之外的其他信息，如： 系统管理数据源支持哪些操作，哪些操作必须由联合服务器提供补偿机制？ 在源中执行一系列操作与在联合服务器上执行这些操作的性能影响如何？联合服务器应将哪些操作委派给源，以便更好地利用源的功能、减
20、少数据传输以及优化总体性能？回答这些问题需要使用源系统及其查询处理功能方面的知识。为了处理后一个问题，联合服务器还必须使用一系列关于操作环境的信息以及源数据的统计数据。 联合服务器确定了所有子操作的最佳执行策略后，将连接到数据源包括结构化和非结构化信息的数据源以检索相关数据（可能会使用源特定的接口） 。根据总体查询执行计划，将随后对数据源执行各个子操作。将接收结果并聚合为集成视图的结果。然后会将此结果返回给使用者。在 SOA 上下文中，使用者通过预定义的请求格式向联合服务器提交请求。联合服务器将请求转换为对应的 SQL 查询或视图定义，以支持服务。从此时开始，将执行与以上所述相同的查询分解、优
21、化和执行步骤。SOA 中唯一的区别在于最后一步。联合服务器会将传统数据联合方法的结果转换为服务响应，并随后通过预定义的服务接口将其返回给服务使用者。图 4. 数据联合的序列图数据联合模式的功能可以通过使用数据相关的技术（如优化器或补偿）或自己开发的应用程序来实现。由于异类源上的查询优化的复杂性，行业最佳实践是使用数据联合实现来利用大多数数据库管理系统提供的查询优化技术。注意事项应用数据联合模式时，务必理解其特征以及其受以下所述的非功能要求的影响情况。一定要注意，我们列出的功能要求并不考虑缓存和数据复制模式。我们认为，当采用以基本模式（本例中为数据联合）为基础模式时，可以随后通过其他模式对其进行扩展，以便满足服务的额外非功能要求和功能要求。可以使用缓存和数据复制模式来补充数据联合或形成组合模式。应小心使用这些模式以及可以在总体实现中使用的其他模式，因为它们可能会妨碍最初选择数据联合来解决的一些非功能要求的实现。例如，它们可能会增加数据延迟和导致数据冗余。需要了解非功能要求和体系结构决策之间的得失。非功能要求的所有特征既适用于传统的非 SOA 上下文，也适用于 SOA 上下文。其包括：
