问题的提出
数据集成是企业信息系统的核心部分之一，它作为一个统一的数据平台为系统的其它部分提供数据支撑服务。许多企业拥有或将拥有多种业务系统，而每种业务系统都有自己的数据存储库，每个业务系统的数据从整体上来说一般是不完整的、不一致的。传统的解决方案为整合数据，它往往需要形成集中库，难以灵活适应底层数据源的变化。传统的解决方案要求直接从数据存储库中获取数据，并且只能从数据存储库中获取数据，但数据存储库往往不被允许直接访问，而且数据存储库中的数据常常是原生数据，它需要经过业务逻辑的处理才能成为有价值的数据，直接使用数据存储库中的原生数据是无意义的。因此，数据集成问题的关键是如何方便地得到需要的数据，如何进行正确的数据整合。
本文提出一种实时动态数据集成的服务框架，这个框架的数据集成是动态的，不需要建立集中库，数据集成是实时进行的；数据集成的数据源不局限于数据存储库，可以是一个应用、一个组件、一个服务，甚至可以将数据集成后的结果作为新的数据源。
SOA技术介绍
SOA即面向服务架构，可以看作是一种软件系统架构。它主要是为了解决在Internet环境下业务集成的需要，以松耦合
■ SOA架构中提供服务的功能实体具有完全独立自主的能力，这样不需要关心功能实体的实现方式和运行机制；
■ SOA架构中以低频率对大量数据进行访问，也就是在信息交换时希望一次性尽可能多地交换大量的数据；
■ SOA架构采用基于文本而非二进制的消息传递方式，消息本身是不包含任何处理逻辑和数据类型的，同样不需要关心消息接受者的细节。
XML和Web Services标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。XML是针对包含结构化信息的文档而设计的一种标记语言。采用这种描述方法，可以在保持原有数据的意义和结构的同时在应用之间进行数据交换，进而可以保持不同系统之间数据交换的灵活性。Web Services是基于最广为接受的、开放的技术标准（如Http、SMTP、XML、SOAP、WSDL和UDDI等），支持服务接口描述和服务处理的分离、服务描述的集中化存储和发布、服务的自动查找和动态绑定以及服务的组合，成为新一代面向服务的应用系统的构建和应用系统集成的基础设施。
Web Services可以定义为通过SOAP协议，在网络上提供服务，使用WSDL来描述这种服务，并通过UDDI注册服务以便使用者能找到服务。
SOAP：这是Web Services的通讯协议，用XML格式来定义消息，即SOAP消息，包含在一对SOAP中的、结构正确的XML段。目前常基于HTTP协议来传输XML数据。
WSDL：Web服务说明语言。WSDL文件也是一个XML文档，Web Service的细节描述都包含在其中。如参数类型、函数名称、返回类型、绑定协议等。调用者可以通过查看WSDL文件来确定Web Service的接口函数。
UDDI：这是Web服务的注册中心。Web Service提供者将其提供的服务注册到UDDI注册中心，调用者就可以到这个已知的UDDI注册中心查询到所需要的Web服务。
Web Services提供者实现服务的接口函数和服务的描述，并将其发布给调用者或注册到服务注册中心。服务调用者通过查询本地或服务注册中心的服务描述，选择所需要的服务进行绑定以调用Web Service的接口函数。服务的提供者以XML文档的形式将服务结果返还给服务调用者，完成了信息的交互。图1 是Web Services的体系结构。
图1 Web Services体系结构
基于SOA的数据集成
数据集成的本质是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中，从而为用户提供全面的数据共享。在数据集成领域已经有了很多成熟的框架。目前，通常采用数据仓库和基于中间层的方法来构造数据集成服务。
中间层模式通过统一的全局数据模型来访问异构的数据库、遗留系统、Web资源等。中间层位于各种数据源和应用程序之间，向下对各数据源起协调作用，向上为访问集成数据的应用提供统一数据模式和数据访问的通用接口。各数据源的应用仍然完成他们的任务，中间层则主要集中为各种数据源提供一个高层次检索服务。中间层提供一个统一的数据逻辑视图来隐藏底层的数据细节，使得用户可以把集成数据源看为一个单一的整体。本文提出的基于SOA的动态数据集成服务框架就属于中间层模式。
在基于SOA的数据集成中，XML提供一种规范化的数据结构以协助整合系统之间不同的数据结构，并以关联视图的方式展现被集成的数据。以“同一种语言交流”不再是必须的，Web Ser
基于SOA的数据集成将传统数据集成解决方案中，考虑不同系统中数据是如何交换的转变为怎样展现系统的功能，这样数据将不再是以点对点的方式获取，而是可以自由的在网络上得到的一种服务。系统不是在底层协议的基础上进行交互，而是在一个抽象的接口层面上进行数据交换。系统仅仅将它们的功能以服务的形式展现出来，其它的系统能容易地发现这个服务并在运行时或设计时绑定它。被集成的服务可以是任意的应用、系统和数据源，而不用考虑它们的特殊要求。
动态数据集成服务框架的研究
框架技术体系
图2是基于SOA的动态数据集成服务框架的技术体系结构。从图中可以看出，框架的技术体系由5个层次组成。分别是数据源适配器、服务包装器、SOA运行引擎、XML视图引擎、XML视图。
图2：框架技术体系结构
数据源适配器是同各种数据源进行交互的桥梁，它是一些可插拔的组件，并动态地进行加载。数据源适配器以遵从标准接口的方
服务包装器是将数据源适配器包装成标准的Web Services服务，这样就将对数据源的API访问模式转变为对服务的提供。服务包装器可以同时包装多个数据源适配器，这样它的另一个重要作用就是可以对来自一个或多个数据源的原生数据进行进一步的逻辑处理以将其转变为更有意义的信息，并可以在本地缓存处理后的数据。这样通过缓存提高了整个系统地效率和可靠性——即使数据源出现故障系统也有能力继续工作，同时将业务逻辑进行预先处理，降低了XML视图的复杂性，使得XML视图更易于被理解。服务包装器隔离了对数据的访问细节和对数据的逻辑处理细节，这两个部分可以独立地变化，极大地提高了系统的灵活性。
SOA运行引擎是框架的核心部分，通过它调度服务的执行，驱动数据集成的处理。SOA运行引擎包括了规则处理器、流程处理器、消息处理器等。SOA运行引擎将XML视图引擎解析的数据集成请求转变为对服务的调用请求，并由运行引擎去查找适合的服务、绑定服务并调用服务。
XML视图引擎提供三种机制：其一，它将多个异构的数据源表示为单一的即时虚拟数据库，这个即时虚拟数据库由一系列实时获取的XML文档构成。其二，解析用户来自XML视图的请求，将该请求向下层传达，并将最后结果以XML文档的形式返还给用户；最后，它将自己的元信息用XML Schema表达，这些XML Schema就是XML视图的基础，基于XML Schema进行XML视图的定义。XML Schema就如同关系数据库中的表一样，而XML视图就像关系数据库中同表相关的表视图（VIEW）一样。XML视图引擎本身也是以Web服务的形式提供，用户可以很方便地以一种标准的方式访问它，它也可同时成为另外的XML视图引擎的数据源。
XML视图是对数据集成的元信息描述，由它表达集成后的效果。它并不是集成的结果，而仅仅是集成结果的元数据表示，就像关系数据库中的表视图一样表示实际数据应具有的组成关系：数据来自于哪个表，对表数据需要作什么样的处理，不同表的数据是如何结合的等。用户查看XML视图就能了解该视图表达的数据集成的模式。可以根据不同的数据集成需要定义不同的XML视图，这就是动态的数据集成——在需要时才定义集成的方式，在运行时才能获得真正的数据。
从图2可以看出，这5个层次可以分为三个部分各自独立的进行开发和分布式部署。其中，XML视图和XML视图引擎是一个部分，SOA运行引擎是一个部分，服务包装器和数据源适配器是另一个部分。这样的分布式数据集成具有极高的灵活性，三个部分互不影响；同服务包装器一样，可以同时部署多个XML视图引擎，而XML视图引擎又可以被服务包装器封装成为一个新的数据源。这种机制可以比较容易的满足现代企业数据集成中复杂的环境，通过较小的代价达到灵活的数据集成要求。图3是一个典型的部署方案。图3中，XML视图引擎B使用服务包装器c，而服务包装器b将XML视图引擎B包装成新的数据服务，XML视图引擎A使用了服务包装器a和服务包装器b，也就是使用了服务包装器a和视图引擎B的某个XML视图。
图3：框架典型的部署方案
框架的运行机制是首先由用户查看XML视图，获得该视图上数据集成的元结构，基于该元结构发起合适的处理请求；XML视图引擎根据处理请求中相应的XML视图描述解析该请求，并将其转递
给SOA运行引擎；SOA运行引擎这些请求转变为对服务包装器的调用；服务包装器再将其转变为对数据源适配器的调用，由数据适配器执行实际的数据源访问；从数据源取回的数据经服务包装器处理后转变为标准的XML文档送回到XML视图引擎中；在XML视图引擎中再根据XML视图的集成方式描述完成实际的数据整合并将整合结果返还给客户。从框架的运行机制可以看出，这时数据集成是实时的，每次的请求都需要即时到数据源中获取数据。框架的基本运行机制如图4所示。
图4：框架运行机制
框架的结构
在基于SOA的数据集成框架中，其面向服务的体系决定了框架内部各模块之间的的关系：这些模块按照SOA的观点都可以视为服务，所有这些服务以松耦合的方式连接在一起。框架的核心部分SOA运行引擎的主要功能就是管理这些各种各样的服务，协调服务之间的交互，同时使用户能方便地存取这些服务。图5是框架的总体结构。
图5：框架总体结构
图5中，内置服务是框架正常运行而必须具备的服务功能。这些服务是框架底层使用的，对用户来说是不可见的。内置服务主要有：流程引擎，为框架提供流程定制和流程运行的功能；规则引擎，由它数据集成
插件服务是框架具有高扩展性和灵活适应各种需求的主要机制。它将提供数据的各种数据源包装成服务，并以可拔插的方式植入框架中。插件服务并不直接访问数据源，而是通过数据源适配器访问数据源，这样将对数据源的访问同服务的提供解耦，数据源适配器可以在运行时根据需要动态装配。同时，插件服务还可以根据需要对其数据源适配器获得的数据进行预先处理，以降低最终集成的复杂度，提高系统的整体运行效率。插件服务通过最小化的编程或仅仅进行配置就能扩展整个系统，具有极大的灵活性。
代理服务是一种扩展的插件服务，由它提供对诸如第三方应用，如ERP、CRM等数据源的包装以及对XML视图引擎的包装。代理服务和插件服务在对数据源的包装上的主要差别在插件服务包装的是具有明确API接口的数据源，如数据库、EJB、COM、MOM、SOAP等，而代理服务包装的数据源没有明确的API接口，需要对这些数据源进行更多的处理。同时代理服务也是数据递归集成的机制，即将集成后的数据作为其他数据集成的数据源。
服务管理器管理框架中所有的服务，是存取服务的入口，由它去查找正确的服务，管理服务的生命周期，检察服务的运行情况，调度服务的运行、注册服务等。服务工厂主要是用来生成各种服务。当服务管理器查找服务时，发现该服务还没有运行，服务管理器将请求服务工厂动态生成并运行这个服务。服务工厂将根据服务注册信息启动该服务，如果服务包装的底层数据源不可得，则该服务将企图装载在本地的缓存数据。
存取控制模块为安全使用服务和访问数据提供了基础。它的主要作用除了提供一个基于角色的存取控制外，还具有两个重要功能。其一，它采用一种基于标记的用户认证模型使得单一登陆就可以访问多个数据源，极大简化了用户的访问模式。其二，存取控制模块还将处理用户访问会话的生命期，使得用户只在一段特定的时间内访问系统，这将进一步提高系统的安全性。
服务存取信道是用户访问包装了XML视图引擎的服务的通道，并解析用户请求成为一系列能直接访问底层服务的查询计划。查询计划将被缓存，以便能尽可能地重用这些查询计划。当有新的请求时，服务存取信道将比较该请求以决定是否已经有可用的查询计划，如果有的话，就直接使用它，这样极大地提高了系统的运行效率。一个服务存取信道可同时提供多个用户使用。
存取信道管理模块提供了对服务存取信道的运行时管理，它将根据不同用户的访问请求，将可能返回相同数据的访问请求合并成一个请求；或者对多个用户访问请求进行优先级排队处理，以保障优先级高的请求能尽快被处理；或者将多个用户小数据量的请求多路复用到一个服务存取信道，保证大数据量的请求有足够的服务存取信道可用。通过这些机制，降低了系统的资源消耗，提高了系统的运行效率。
服务发布/订阅接口提供了同框架异步通讯的机制。各种服务可以在服务发布/订阅接口订阅需要的消息，当有适合的消息发布时，所有订阅了该消息的服务都将得到通知，这是一种多对多的通讯机制。服务发布/订阅接口也能同各种消息中间件相连，以便提供基于消息的服务互连功能。同时，通过服务发布/订阅接口，框架将具有一定的事务处理能力。
基于SOA的动态数据集成服务框架为异构异型数据的集成和共享提供了一个面向服务体系结构的框架，它以XML技术为基础，动态集成为手段，实现各种应用系统之间的数据集成，实现跨平台数据的共享，达到跨平台数据资源整合的目的，实现 了信息的互通互联。基于SOA的动态数据集成服务框架可以为解决跨平台数据共享和集成所面临的异型异构接口、实时数据交换和随需应变等技术问题，提供有效的解决方法和途径。
