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