专利名称：：一种面向服务的分布式工作流管理系统的制作方法
技术领域：
：本发明属于计算机应用领域，具体涉及一种面向服务的分布式工作流管理系统。
背景技术：
：当前，在面向服务的体系结构(ServiceOrientedArchitecture,SOA)中，基于标准协议(XML，HTTP,WSDL和SOAP等)的Web服务和WSRF服务正处于核心地位，由于其跨语言、跨平台的技术中立性，同时历史遗留的应用程序和系统也可以封装成为服务得以继续利用，赢得了主要软件供应商和企业组织的普遍欢迎和支持。开放标准、松耦合的服务组件以提供标准的接口和服务功能来封装了底层异构的物理资源和软件环境，他们是能够被动态发现的和被组合集成的服务实体。因此，基于服务构建的软件系统除了能够互相访问，还可以根据需要进行集成，即就是由一些松耦合且具有统一接口定义方式的组件(服务)进行组合。在服务集成的过程中，工作流理论和服务组件相结合，使得能够依据流程逻辑，由独立存在的具有原子特征的服务(原子服务)扮演一定角色，参与组合成增值的能够处理流程事务的复合服务。复合服务能够根据时间推移和需要进行重新定义甚至销毁，但其丝毫不影响原子服务作为一个独立自治的实体向外界提供服务功能，同时，一个原子服务还可以被定义到其他的复合服务中去，身兼数职，在另一个流程逻辑中担任其他角色并提供服务。因此，服务复合思想和工作流技术被看作SOA的"心脏"。当前，各大软件公司也把工作流管理系统和面向服务的思想相结合，把开发和推广基于服务的工作流管理系统作为占领技术和市场的制高点。例如，Microsof推出的BizTalk就集成了面向服务的BPEL引擎，Oracle公司推出的0raclel0g中集成了OracleBPELProcessManager和BPELDesigner，IBM和SAP也正在加紧基于BPEL的工作流管理系统。同时，一些开源组织和个人也纷纷加入到研究和开发的队伍中来，比如ActiveBPEL就是一个非常出名的开源BPEL引擎。由于面向服务的工作流管理系统开发和发展还处于初级阶段，所以还存在很多不完善的地方。首先，以上提及的工作流管理系统都是集中式的单一引擎，当负载任务变重后不能得到均衡，性能就成了很大的瓶颈；同时还可能存在着单一失效点，当工作流引擎崩溃后，整个系统就会瘫痪。其次，以上系统只支持物理上真真存在的具体服务担任原子服务参与具有工作流逻辑的服务复合，没有服务虚拟化的概念，因而不能有效地在物理服务之间根据服务质量进行最优选择。另外，以上系统只支持标准的Web服务，而对于有状态的WSRF服务不支持，这大大削减了面向服务的支持能力。
发明内容本发明旨在提供一种面向服务的分布式工作流管理系统，该系统具有支持虚拟服务参与服务复合、支持WS/WSRF服务、基于QoS的动态服务选择和工作流作业动态负载均衡功能。4本发明提供的面向服务的分布式工作流管理系统，包括用于支持服务实例存在的运行时环境的服务容器，其特征在于该系统还包括客户端界面模块、分布式工作流引擎模块和服务动态选择代理模块；客户端界面模块用于为外界用户提供基于Web页面的交互接口，它接收来自用户的各种请求，并将其转交给分布式工作流引擎模块进行处理，处理完毕后，接收处理结果，并展现给用户；分布式工作流引擎模块接收来自客户端界面模块的各种请求，处理后将结果返回给客户端界面模块；分布式工作流引擎模块在虚拟服务参与工作流执行时会调用动态服务选择代理模块；分布式工作流引擎模块还负责执行工作流作业，并按照流程把子任务调度物理服务上执行；动态服务选择代理模块用于接收来自分布式工作流引擎模块的服务选择请求，从属于同一虚拟服务的物理服务中选择具有最优服务质量的物理服务进行作业执行。本发明提供的一种面向服务的分布式工作流管理系统具有以下优点和效果(1)支持虚拟服务作为原子服务参与服务复合服务虚拟化能够聚集众多提供相同功能的物理服务，向外界提供统一的功能接口。把虚拟服务作为原子服务参与服务复合可以实现在执行的过程中，在多个物理服务之间根据其提供的能力和服务质量(QoS)进行透明选择，选择具有最优服务质量的物理服务执行作业。(2)支持WS/WSRF服务除了支持无状态的Web服务(WebService,WS)，本系统还对工作流引擎进行了很大的扩充，使其支持带状态的WSRF服务(WebServiceResourceFramework，WSRF)，使得能够根据需要，支持持久性的作业执行和保留基于资源的服务状态和作业状态信息。(3)基于QoS的动态服务选择本系统在从虚拟服务中映射和选择合适的物理服务中，着重考虑了服务质量(QualityofService,QoS)，根据物理服务的服务质量进行量化分析，实现了服务动态选择的最优化。(4)分布式工作流引擎，实现了作业动态负载均衡本系统支持多个工作流引擎协同运行，消除了由于单个工作流引擎造成的负载过量而效率低下，同时消除了单一失效点；根据各个引擎的负载情况，对作业请求进行动态调度，选择负载最小的工作流引擎来执行，实现了负载均衡、高可用和很高的健壮性。图1为本发明分布式工作流管理系统的分层结构示意图；图2为本发明分布式工作流管理系统的逻辑结构示意图；图3为本发明分布式工作流引擎模块的内部逻辑结构示意图；图4为复合服务的部署流程示意图；图5为复合作业的执行流程示意图。具体实施例方式在展开系统的具体实施说明之前，先对本系统中定义的几类服务及其之间的关系给出如下说明(1)虚拟服务(VirtualService)虚拟服务是相对于物理服务(PhysicalServic)而言，虚拟服务是一个逻辑上概念，不具有真正提供服务的能力。虚拟服务只通过WSDL定义服务的接口和功能，而相应的物理服务可以根据其接口和功能来选择某种编程语言实现并部署到服务容器，向外提供服务。一个虚拟服务往往可以对应多个物理服务。如下公式所示vs={psIf!(ps)}①在公式①中，vs表示一个虚拟服务，ps表示物理服务，^表示这些物理服务拥有同一服务功能和统一的服务接口(PortType)。(2)物理服务(PhysicalService)物理服务提供真正的服务能力，存在并部署在服务容器中。本系统支持两类物理服务Web服务和WSRF服务，如下公式表示PS={psI(psGWS*)V(psGWSRF*)}②在公式②中，PS是物理服务的集合，ps表示单个物理服务，WS*表示Web服务，WSRF*表示WSRF服务。一个物理服务可以是标准的Web服务，也可是WSRF服务。(3)属于同一虚拟服务的物理服务之间的关系同属于同一虚拟服务的多个物理服务拥有同一服务功能和统一的服务接口(PortType)，但并不一定拥有相同的服务能力。即物理服务之间的服务质量(QaulityofService,QoS)可能不同。因为支撑和实现这些服务的物理资源和软件环境是异构的，而且服务能力还处于动态变化中，安全等级等也可能差别很大。下面结合附图和具体实施方式对本发明做进一步说明。如图1所示，本发明系统架构按照分层思想分为三层应用接口层、系统逻辑层和物理服务层。应用接口层是本系统对外界用户的交互接口，由客户端界面模块l构成。系统逻辑层是整个系统的主要功能实现模块，包括分布式工作流引擎模块2和服务动态选择代理模块3。物理服务层主要是由具体的服务实例构成，供上层进行服务组合和调度执行，所有的服务实例存在于服务容器4中。服务容器4是服务实例存在的运行时环境，一般都包含有SOAP引擎，为各个服务提供实例启动、消息传递、服务调用、服务安全等功能。如图2所示，客户端界面模块1按照B/S架构，实现了一个基于Web页面的系统客户端界面，包括系统管理员页面，工作流引擎注册页面，复合服务部署页面，普通用户提交复合作业页面，引擎、服务、作业的监控页面。客户端界面模块l接收来自用户的各种请求，并将其转交给分布式工作流引擎模块2进行执行，执行完毕后，接收结果，并展现给用户。分布式工作流引擎模块2是整个系统的核心部分，它接收来自客户端界面模块1的各种请求(服务部署、作业提交、监控、返回作业结果)等，进行处理，然后将处理结果返回给客户端界面模块1。另外，在工作流执行的过程中，若有虚拟服务001参与了工作流执行，分布式工作流引擎模块2便会调用动态服务选择代理模块3进行虚拟服务001到物理服务002的映射选择和作业调度。分布式工作流引擎模块2负责执行工作流作业，并按照流程把子任务调度物理服务002(Web服务003、WSRF服务004)上执行。其内部结构和详细功能模块将结合图3进行介绍。动态服务选择代理模块3是在复合服务执行过程，当遇到的原子服务是由虚拟服务001担当时，接收来自分布式工作流引擎模块2的服务选择请求，在属于同一虚拟服务001的多个物理服务002中，计算每个物理服务的服务质量(QoS，QualityofService)值，然后选择最优的物理服务002，进行作业执行。我们支持虚拟服务作为原子服务参与服务复合功能主要由动态服务选择代理模块3和虚拟服务001、物理服务002、Web服务003和WSRF服务004来完成。其中服务质量(QoS，QualityofService)为服务所处的硬件资源性能参数(如内存大小、存储空间、CPU的个数、完成时间)和服务的品质指标(如价格、信用等级、安全性、可靠性)。服务容器4是支持服务实例存在的运行时环境，一般都包含有SOAP引擎，为各个服务提供实例启动、消息传递、服务调用、服务安全等功能。在本系统中，服务容器4采用第三方软件，它包括两种类型一种是支持纯Web服务003(WebService)容器，如Apache开源Axis,IBM的Websphere等；另一禾中是支持WSRF(WebServiceResourceFramework)月艮务004的容器，如Globus联盟的GT4，Microsoft的WSRF.NET等。如图3所示，分布式工作流引擎模块2是整个系统的主要部分，其包括了以下子模块作业队列子模块21、监控子模块22、作业调度与负载均衡器子模块23、引擎管理器子模块24、信息中心子模块25、工作流引擎261，262，…，26n。作业队列子模块21支持工作流作业请求进入作业队列。其首先接收来自客户端界面模块1中用户提交的作业请求；然后将作业请求进入作业队列进行等待；最后由作业调度与负载均衡子模块23从队列中取出作业请求，并调度到负载最小的工作流引擎上执行。监控子模块22主要负责对工作流引擎、复合服务、工作流作业实施监视和控制。它首先接收来自客户端界面模块1中用户提交的监视和控制请求，然后调用引擎管理器子模块24进行直接对某个工作流引擎、复合服务、工作流作业实施监视和控制。完成后，监控子模块22接收来自引擎管理器子模块24的监控结果，并将其返回给客户端界面模块1并展现给用户。其中，监视功能主要包括监视各个引擎的运行状态和负载；监视复合服务的运行状态；监视各个复合作业的执行状态，其状态主要设定为以下类型starting，running,suspended,destroyed,aborted,successful。控制功會g主要接收来白用户的控制信息，并实施控制操作。包括对各个引擎的重启(restart)，停止(shutdown);对复合服务的挂起(suspend)、销毁(destroy)、恢复(resume)等；对正在执行中的工作流作业执行启动(start)、挂起(suspend)、恢复(resume)、销毁(destroy)、中止(abort)等控制操作。作业调度与负载均衡子模块23负责对从作业队列子模块21中取工作流作业请求，并通过引擎管理器子模块24获取各个引擎当前实时的负载情况，动态地从工作流引擎261,262，…，26n选择负载最小的工作流引擎并将工作流作业分配给其进行执行。引擎管理器子模块24负责对工作流引擎261,262，…，26n进行管理。它接收来自作业调度与负载均衡子模块的23的引擎状态查询请求，并从信息中心子模快25中提取各引擎负载和状态信息，然后将其反馈给作业调度与负载均衡子模块的23，供其进行引擎选择和作业调度。而且，引擎管理器子模块24还接收来自监控子模块22的监控请求，然后按照要求对工作流引擎261，262，…，26n实施监视(查询状态信息)和控制(例如，重启、7停止、恢复等)，最后将监控的结果返回给监控子模块22。另外，引擎管理器子模块24还负责从客户端界面模块1下载作业输入文件和上传作业执行结果文件。信息中心子模块25为系统内众多工作流引擎服务提供信息注册、信息更新、信息注销。同时维护工作流引擎、服务(包括原子服务和复合服务)、作业的描述信息，监控信息，运行时状态信息。信息中心子模块25接收来自引擎管理器子模块24的(引擎、服务、作业)信息注册、更新，注销等，同时，它还支持引擎管理子模块24对所有这些状态信息的检索和查询。信息中心子模块25将所有的信息都记录在数据库27中。工作流引擎261,262，…，26n提供复合服务的运行时环境，包括复合服务定义解析、服务实例的创建和维护、在参与的原子服务之间消息传递、服务状态的监控和通知、容错和补偿、安全和信任机制等。在本系统中，我们使用了开源的BPEL引擎ActiveBPEL，并对其进行了功能扩展，使其能够支持WSRF服务和虚拟服务。工作流引擎261,262，…，26n接收来自作业调度与负载均衡子模块23的作业执行请求，然后执行。同时，作流引擎261，262，…，26n也接受引擎管理器子模块24的监控和管理。数据库27用来记录工作流引擎、复合服务的状态信息，工作流作业的执行过程中的中间数据和状态信息。数据库27响应来自信息中心子模块25最这些数据的保存、读取和更新操作。由于我们使用了分布式的工作流引擎架构，故工作流引擎的个数可以根据作业提交数量和整个系统的负载情况进行动态增加。扩展增加BPEL引擎后，必须通过擎管理器子模块24到信息中心子模块25进行引擎注册，这样作业调度与负载均衡子模块的23就可以从信息中心子模块24查询各个引擎之间实时的负载情况，动态地选择负载最小的工作流引擎261，262，…，26n执行此工作流作业。如图4所示，一个复合服务的部署需要经过以下几个步骤①定义复合服务。借助图形化的定义工具，高级用户根据流程逻辑使用BPEL语言定义具有工作流模式的复合服务，其最基本的工作流模式包括顺序、分支、循环、并发、同步、触发。定义后的结果是一个以bpr为后缀的包。②提交复合服务。将定义好的*.bpr包通过复合服务部署界面提交给本系统，系统接受并上传该包，以暂存在用户的虚拟空间中。③检查引擎状态。从信息中心中检查所有已经注册的引擎运行状态，若正常，执行步骤。若不正常，执行步骤⑧。④部署复合服务。将tbpr部署在运行正常的工作流引擎中。⑤检查服务状态。服务部署完成后，工作流引擎会自动加载该服务，将其加入到引擎的服务列表。若该服务运行正常，执行步骤⑥。若服务加载失败，运行步骤⑨。⑥注册服务到信息中心。服务运行正常，则将该复合服务的地址注册到信息中心，包括所属于的工作流引擎等描述信息。⑦复合服务处于运行状态，等待作业调用。⑧经检查，若工作流引擎运行不正常，则从信息中心中注销该引擎并通知错误信息到用户界面。⑨记录错误日志，并通知错误信息到用户界面。当一个复合服务已经部署在本系统的多个工作流引擎中，则用户提交一个复合作业，该复合作业的执行步骤如图5所示①提交复合作业及其QoS需求。普通用户通过作业提交界面提交复合作业及其QoS需求。其中QoS需求可以指执行该作业必须达到的性能指标，如内存，存储空间，CPU的个数，完成时间等；也可以是服务的品质，如价格，信用等级，安全策略等。②进入作业队列等待。用户提交的复合作业现进入系统的作业队列(2.1)等待执行。③动态服务选择。根据作业的QoS需求，进行动态选择能够满足该需求的复合服务。若找到能够满足该QoS的多个复合服务，在多个工作流引擎之间选择负载最小引擎的复合服务，执行步骤④。否则，执行步骤⑧。④提交作业到该服务，修改服务状态，同时该服务为工作流作业产生服务实例。⑤由服务实例执行该作业，修改信息中心中的作业状态。⑥检查作业状态，若作业执行结束，执行步骤⑦，否则，执行步骤⑤。⑦修改服务状态，销毁服务实例。执行步骤⑨。⑧记录日志并通知用户。执行步骤⑨。⑨作业执行结束。实例本系统ServiceFlow实例使用了一个集群服务器的6个节点来安装。其系统实例软硬件配置如表l所示。如表1所示，集群服务器的Nodel用来安装客户端界面模块1，Node2安装分布式工作流引擎模块2内的各个子模块，Node3用来安装服务动态选择代理模块3，Node4、Node5和Node6均用来安装了BPEL工作流引擎。表1系统实例软硬件配置表<table>tableseeoriginaldocumentpage9</column></row><table><table>tableseeoriginaldocumentpage10</column></row><table>权利要求一种面向服务的分布式工作流管理系统，包括用于支持服务实例存在的运行时环境的服务容器(4)，其特征在于该系统还包括客户端界面模块(1)、分布式工作流引擎模块(2)和服务动态选择代理模块(3)；客户端界面模块(1)用于为外界用户提供基于Web页面的交互接口，它接收来自用户的各种请求，并将其转交给分布式工作流引擎模块(2)进行处理，处理完毕后，接收处理结果，并展现给用户；分布式工作流引擎模块(2)接收来自客户端界面模块(1)的各种请求，处理后将结果返回给客户端界面模块(1)；分布式工作流引擎模块(2)在虚拟服务参与工作流执行时会调用动态服务选择代理模块(3)；分布式工作流引擎模块(2)还负责执行工作流作业，并按照流程把子任务调度物理服务上执行；动态服务选择代理模块(3)用于接收来自分布式工作流引擎模块(2)的服务选择请求，从属于同一虚拟服务的物理服务中选择具有最优服务质量的物理服务进行作业执行。2.根据权利要求1所述的面向服务的分布式工作流管理系统，其特征在于分布式工作流引擎模块(2)包括作业队列子模块(21)、监控子模块(22)、作业调度与负载均衡器子模块(23)、引擎管理器子模块(24)、信息中心子模块(25)、工作流引擎(261,262，…，26n)和数据库(27);作业队列子模块(21)用于支持复合作业请求进入作业队列，它首先接收来自客户端界面模块(1)中用户提交的作业请求；然后将作业请求进入作业队列进行等待；最后由作业调度与负载均衡子模块(23)从队列中取出作业请求，并调度到负载最小的工作流引擎上执行；监控子模块(22)负责对工作流引擎、复合服务、工作流作业实施监视和控制，它首先接收来自客户端界面模块(1)中用户提交的监视和控制请求，然后调用引擎管理器子模块(24)进行直接对某个工作流引擎、复合服务、工作流作业实施监视和控制；监控子模块(22)还接收来自引擎管理器子模块(24)的监控结果，并将其返回给客户端界面模块(1)并展现给用户；作业调度与负载均衡子模块(23)负责对从作业队列子模块(21)中取工作流作业请求，并通过引擎管理器子模块(24)获取各个引擎当前实时的负载情况，从工作流引擎(261,262，…，26n)选择负载最小的工作流引擎并将工作流作业分配给其进行执行；引擎管理器子模块(24)负责对工作流引擎(261,262，…，26n)进行管理，它接收来自作业调度与负载均衡子模块的(23)的引擎状态查询请求，并从信息中心子模快(25)中提取各引擎负载和状态信息，然后将其反馈给作业调度与负载均衡子模块的(23);引擎管理器子模块(24)还接收来自监控子模块(22)的监控请求，然后对工作流引擎(261，262，…，26n)实施监视和控制，最后将监控的结果返回给监控子模块(22);另外，引擎管理器子模块(24)还负责从客户端界面模块(1)下载作业输入文件和上传作业执行结果文件；信息中心子模块(25)为系统内各工作流引擎服务提供信息注册、信息更新、信息注销，同时维护工作流引擎、服务、作业的描述信息，监控信息，运行时状态信息；信息中心子模块(25)接收来自引擎管理器子模块(24)的信息注册、更新和注销；信息中心子模块(25)支持引擎管理子模块(24)对状态信息的检索和查询，信息中心子模块(25)将其信息记录在数据库(27)中;工作流引擎(261,262，…，26n)提供复合服务的运行时环境，接收来自作业调度与负载均衡子模块(23)的作业执行请求，并执行；工作流引擎(261,262，…，26n)还接受引擎管理器子模块(24)的监控和管理；数据库(27)用于记录工作流引擎、复合服务的状态信息，工作流作业的执行过程中的中间数据和状态信息；数据库(27)响应来自信息中心子模块(25)对这些数据的保存、读取和更新操作。全文摘要本发明公开了一种面向服务的分布式工作流管理系统，包括用于支持服务实例存在的运行时环境的服务容器、客户端界面模块、分布式工作流引擎模块和服务动态选择代理模块；客户端界面模块为用户提供基于Web页面的交互接口；分布式工作流引擎模块处理来自客户端界面模块的各种请求，负责执行工作流作业，并按照流程把子任务调度物理服务上执行；动态服务选择代理模块从属于同一虚拟服务的物理服务中选择具有最优服务质量的物理服务进行作业执行。本发明支持虚拟服务作为原子服务参与服务复合，选择具有最优服务质量的物理服务执行作业；支持WS/WSRF服务，基于QoS的动态服务选择实现了服务动态选择的最优化；采用分布式工作流引擎，实现了作业动态负载均衡。文档编号G06Q10/00GK101694709SQ20091027226公开日2010年4月14日申请日期2009年9月27日优先权日2009年9月27日发明者吴松,曹海军,羌卫中,赵峰,金海,陶永才,齐力申请人:华中科技大学;