第二个可能的情况是, <receive>活动是负责接收前一个单向调用合作伙伴BPEL流程的结果,同时同一个伙伴是另一个调用<invoke>活动,BPEL流程。在这种情况下,如果<receive>活动和的<invoke>的活动之间的顺序被逆转,BPEL流程的行为可能会改变,并可能导致死锁。
值得注意的是,请求 - 响应<invoke>活动由一个单向的<invoke>的活动模拟和<receive>活动,负责接收结果的单向的<invoke> 。牢记这一点,总结上述所有的交互依赖的情况。我们定义AJ的活动是互动依赖当且仅当在前面的活动Ai爱是一个<receive>的活动或请求响应的<invoke>的活动和Aj是一个<invoke>活动(单向或请求 - 响应)或<reply>活动。
请注意, BPEL还提供一流的公民元素的<link>来表示同步依赖<flow>活动的两个活动之间的不同分支的结构。在本文中,这些依赖关系被视为一种特殊的相互作用依赖。
B.相关性分析和BPEL程序依赖图形
让我们讨论如何来识别所有的BPEL程序在BPEL过程中的依赖关系。控制相关支配后的分析的基础上,通过以下方式获得BPEL控制流图( CFG ) [9], [18]。在完善的数据基础上,可以得到一个BPEL流程依赖性[9] [14] [16]。文献综述
作为一流的BPEL规范, <LINK>的公民元素代表直接同步依赖。因此,介绍了同步的依赖性<LINK> [ 3 ]可以方便地免费获得。像控制依赖分析,异步调用。
在BPEL的依赖性和互动的依赖性遍历BPEL CFG过程中也可以通过以下方式获得。
然而,分析异步调用的程序和有些技术交互的依赖性,即,需要得到BPEL和WSDL一些语法细节。出于这个原因,我们假设读者是熟悉BPEL和WSDL 。对于异步调用和互动的关系分析,属性的partnerLink “ , ”端口类型“ ,和”运行“通信活动是必不可少的[3]。为此,相关联的这些属性与相应的活动节点在BPEL CFG 。
让我们先来讨论如何确定异步调用在BPEL CFG的依赖性。 <receive>活动来AJ如果异步调用依赖于一个<invoke>活动Ai,符合下列条件:(1) AJ可达Ai的BPEL CFG 。 (2) Ai和Aj共享相同的“的partnerLink“ partnerLinkType的”, “ portType的” s的两个活动分别在两个“角色” s的声明“ partnerLinkType的” 。
有几种情况进行交互的依赖性BPEL流程。在下面,我们讨论如何识别它们个案。请求响应的<invoke>的活动AJ是交互依赖于另一项活动AI如果满足以下条件:(1) AJ可达Ai在BPEL CFG 。 (2) Ai和Aj共享相同的partnerLink “和”端口类型“ ,但有不同“操作”S 。 AJ是互动的单向<invoke>活动依赖于一个<receive>或请求 - 响应的<invoke>的活动Ai,或请求 - 响应<invoke>活动AJ互动依赖上<receive>活动Ai如果符合下列条件:(1) AJ可达Ai的BPEL CFG 。( 2 )Ai和AJ有不同的“的partnerLink ” 但是这两个的partnerLink “是指相同的WSDL ,即,两个“的partnerLink ”分别对应两个操作。源:自~751·论`文'网·www.751com.cn/
所有的这些识别程序的依赖关系(即,控制依赖关系,数据依赖性,异步调用依赖关系和交互的依赖性) ,可以被捕获到一个BPEL程序依赖图( PDG BPEL中短) [18] , [21 ]。
定义1 。 ( BPEL程序依赖图, BPEL PDG )一个BPEL程序依赖图是一个有向的图<N, E> ,其中
·N是一组节点。有一个虚拟的入口节点在N,而其他节点表示实际活动报表的谓词表达式。
·E