第二个可能的情况是， <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 ”分别对应两个操作。源:自~优尔·论`文'网·www.youerw.com/

所有的这些识别程序的依赖关系（即，控制依赖关系，数据依赖性，异步调用依赖关系和交互的依赖性） ，可以被捕获到一个BPEL程序依赖图（ PDG BPEL中短） [18] ， [21 ]。

定义1 。 （ BPEL程序依赖图， BPEL PDG ）一个BPEL程序依赖图是一个有向的图<N, E> ，其中

·N是一组节点。有一个虚拟的入口节点在N，而其他节点表示实际活动报表的谓词表达式。

·E