毕业论文移动版

在这一章节，我们将会介绍BPEL程序依赖图PDG，中间表示一个BPEL的过程，与普通程序依赖图不同BPEL PDG图有更多的各种边缘活动的依赖关系。根据BPEL PDG，我们可以提出自己的服务方式已提供兼容性分析。

A. BPEL程序的依赖性

作为一个大的编程语言，比起交流BPEL更注重合作。例如，BPEL不仅提供活动进行计算，如<assign>活动，但还提供了一些通信活动等合作的<invoke> <receive>活动，流程作为其一等公民。

在编写小程序时，例如，C或Java程序，改变指令的顺序可能得到错误的结果，即危害的危险。这是因为改变执行订单指令违反控制或数据依赖关系之间的指令。在BPEL过程中，如果序列订单的通信活动的改变，一些危害如死锁可以引入互动危害当BPEL流程与合作伙伴交互时。同样地，那是因为改变顺序沟通活动违反了一些依赖之间的活动。这种依赖关系可能会影响相关活动之间的同步通信。在本节中，我们将介绍两种新颖的类型，特别是BPEL流程的依赖性。论文网

为了使本文便于理解，我们首先回顾下控制依赖和数据依赖的概念。

BPEL中的术语。一个活动Aj为控制依赖于前面的活动Ai，当且仅当结果Ai决定是否AJ可以执行[9 ] [18]。一般，Ai条件活动，如<if Ψ>，<while Ψ> ，其中Ψ代表谓词表达式。如果活动AJ是无法控制依赖任何条件活动，我们假设Aj为控制依赖于虚拟条目活动的BPEL流程。在BPEL进程P1在图1（a ） ，活动A1 〜 A3控制依赖于虚拟项目活动的P1 。

数据依赖性可以分为三类：真正的依赖（定义使用依赖），反依赖（use-def依赖）和输出依赖（def-def依赖）[9] ，[18 ]。由于过去两年的依赖性可以应避免通过变量命名数据依赖。

下面介绍的仅是指use-def依赖。一个活动AJ是数据依赖于前一个活动AI, 如果只有当AJ ，Ai定义之前使用一个变量。在BPEL流程P2活动A5是在图1（b ）所示，数据依赖于活动A4 ，因为A5采用变量airlineInput定义A4 。

除了控制和数据依赖关系，我们又提出了两个BPEL程序依赖性：异步调用依赖【21】和交互依赖【23】。首次提出了我们的异步调用依赖以前的工作是这种依赖关系所引起的异步通信机制的BPEL流程。让我们考虑这样一个场景：一个单向的<invoke>的活动，此后，再进行一个<receive>活动，这<receive>活动负责接收结果单向调用。有没有控制和数据这两种活动之间的依赖关系。但是，如果我们将两个活动的执行顺序反向，当BPEL流程与它进行交互时，它可以导致死锁。因此，这两个活动有某一种依赖关系被定义为如下【21】。通俗的说，<receive>活动AJ是异步调用，依赖于一个当且仅当AJ是单向前<invoke>活动Ai负责接收“响应”。图1（a ），活动在BPEL流程中的P1 ，A3是A2活性依赖于异步调用。

交互依赖是由于一个BPEL流程连续同步约束相同的合作伙伴BPEL流程交互引起的。让我们考虑这样一个场景：一个<receive>活动后跟一个<invoke>活动。有两种可能的情况如下：第一个可能的情况是，<receive>活动负责，用于接收一个单向伙伴BPEL流程<invoke>活动，同时<invoke>活动是单向和负责调用备份合作伙伴回复合作伙伴的调用，它可以是<receive>活动和单向的<invoke>的活动。例如，活动A9和A7活性的BPEL流程中的P3，图1（c ）有这种依赖。同样地，也是一个<receive>活动之间的依赖关系和<reply>活动，当<receive>活动负责用于接收的请求 - 响应调用一个合作伙伴BPEL流程和<reply>活动的负责回答的结果返回给伙伴BPEL流程。例如，活动的A6和活动A4在BPEL流程P2，图1（b ）有这种依赖。 (责任编辑：qin)