发明内容
鉴于现有方法的缺陷,本发明的目的在于提供一种基于分布式适配的服务协作方法以及支持该方法的实现系统,为参与协作的每个服务组件生成独立的适配器,并实现各个适配器的分布式部署和运行,从而更加满足开放网络环境对于高效、灵活的服务协作机制的需求,避免集中式的适配方法在运行效率、可伸缩性和可用性等方面存在的局限。
为实现上述的发明目的,基于分布式适配的服务协作方法包括了以下几个步骤:
步骤1:建立全局的服务协作流程,用以描述整体的协作流程,即参与协作的服务组件之间的交互过程,在协作流程中以角色来抽象地表示服务协作的参与者;
步骤2:基于角色实现了全局协作流程的投影方法,得到P2P的分布式服务协作流程,其中包含了各个角色所对应的抽象服务接口,每个抽象服务接口定义了相应的角色需要在协作中满足的行为约束;同时建立参与协作的实际服务的行为接口模型,该模型描述了实际服务组件所提供的操作,以及操作调用之间的逻辑时序关系;
步骤3:以步骤2所得到的抽象服务接口为标准,与对应的实际服务行为接口进行可适配的一致性检查;
步骤4:根据步骤3的结果,如果实际服务的行为接口满足可适配的一致性,为其自动构造适配器;如果实际服务的行为接口不满足可适配的一致性,则返回不可适配的交互路径信息,提供给协作开发者以实现有效的调整;
步骤5:将各个服务组件所对应的适配器转换成相应的实现形式(Java类或者BPEL流程),并封装为Web服务,从而可以分布式地部署在与实际服务相同的执行环境中,使得适配器作为服务的Wrapper,基于其协调作用来实现正确的服务协作流程。
其中,步骤1具体还包括以下步骤:
1)首先建模服务组件之间的全局协作流程,其中每个活动表示角色之间的消息交互事件,活动之间的控制流则描述了角色之间的控制传递;
2)本发明以CSP形式化方法为基础,来验证投影算法的正确性以及服务的可适配一致性,因此需要将流程模型转换为CSP形式化语言描述的结构。
这里我们所用到的CSP的操作符包括:
前缀(prefix):设有一活动为a,有一进程为P,则执行活动a,然后按照进程P的描述来执行,用a→P表示;
循环(recursive):若F(X)是一包含了名称X的有前缀的流程描述,则μX·F(X)给出了循环执行流程X的定义;
外部确定性选择(external deterministic choice):一个流程可以按照进程P的描述执行,也可以按照Q的描述执行,其选择由外部环境决定,则表示为:P□Q;
内部非确定性选择(internal non-deterministic choice):一个流程可以按照进程P的描述执行,也可以按照Q的描述执行,其选择由流程自身决定,则表示为
顺序(sequence):P;Q表示流程首先按照进程P的描述执行,如果成功,则继续按照Q的描述执行;
并发(parallel):P‖Q表示通常的并行操作,进程P和Q将基于符号表中的相同事件进行同步,即进程P和Q在事件集αP∩αQ上同步;
另外,CSP中还定义了两种特殊进程:STOP与SKIP,其中STOP表示流程死锁,SKIP表示流程执行成功。
全局协作流程的每个原子活动表示了两个角色之间的一次消息交换,那么采用CSP形式化语言来描述即为:m(rs,rd)。表示消息m由角色rs发送到角色rd。
所述步骤2还包括以下步骤:
建立实际服务行为接口的形式化描述模型,在实际应用中,通常可以采用抽象WS-BPEL流程描述来描述实际服务的行为,因此这里我们给出了WS-BPEL与CSP形式化语言的模型结构的转换方法,如表1:
表1WS-BPEL的CSP转换方法
这里我们用!x表示消息发送活动,而?x则用来描述消息接收活动。针对WS-BPEL中的结构活动sequence,flow,pick,switch以及while,则分别转换为CSP语言中对应的顺序,并发,确定性选择,非确定性选择以及循环结构。
所述步骤3还进一步包括下列步骤:
1)建立抽象服务接口与实际服务行为接口之间的消息映射模型,即如何实现抽象服务接口与实际服务接口所定义的消息之间的相互转换;
2)基于消息映射模型构造抽象服务接口与实际服务接口之间的适配模型;
3)对得到的适配模型进行死锁检查,以确定对应的实际服务是否存在正确的适配器,使其满足协作流程的需求。
为实现本发明目的,还提供了一种基于分布式适配的服务协作系统,其主要模块按照功能分为三个层次:
协作流程层次:主要包括了协作流程建模工具,CSP映射转换模块以及协作流程投影模块。其中,协作流程建模工具采用图形化的方式建立服务协作流程,用于可视化建模和展示;CSP映射转换模块则将图形化的流程模型转换为CSP表示的模型结构;协作流程投影工具则基于协作角色将全局的协作流程进行投影,得到各个实际服务所对应的抽象服务接口。
适配管理层次:包含三个子模块,分别为服务管理模块,映射模型管理模块以及适配器管理模块。其中,服务管理模块中的协作服务管理器负责参与协作的服务组件的组织与管理,并通过服务接口CSP转换工具将服务组件的行为接口转换为CSP描述模型;映射模型管理模块中包括映射模型管理器、消息映射编辑器以及映射模型构造模块。映射模型管理器负责抽取抽象服务接口以及实际服务接口中的消息,提供给消息映射编辑器,并将消息映射的结果提交给适配器管理模块以进行一致性检查以及适配器的构造。消息映射编辑器通过可视化的界面使得开发者可以方便地编辑消息之间的依赖映射关系,而映射模型构造模块负责映射模型的生成,管理及其持久化存储;适配器管理模块包括了一致性检查模块,适配器生成模块以及适配器管理器。其中一致性检查模块以抽象服务接口,服务的实际接口以及消息映射模型为输入,判断对应的实际服务是否存在有效的适配器;适配器生成模块则依据一致性检查的结果生成适配器,并转换成相应的实现形式(本发明将适配器转换为可执行WS-BPEL流程的形式);适配器管理器则负责适配器分布式部署及其管理;
协作运行层次:协作运行层分布式地位于各个服务提供者的位置,为适配器提供运行支撑环境。其中协作代理负责与适配器管理器进行通信,接收并部署适配器到相应的执行引擎;适配器执行引擎则实现适配器实例的解释与执行。
本发明提出一种基于分布式适配实现服务协作的方法及相应的支撑实现系统,和现有的方法相比,本发明的技术效果是,通过为每个服务组件分别实现适配器,进一步降低了实际服务与协作环境的耦合关系,使得在不改变源服务组件实现的前提下满足应用协作要求,从而提高了服务组件的可复用性以及协作成功率。而且在协作目标或者单个服务组件发生变化时,只需重新配置适配器就可以再次实现有效的协作,从而降低了系统更新的代价。而且采用了分布式的适配方式,避免了集中式适配方式所带来的通信开销,提高了系统的可伸缩性;取消了集中式适配器的控制中心和数据路由中心,将适配器的执行分布到服务组件所在的各个结点,并在结点之间直接交换数据,从而减少了适配器结点成为系统重载结点的可能,提高了服务协作系统的数据传输效率。在大并发访问量、大数据传输量以及网络带宽受限的应用中,采用基于分布式的适配机制将是更好的选择。因此,本发明所提供的方法在保持了服务组件自治特性的同时,提高了企业间服务协作的灵活性。
具体实施方式
以下结合具体实施例和附图对本发明作更详细的说明。
图1给出了基于分布式适配的服务协作方法示意图。本方法中所涉及的主要元素包括有协作流程模型,抽象服务接口,实际服务接口以及服务适配器等等。
图2给出了本发明的服务协作支撑系统的总体架构图,包含了协作流程层,适配管理层以及协作运行层三个层次。
首先依据协作需求,通过协作流程建模工具,建立服务之间的交互协作流程,从全局角度描述参与协作的服务之间的公共交互消息和协作契约关系。本发明所实现的建模工具采用了基于Eclipse的插件开发技术,整体采用MVC(Model-View-Control)的架构,通过继承和实现框架类完成。如图3所示,类似于业务流程建模标注规范BPMN(参见文献:http://www.bpmn.org/,BPMN1.0,OMG Final Adopted Specification,February 6,2006),协作流程建模工具以泳池(pool)的概念来描述一个协作流程,而参与的角色通过泳道(lane)的概念来进行划分。图形化流程中的每个活动表示一个消息交互事件,活动所属的泳道作为消息的发送者,而通过活动的接收角色(receiver)属性来选择设置相应的消息接收者。消息的具体内容则通过泳池的消息列表(message list)属性来设置。可以看出,协作流程主要描述了服务之间的消息交互活动以及这些活动之间的时序逻辑关系。
接下来需要将服务协作流程投影到各个参与角色,得到各个角色的抽象服务接口集合。这些抽象服务接口的交互则构成了P2P形式的分布式协作流程。为了保证投影前后流程的正确性与一致性,本发明首先将协作流程建模工具所得到的协作流程转换为CSP形式化语言的模型结构,然后再执行投影算法。首先对CSP描述流程的模型结构进行面向对象建模,图4给出了主要类结构的示意图。其中ProcessObject是根类,所有流程相关的类都继承于ProcessObject。ProcessObject包括三种子类,分别是Process,Swimlane和LaneObject。其中Process用来描述整个流程的相关属性,包括消息列表(message list)用以定义整个协作流程中角色之间交互的消息;Swimlane的子类则包括Pool和Lane,Pool用以描述一个具体的协作场景,而Lane用以表示协作中的各个角色;LaneObject则用以定义流程中的元素,其子类包括有ConnectionObject和FlowObject,分别用来描述流程中的连接和基本活动。SequenceFlow继承于ConnectionObject,用来建模流程中的连接线,描述活动之间的时序逻辑关系。FlowObject则包含了Activity(活动),Event(事件)和Gateway(网关)三个子类。其中Activity的子类ServiceTask用来建模具体的消息交互活动,其属性包括活动标识(ID),活动名称(Name),消息(Message),消息的发送角色(Lane)以及消息的接收角色(Receiver Lane)等等;Event的子类StartEvent和EndEvent则分别用来描述流程的起始点和结束点;GateWay则用来描述流程的分支,其子类分为ParallelGateWay(并发网关)和ExclusiveGateWay(选择网关),分别用来建模并发分支以及选择分支。具体的转换过程由协作流程层的CSP转换工具实现,转换后得到的CSP描述的协作流程通过协作流程投影工具的作用,转换为各个角色的抽象服务接口的集合,协作流程投影工具主要依据表2所示的投影方法来实现流程的转换:
表2全局协作流程投影方法
投影方法包含原子活动和复杂活动两类。
方法2.1用来实现原子活动的投影,方法如下:对于活动m(rs,rd),如果当前角色为发送角色rs,那么投影后的活动为消息发送活动!m(rs,rd);如果当前角色为接收角色rd,则投影后的活动为消息接收活动?m(rs,rd);对于其他角色,活动m(rs,rd)投影后为SKIP。
方法2.2给出了顺序活动的投影方法:对于顺序流程P;Q,Head(Q)={rj|1≤j≤n},是流程Q中所有起始活动的消息发送角色的集合;Tail(P)={ri|1≤i≤l},则包括了流程P中所有结束活动的消息接收角色。如果当前角色属于集合Tail(P),那么需要增加相应的顺序同步流程‖j≤n!msyn(r,rj),即当前角色发送同步消息msyn到Head(Q)中的每个角色;如果当前角色属于集合Head(Q),那么需要增加相应的顺序同步流程‖i≤l?msyn(ri,r),即当前角色从Tail(P)中的每个角色接收同步消息msyn;从而保证了分布式协作流程中的顺序一致性。
方法2.3给出前缀活动的投影方法,前缀活动属于顺序流程的特例,因此其投影方法同方法2.2一致。
方法2.4对于并发活动P‖Q的投影方法:分别对流程P和Q进行投影,然后再以并发操作符连接投影后的流程即可。
方法2.5是选择活动的投影方法。对于协作流程中的选择操作符,我们要求参与协作的一个角色拥有决策权。假设选择决策角色为r0,而{ri|ri≠r0∧1≤i≤n}则为所有在流程P或Q中具有相关发送或接收活动的角色,那么需要构造相应的同步选择消息mP和mQ,并从r0发送到每一个ri,用来通知角色r0所选择的分支,从而保证分布式协作流程中的选择一致性。
方法2.6为具有选择结构的循环活动投影方法,其只需对循环结构内的选择活动进行投影即可。
得到各个角色对应的CSP描述的抽象接口之后,为了判断实际服务接口的一致性,首先通过协作服务管理器获取实际服务的接口描述,包括WSDL描述的操作接口,以及抽象WS-BPEL描述的行为接口,然后通过服务接口CSP转换工具,将行为接口转换为CSP描述的形式化模型结构。这里的CSP转换工具主要依据表1中给出的转换方法,实现相应的转换算法。然后以抽象接口与实际接口的CSP描述模型为基础,建立实际服务与对应角色之间的适配模型,以进行可适配一致性的检查。
适配模型的构造示意图如图5所示,分为以下三个步骤:
1)首先抽取抽象接口与实际服务接口中的消息,并且建立消息之间的数据依赖关系,即一方所需要接收的消息如何通过另一方的发送消息来构造。通过映射管理模块的消息映射编辑器,本发明所述的系统通过可视化的方式描述消息之间的映射关系,消息映射编辑器如图6所示,界面左半部分给出了一方接口的所有接收消息以及消息的具体格式的描述,界面的右上部分给出了当前接收消息所依赖的另一方接口的发送消息,而右下部分则用来输入消息之间具体的映射转换关系,主要基于XPath语言来实现。
2)然后根据消息依赖关系为每个接收消息建模对应的消息管道,其CSP描述为:
Pipe_mr=[(‖i≤nleft?msi)→synth→right!mr→SKIP]□[close→SKIP]
这里mr是当前的接收消息,msi∈MS,MS是mr所依赖的发送消息的集合,n是mr所依赖的发送消息的数目。消息管道通过left信道接收消息,并通过其right信道发送消息。Synth则是消息映射中转换关系的相应实现。
3)最后依据抽象接口和实际服务接口的CSP描述模型构造异步交互流程,其方法为:
(a)对于接口描述中的每个发送消息m,若m在数据映射中有相应的映射关系定义,则将相应活动改写为对消息管道的写入活动(‖i≤nPipe_mi.left!m),Pipe_mi是依赖于m的接收消息所对应的消息管道,否则将相应的活动改写为SKIP;
(b)对于接口描述中的每个接收消息m,若m在数据映射中有相应的映射关系定义,则将相应的活动改写为对消息管道的读出活动Pipe_m.right?m,否则将相应的活动改写为STOP。
最后得到的适配模型的CSP描述为:(‖i≤nPipe_mi)//[PAI‖PSI],其中‖i≤nPipe_mi为所有的消息管道的集合,PAI和PSI则分别对应了抽象接口和实际服务接口转换得到的异步交互流程。
在得到实际服务接口对应的适配模型之后,本发明通过以下的算法来验证实际服务的可适配一致性:
输入:适配模型(‖i≤nPipe_mi)//[PAI‖PSI]
输出:对应的实际服务是否满足可适配一致性
Procedure boolean adaptableConsistency
(1)预处理:将异步交互流程中的P
AI和P
SI分别转换成等价的非确定性选择的标准形式
(1.1)if活动为形式,转换为
else if活动为形式,转换为
end if
(1.2)PAI转换后得到的分支子流程PAI1,PAI2,...PAIm集合存入列表AIList,同样PSI的分支子流程PSI1,PSI2,...PSin存入列表SIList。
(2)for each pi in AIList,
for each pj in SIList,
while(true)do
result_pi←move(pi),result_pj←move(pj);
if(result_pi=STOP∨result_pj=STOP)return false;end if
if(result_pi=NoMove∧result_pj=NoMove)return false;end if
if(result_pi=SKIP∧result_pj=SKIP)break;end if
end while
end for
end for
return true;
end Procedure
步骤(1)的预处理部分将流程分解为非确定性选择符
连接的分支子流程集合,从而简化了非确定性选择分支的处理,每个分支子流程代表了协作的一条交互路径。步骤(2)对抽象接口与实际服务接口的每条交互路径进行两两的死锁检查,如果所有的交互路径都不存在死锁,那么实际服务就满足可适配一致性的条件。其中调用的算法move,用来检查交互流程各个活动。算法move遍历流程的各个原子活动,并返回当前的检查结果,包括四种类型:SKIP,STOP,NoMove和Move。如果当前流程可以成功执行完,则返回SKIP;如果存在STOP活动,则返回结果STOP。如果不存在可执行的活动,则返回NoMove;或者存在可执行的活动,则返回结果Move。同时每次执行Move算法后将可执行活动的状态标记为已检查。算法中的函数canReceive和canSend分别用来检查相应的消息通道的状态是否可以写入数据,以及是否可以读取数据。其算法描述如下:
输入:待检查的流程p
输出:当前的检查结果result
Procedure result move
(1)if p是顺序活(顺序运算符‘;’连接各个子流程)
for(i:=n;i>0;i--)do
qi:=subSequentialProcess(p,i);
if qi未标记
result←move(qi)
if(result=SKIP)hasMoved:=true,mark(qi);
else if(result=STOP)return STOP;
else if(hasMoved=true∨result=Move)return Move;
else return NoMove;
end if
end if
end for
return SKIP;
(2)else if p是并发活动
for(i:=n;i>0;i--)do
qi:=subParallelProcess(p,i);
if qi未标记
result_i←move(qi);
if(result_i=SKIP)mark(qi);end if
else result_i:=SKIP;
end if
end for
if存在一个result_i=STOP return STOP;
else if存在一个result_i=Move return Move;
else if所有result_i=SKIP return SKIP;
else return NoMove;
end if
(3)else if p是外部选择活动
if存在子流程qi有isChoosed(qi)=true,return move(qi)
else return NoMove;
end if
(4)else if p是形如a1→a2→...→an的结构
for(i:=n;i>0;i--)do
ai:=subActivity(p,i);
if ai未标记
(4.1)if ai是发送活动
if canSend(ai)hasMoved:=true,mark(ai);
else if(hasMoved=true)return Move;
else return NoMove;
end if
(4.2)else if ai是接收活动
if canReceive(ai)hasMoved:=true,mark(ai);
else if(hasMoved=true)return Move;
else return NoMove;
end if
(4.3)else if ai=STOP return STOP;
end if
end if
end for
return SKIP;
end if
end Procedure
当可适配一致性的检查结果为false时,说明即使采用适配技术,服务组件也无法满足协作需求。所有无法适配的路径以及对应的活动节点会可视化地提供给开发者,作为调整服务协作需求的参考,从而更加有效地利用了检查算法的结果。通常存在两类无法适配的情况:
(1)接收活动所对应的消息m,不存在相应的数据映射关系;
(2)存在消息的循环依赖,从而无法进行适配。
对应于第一类情况,开发者需要进一步确认给定的接收消息m是否可以通过以下方式构造:(i)消息m是常量或者空值;(ii)消息m可以由先前接收到的消息来构造。而对于第二种情况,则开发者需要确认是否可以调整协作流程中消息交互的顺序,从而避免造成无法适配的情况。
当可适配一致性的检查结果为true时,适配器生成工具依据适配模型生成适配器的CSP描述。适配器的生成方法的主要思路在于,为异步交互流程的每个活动构造相应的消息发送或者接收活动:
(1)如果异步交互流程中的活动为写入活动(‖i≤nPipe_mi.left!m),则构造相应的消息接收活动?m,并用前缀连接符‘→’连接活动,结果为:?m→(‖i≤nPipe_mi.left!m);
(2)如果异步交互流程中的活动为读出活动(Pipe_m.right?m),则构造相应的消息发送活动!m,并用前缀连接符‘→’连接活动,结果为:Pipe_m.right?m→!m;
构造的消息发送或者接收活动主要实现了与实际服务或是其他适配器的消息交换,从而实现行为适配;而异步交换流程以及消息管道则主要实现消息缓存、抽取、转换以及协调消息交互顺序的作用,其结构示意图如图7所示。
考虑到实际应用中通常采用WS-BPEL作为服务流程的实现语言,本发明将CSP描述的适配器结构转换为WS-BPEL描述的流程模型,通过适配器生成工具实现这一功能,其转换方法如下:
(1)行为适配流程:与对应实际服务以及与其他适配器的交互部分,分别实现为flow结构的两个并发子流程;并根据定义中的结构化信息生成相应的flow,sequence等结构;
(2)具体的消息发送与接收活动:根据实际服务行为接口的具体描述信息,分别实现为receive,reply,invoke或pick等活动;
(3)消息管道中的数据存储:对于流程中的每个消息,采用WS-BPEL中的Variable元素来表示,并以此来实现具体消息内容的保存与更新;
(4)消息管道中的转换活动:对于消息管道中的映射转换,则采用WS-BPEL中的Assign活动来实现,并通过其copy和to元素来描述具体的转换方法;
(5)消息转换活动实现为单独的并发子流程,具体的消息转换与行为适配流程之间的同步关系通过WS-BPEL语言中的link活动来实现,从而保证在接收消息之后,以及发送消息之前完成相应的消息转换。
最终生成适配器的WS-BPEL描述文件,并通过各个服务提供者的协作代理模块,部署到各个适配器执行引擎。那么在运行时,适配器通过与相对应的实际服务交互来进行应用数据的交换,而协作流程则通过适配器之间的分布式交互来实现,其运行时的交互协作模型如图8所示。从而通过分布式适配器的应用,在保持服务协作灵活性的前提下,提高了服务组件的可重用性。