面向服务的数据集成方法

面向服务的数据集成方法胡超1周晓峰1李超11河海大学计算机及信息工程学院南京（210098）Email:[e-mail]摘要：围绕异构环境中数据集成及主动服务方面的需求，在WebServices的基本框架下，采用WSDL、UDDI、SOAP、XML等技术，设计基于主动服务的数据集成平台。通过构建全局本体库解决语义异构问题，利用WSDL描述用户提供的服务，主动推送用户所需数据，为实现基于主动服务的分布式异构数据集成提供了一套有效的解决方案。关键词：数据集成、本体、WebService、WSDL、主动服务中图分类号：TP302.11引言如何获取网络上自治、异构、分布的数据并加以综合利用，即数据集成，成为一个引起广泛关注的研究领域。数据集成是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集成，实现分布的、异构的、自治的数据共享的主要技术，数据集成一般还应满足用户数据访问的实时性和安全性等方面的要求。目前，数据集成[1]主要通过多数据库集成技术、Mediated系统、数据仓库技术、移动Agents技术和基于WebServices的信息集成技术实现。2传统的数据集成方法早在20世纪70年代中期就提出了多数据库的集成问题。多数据库集成系统支持用户使用单一数据定义和操作语言，同时访问多个独立的数据源。代表性的多数据库系统有Garlic,Tsmmis,IRO-DB、Yat和HP公司开发的Pesasus[2]。国内有东北大学数据库研究室开发的PolyBase和SCOPE系统以及北京理工大学的UNHDB系统等。多数据库集成系统开始采用全局模式的集成方法，后来Mcleod等人提出了联邦数据库系统的概念。联邦数据库系统是由参与联邦的半自治的数据库系统组成，目的是实现数据库系统间部分数据的共享[3]。由于缺乏必要的标准，联邦数据库系统只能在一定的限制条件下实现，难以实现各种数据源的灵活数据集成。多数据库集成系统难以实现非数据库系统中的数据，可扩展性不强。对于网络上越来越丰富的数据源，多数据库集成系统不是一个很好的解决方案。Mediated系统通过提供所有异构数据源的虚拟视图来实现集成，数据源可以是数据库、遗产系统、Web数据源等。用户针对mediated模式提交查询。Mediated系统中的数据源是自治的，所以对数据源的访问通常是只读的，而联邦数据库系统支持读写访问[4]。Mediated系统主要由中介器（Mediator）和针对每个数据源的包装器（Wrapper）组成[5][6]。随着中间件技术的发展，Mediated系统基于中间件实现，这就是基于中间件的分布式集成系统[7]。基于-1-中间件的分布式集成系统用分布式的对象模型，诸如，微软的分布式组件对象模型(DCOM)[8][9]、CORBA[10]或Sun的RMI[11]来构建信息集成系统[12]。这种方法有效的避免了联邦数据库系统带来的开发代价大，代码难以重用的问题，利用网络计算环境可以有效的实现复杂的大规模的信息集成。但是，DCOM，CORBA或RMI要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。数据仓库技术需要建立一个存储数据的仓库，由ETL工具定期从数据源过滤数据，然后装载到数据仓库，供用户查询[13]。数据仓库系统由ETL工具、集成器和数据仓库构成[14]。数据仓库中主要存储历史数据和汇总数据，用于决策支持，通常不允许用户对数据仓库进行更新。数据仓库技术查询处理性能高，但是数据可能不是最新的，实时性不好。20世纪90年代初，GeneralMagic公司第一次提出了移动Agent的概念，即一个能在异构环境中自主地从一台主机迁移到另一台主机，并可与其它Agents或资源交互的软件实体。移动Agents系统一般包含移动Agents和移动Agent服务设施。移动Agent技术有很好的生存能力和适应能力，使用方便，并且具有一定的智能。基于移动Agents技术数据集成系统最大的优势是可以实现数据的定制[15]，满足用户个性化的需要，这是上述多数据库集成技术、Mediated系统和数据仓库技术难于实现的功能，但是系统实现复杂，安全性不好。WebServices[16]就是可以通过web描述、发布、定位和调用的模块化应用。WebServices功能强大，从简单的请求到复杂的业务过程。一旦WebServices被部署，其他的应用程序或是WebServices就能够发现并且调用这个部署的服务。WebServices是松耦合的，而且能够动态地定位其他在Internet上提供服务的组件，并且与它们交互。基于WebServices的信息集成系统在WebServices的框架下，使用一组WebServices协议(SOAP[17],WSDL[18],UDDI[19],XML[20][21])，构建信息集成系统[22][23]。为每个数据源创建一个WebServices，然后使用WSDL向服务中心注册。当要构建一个新的集成应用时，集成端首先向注册中心发送查找请求收集并选择合适的数据源，然后通过SOAP协议从这些数据源获取数据。这种方法克服了上述方法的缺陷，具有完好封装，松散耦合，规范协议高度可集成能力等特性。根据用户的定制需求，可为用户提供安全的、实时的数据推送服务。Webservice是一个接口,它描述了一组可以通过SOAP消息进行访问的操作。Webservice使用被称为服务描述的、格式正规的XML文档进行描述。服务描述涵盖了与服务进行交互所需的所有细节,包括消息格式、传输协议和位置。所谓“接口”,就是说Webservice隐藏了服务的实现细节,使得它具有硬件、软件平台和编程语言的无关性。这也使得基于Webservice的应用天生具有松散耦合、基于组件和跨平台实现的特性。Webservice解决的问题：现有的Internet是一个多元化的计算环境,是由各种不同的实现-2-技术、平台和操作系统共同结合而成的,对于DCOM,CORBA等技术,由于它们自身的原因,难以穿透防火墙进行相互之间集成。因此要使这些不同技术提供的服务组成一个网网相连的集成环境,就必须要有一个统一的标准来集成彼此的服务。WebService技术就是在这种情况下产生的。它是数据集成的首选方法。3面向服务的体系结构面向服务的体系结构（service-orientedarchitecture，SOA）来源于早期的基于构件的分布式计算方式，Allen在《Component-BasedDevelopmentforEnterpriseSystems》一书中首次提到了服务的概念，他认为服务是将构件描述成提供相关服务的物理黑盒封装的可执行代码单元，它的服务只能通过一致的已发布的接口进行访问，构件必须能够连接到其他构件以构成一个更大的构件[24]。在OMG和IONA的推动下，目前SOA已成为了一个大家所广泛认可的规范。面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互[24]。面向服务的体系结构主要由服务提供者、服务使用者和服务注册中心组成。如图3.1服务提供者是一个可通过网络寻址的实体，它接受和执行来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用者可以发现和访问该服务。服务使用者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。ServiceBrokerServiceRequestorServiceProviderServiceFindPublishWSDL,UDDIWSDL,UDDIServiceBindServiceWSDL,UDDIDescription图3.1SOA三层体系结构-3-服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务使用者查找服务提供者接口。SOA本身是如何将软件组织在一起的抽象概念，并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。虽然WebServices并不是实现SOA的惟一方式，但目前WebServices是实现SOA的最好方式。4面向服务的数据集成框架4.1.总体框架应用服务平台在逻辑上分成三个部分，分别是服务提供者、服务使用者和平台管理者，分别对应于SOA体系结构中的服务提供者、服务请求者和服务注册。总体架构如图4.1所示：服务提供者通过服务描述功能把传统的应用系统功能模块封装成服务，并在领域本体库的范畴内，描述软件构件的构件接口信息和行为信息,并利用服务发布功能把服务发布到UDDI注册中心；服务使用者利用工作流定义对应于具体业务应用系统的工作流程，并定义对应于每一流程结点的功能需求，利用应用生成功能自动生成业务应用系统；服务管理者利用领域问题空间定义功能维护领域本体库，利用服务访问管理功能负责维护UDDI注册中心和工作流数据，并通过安全访问控制提供的接口，对服务提供者和服务使用者的服务发布和服务调用进行控制。服务访问管理工作流定义服务提供者服务使用者平台管理者UDDI注册中心工作流数据系统生成服务发布服务描述构件库功能服务构件领域本体库领域问题空间定义图4.1应用集成平台框架4.2平台功能应用服务平台主要由六个功能组成，分别是服务描述、服务发布、工作流定义、系统生-4-成、领域问题空间定义和服务访问管理，分别供服务提供者、服务使用者和平台管理者使用。服务描述功能：是服务构件的拥有者生成服务构件描述信息的工具。该功能主要包括三个子功能，即服务构件接口描述、服务构件行为描述和服务封装。服务构件接口描述与webservices的描述类似，用于描述服务构件接口的语法信息，服务构件的拥有者在特定的领域本体库的范畴内描述2.3所要求的所有接口信息；服务构件行为描述用于描述服务构件的内部行为，同样，服务构件拥有者在特定的领域本体库的范畴内描述2.4所要求的所有内部行为信息；最后，根据前面定义的接口描述信息，把服务构件封装成符合webservice规范的服务构件。服务描述功能所生成的服务构件描述信息和服务存放在本地，通过服务平台提供共享。服务发布功能：提供服务拥有者在UDDI注册中心上发布由自己生成的服务构件，服务拥有者根据UDDI注册中心的要求，填写该服务相关的黄页、绿页和白页信息，根据UDDI规范，白页是该服务构件所属企业的基本信息，包括企业的名称、地址、联系方式和企业标识等；黄页主要是基于标准分类法的行业类别；绿页是该服务构件的技术信息，主要是一些指向文件或URL的指针，指向该服务构件及其描述信息所在的文件。服务发布的目的是使得其他用户可以通过UDDI注册中心查找到该服务。服务发布功能在目前提供的所有支持webservices的系统中都已实现，如IBM的WebSphere，BEA公司的Weblogic，开源代码Jboss等。工作流定义功能：提供用户定义业务应用系统的工作流程。一般认为，为有效地实现软件复用，必须把软件的功能逻辑、表现逻辑和过程控制逻辑相分离，工作流定义功能是与具体业务应用系统相一致的过程控制逻辑。首先，工作流定义功能定义业务应用系统的工作流程；然后针工作流中的每一个功能，依据领域本体库的规范，定义该功能的需求，该需求与3.2的查询条件一致。工作流定义功能也可以对已定义的工作流、功能需求进行维护，甚至可复用已有的工作流定义生成新的业务应用系统的工作流程。工作流定义所生成的文档存放在服务平台的工作流数据库中。系统生成功能：供用户根据已生成的工作流数据和UDDI