一个BPEL进程发生的故障可能是由许多原因引起的，如消息与端口的匹配不正确、数据格式错误、互联网连接问题等等。诊断的目标就是当进程抛出异常时快速、准确地找出故障活动并且指出故障发生的原因。
为了便于诊断模型的构建及诊断方法的执行，我们首先对可获得的诊断信息做出如下假设：
（1）BPEL进程规约文件是可获得的，且包含进程活动及输入、输出消息；
（2）进程的历史执行数据是可获得的，历史执行数据记录的是每次失败执行中所有执行的活动、抛出异常的活动及真正引起故障的活动；
（3）抛出异常的执行路径是可获得的，并且按顺序记录了执行的活动。
4.4.4.1 诊断模型
一个基于BPN进程模型的诊断模型定义了活动之间正常的依赖关系，通过分析这些依赖关系，找到违反这些给定依赖关系的活动，该诊断模型能够精确地定位进程故障并且解释故障发生的原因，如数据类型故障、误匹配故障等。
定义4.25 一个基于BPN模型的BPEL进程诊断模型表示为BDM=（BPN，OBS，D），其中：
(1)BPN=(ps，pe，P，T，F，W，V，OP)；
（2）OBS=（T′，V′，OP′）是一组观察集合；
（3）D={EQ，EQT，EQV，IN，CO}，其中EQ用于表示两个给定的操作是一样的，EQT表示两个给定的变量的类型是一样的，EQV表示两个给定的变量的值相等，IN表示一个输出参数是通过调用另一个服务所产生的，CO表示一个给定的表达式或条件表达式的计算结果。
对于基本活动的诊断模型被描述如下：
定义4.26 receive的诊断模型形式化定义为
如果进程模型中receive的操作与观察到的实际操作一样，定义的变量类型和与观察到的变量类型相同，并且receive活动接收的消息值与实际观察中变量的值相等，那么活动receive没有发生故障，否则其就是故障的活动。
定义4.27 reply的诊断模型形式化定义为
如果进程模型中reply的操作与观察到的实际操作一样，定义的变量类型与观察到的变量类型相同，并且reply活动接收的消息值与实际观察中变量输出的值相等，那么活动reply没有发生故障，否则其就是故障的活动。
定义4.28 invoke的诊断模型形式化定义为
如果进程模型中invoke的操作与观察到的实际操作一样，输入输出变量类型与实际观察到的变量类型相同，并且产生实际操作的服务是
.service，那么活动invoke是正常的，否则其就是故障的活动。
定义4.29 assign的诊断模型形式化定义为
如果进程模型中assign的输入输出变量类型与实际观察到的变量类型相同，且实际观察中的输入值与输出值相等，那么活动assign就是正常的，否则其就是故障活动。
定义4.30 wait诊断模型形式化定义为
如果进程模型中wait的条件表达式计算得到的值与实际观察到的值相等，那么该活动就是正常的，否则其就是故障活动。(www.xing528.com)
定义4.31 empty的诊断模型形式化定义为
如果实际观察到的empty的操作为空，那么该活动就是正常的，否则就是故障活动。
这里并没有定义活动throw的诊断模型，throw本身是用于抛出进程异常的，因此在正常的活动依赖关系中我们不将其考虑在内。
对于结构活动的诊断模型被描述如下：
定义4.32 sequence的诊断模型形式化定义如下，Di表示对sequence中第i个活动块的诊断。
如果sequence中的所有活动块都没有发生故障，则sequence活动正常，否则其就是故障的结构活动。
定义4.33 switch的诊断模型形式化定义如下，其中k表示switch选择第k个分支，Dk则表示对第k个分支中活动块的诊断。
如果前k-1个分支的条件都不被满足，而第k个分支的条件被满足且第k个分支中的活动块正常，那么switch活动是正常的，否则其就是故障的结构活动。
定义4.34 while的诊断模型形式化定义如下，其中k表示while的循环次数，ci表示第i次循环的循环条件的变化情况，Di表示第i次循环的活动块的变化情况。
如果前k次循环的循环条件都被满足，循环活动块都被诊断为正常，并且第k+1次循环的循环条件为否，那么该结构活动就是正常的，否则其就是故障的结构活动。
定义4.35 flow的诊断模型形式化定义如下，n表示flow中包含的并发活动块个数，Di表示flow中第i个并发活动块。
如果flow中的所有活动块都没有发生故障，则flow活动正常，否则其就是故障的结构活动。
定义4.36 pick的诊断模型形式化定义如下，k表示活动pick执行了第k个分支活动块，Dk表示对pick中的第k个活动块的诊断。
如果事件ek发生，且活动块Dk诊断正常，那么pick活动是正常的，否则其就是故障的结构活动。
4.4.4.2 诊断方法
应用上面给出的诊断模型，我们能够精确地诊断出每个活动是否是故障活动。然而，我们还需要考虑的是如何减少诊断的活动个数，以使得在异常发生时能够快速地定位故障，保证进程的正常执行。因此，当一个异常在进程执行期间发生时，我们首先使用BDM诊断模型对抛出异常的活动进行诊断。如果异常活动本身就是故障，那么将诊断结果发送给异常处理器，让其处理；如果异常活动是正常的，那么利用历史执行数据计算观察到的异常执行中每个活动的故障概率，然后选择概率最高的活动进行诊断，直到找到故障为止；如果所有的活动都被诊断完成且均是正常的，那么就通知异常处理器进程的输入信息可能是不正确的。
算法4.1 BDM（BPN，OBS，D）
输入：进程模型BPN，异常执行OBS，诊断模型D。
输出：诊断解DS。
根据给定的进程模型BPN和观察到的异常执行OBS，我们可以采用算法4.1来对进程进行诊断。这里给出根据历史数据计算活动故障概率的计算公式：
其中，
表示活动tf抛出了异常且活动t是故障的失败执行个数；而
表示活动tf抛出了异常的失败执行的个数，N表示失败执行的总数。在式4.1中，还需考虑循环结构中活动个数的计算方法。对于循环结构中的活动，无论它循环执行了多少次，在该次执行中这个活动的执行次数只记为1。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
