支持LRT的失败恢复算法及其事务性质分析

梅晓勇，黄昌勤，郑小林，陈德人，李师贤

（1. 中山大学 信息科学与技术学院，广东 广州 510006；2. 浙江大学 计算机科学与技术学院，浙江 杭州 310027）

1 引言

组合后长运行事务 LRT(long running transactions)运行的长效性(可能持续几小时、几个月甚至更长)，这为 LRT的事务处理带来难度。传统的ACID(atomicity, consistency, isolation, durability)机制过于严格，不再适用于LRT，需要放宽隔离性，松弛资源持有条件，确保可靠LRT执行。因此，在组合事务环境下，把 Relaxed-ACID事务属性应用到LRT是非常有必要的。

文献[1]和文献[2]提出了基于容忍嵌套的 LRT失败执行框架，探讨自动处理容错和失败处理策略。文献[3]提出了组合Web事务的失效恢复算法。文献[4]借助自适应执行上下文，提出一种新的基于语义的动态恢复机制。文献[5]提出了一种基于语义的 Web事务协议。文献[6]提出了一种灵活的确保可靠面向服务事务的方法，确保控制流和事务模式的高内聚。文献[7]提出一种支持业务流程的向后恢复补偿方法，其将补偿逻辑和失败依赖作为协调逻辑的一部分。虽然这种方法解决了回滚问题，但有2个主要缺点：第一，多数情况下只能完成半自适应；第二，这些类型的工作流需要非常严格的流程定义。

目前支持事务机制的组合Web服务环境只提供有限的补偿能力，引入向后恢复确保事务的一致性。文献[8]通过扩展事务协调架构和基础设施，提出一种基于向前恢复策略的高级补偿环境。文献[9]提出一种基于规则的工程补偿方法。文献[10]提出了一种支持用户指定失败处理的Web服务组合框架。文献[11]给出了一个基于Java的事务性组合服务JTWS的API框架。为了保证 LRT执行语义的准确性，要么正常结束, 包括借助替换恢复或向前恢复策略使流程继续，要么通过执行向后恢复策略撤销已经提交的执行结果。面临如下两方面问题：① LRT执行时可能消耗大量资源，不一定对所有已提交任务逆向补偿，并最终回滚到到初始状态；② 中止整个 LRT需要很大代价，一种折中的恢复机制是先向后退到一个点，然后用替代任务或修复失败继续正向执行。引入灵活的 LRT的恢复策略，有如下优势：① 重试失败任务或选择等价替代任务有助于LRT重新获得成功；② 比尝试“修补”失败任务更有效；③ 有利于预测长事务执行状态，而不会导致长时间占用资源。综上所述，有必要进一步研究基于 LRT灵活的事务恢复策略。

2 基于Petri网的任务形式化

首先给出了基于Petri的原子任务形式化定义。

定义1 原子任务I的三元组表示为(P,T,F)。

1)P=Ps∪Pio∪Pqos∪Pc，其中，Ps指I的状态库所{Ready,Activated,Failed,Running,Aborted,Cancelled,Committed,Compensated,Half_Compensated} ;Pio指I的I/O库所集，通常描述Web服务的功能参数；Pqos指描述I的非功能参数；Pc描述I的信号库所。对于I，分别用I.ps,I.pio,I.pc和I.pqos来描述I的状态、功能、信号和非功能参数。

2)T=Tn∪Tb∪τ，其中，Tn指I正向事件集{Activate( ),Run( ),Fail( ) ,Abort(),Cancel(),Commit( ) }；Tb指I反向事件集{Compensate( ),Hcompensate(),Retry()}；τ∈T为空操作。为简化描述，正向事件Activate(),Run(),Fail(),Abort(),Commit(),Cancel()分别简记为tact,trun,tfal,tabt,tcmt,tcnl；反向事件Retry( )和Compensate( )分别简记为trty和tcmp。对于任务I，用I.t获取I的执行事件。

3)F= (P×T) ∪ (T×P)分别描述P到T或T到P控制流和数据流的有向弧集合。事件/状态对 (t1,p1)和 (t2,p2)间有如下约束：① 偏序关系 (t1,p1)≺ (t2,p2)；② 排斥关系 (t1,p1) ◁ ▷ (t2,p2)；③ (t1,p1)≈ (t2,p2)描述动作t1和t2同时发生或都不发生。

每个原子服务都有独特的事务行为，依据功能语义将分为 4类：枢轴(pivot)服务(记为WSp)、可补偿(Compensable)服务(记为WSc)、可重试(R etriable )服务(记为WSr)和关键(Vital)服务(记为WSv)。对于任务I，其事务类型记为I.TBP，其中，I.TBP∈{Pivot,Vital,Retriable,Compensable}。

WSp指Ip既不可重试，也不可补偿，如图1(a)所示。WSc是当Ic成功提交后，通过执行其补偿任务来消除产生的影响，如图1(b)所示。WSr指Ir执行失败，有限次重试后，确保Ir成功提交，如图1(c)所示。WSv指Iv具备重试和补偿的能力，如图1(d)所示。表1给出了任务执行状态和变迁含义，运行时任务可能转移到就绪(p0)、运行(p1)、提交(p2)、中止(p4)、取消(p6)、失败(p7)和补偿(p9)状态之一，触发Activate()、Run()、Fail()、Abort()、Cancel()或Commit()等内部或外部动作。

图1 原子任务形式化

表1 事务属性的变迁和库所

3 恢复范围及恢复契约

LRT流程的可靠性和一致性问题变得尤为突出，有必要提出一种可靠的失败恢复算法。目前，现有规范大多涉及补偿算法，且补偿算法定义在范围(BPEL4WS)或上下文(WSCI)或编排(WS-CDL)中。本文扩展BPEL4WS范围，扩展后范围由静态指定改为动态计算，恢复范围相对固定，缺乏灵活性。

3.1 恢复范围

考虑不同恢复需求，为不同恢复策略灵活地定义恢复范围Ξ。况且流程设计师为失败类型的失败恢复确定Ξ，也是一件非常困难的事情。本文给出的解决方法是依据恢复规格说明动态计算Ξ。

对于给定 LRT，执行迹σ，如果∃σ∀Ii,Ij∈σ∧Ii.TBP,Ij.TBP{Co∈mpensable,Vital}，Ii和Ij之间存在依赖之一，且Ii和Ij均是可补偿的，则σ是可补偿的，记为σ.Compensated。若LRT中每个任务都是可补偿的，且与失败任务存在依赖的任务都能确保成功补偿，则该LRT是可补偿的。

LRT执行失败，确定终止依赖点(TDP, terminate dependency point)非常关键，恢复处理器(RH, recovery handler)启动恢复策略(RHS, recovery handling strategy)，对Ξ中所有任务执行恢复，直到TDP。对于给定σ，如果∃σ∀Ii，Ij∈σ∧Ii.TBP,Ij.TBP∈ {Vital,Compensable}，Ii和Ij之间存在数据流依赖或称Ii是Ij的 TDP，如图 2所示。若Ij失败，从依赖点Ii开始对σm(σm∈σ)执行恢复，称σm为Ij的依赖路径。

对于给定 LRT，Ij(Ij∈σ)失败，计算Ij的依赖路径集{σm1,σm2,…,σmk}，回滚到Ii并注入修正参数，正向执行σm直到LRT成功执行。考虑恢复代价，对{σm1,σm2,…,σmk}的恢复范围集{Ξ1,Ξ2,…,Ξk}，优先选取恢复范围小的Ξ执行恢复。

图2 确定失败任务的恢复范围

范围嵌套类似于聚合模式嵌套，如图3所示，Ξ[1] ╞Ξ[1][2]指Ξ[1][2]是Ξ[1]的子范围，括号中数字表明嵌套层次。Ξ[1]╞ …╞Ξ[1]…[i]…[m]表示Ξ包含m个嵌套层，其中，每个嵌套子范围可能包含零个或多个任务。RH启动Ξ中预定义的 RHS，用二元组(Failtype,Action)i描述Ξ中失败任务I启动第i个事务失败处理策略rhsi，其中，Failtype为不同失败触发类型，Action为失败处理事件。Failtype又可分为简单失败(记为Fail(Sname))和组合失败(记为Fail(Sname1)∧Fail(Sname2)∧…∧Fail(Snamen))。Action描述触发事件定义的失败处理操作，其又可分为原子操作和组合操作，前者指单一替代或补偿操作，后者指聚合算子连接的多个原子行为。

通常，Ξ与RHS集(rhs1,rhs2,…,rhsn)(rhsi≠rhsj,i≠j)相关联。例如，TRP中Ξ有2个恢复策略rhs1=(Fail(ReserveAirline_Tickets),Compensate(UndoAirline Tickets))和rhs2=(Fail(CarRenting),Alter(BusRenting))，其中，当ReserveAirline Tickets失败，执行补偿，撤销预订机票；而CarRenting失败，调用替代恢复BusRenting执行巴士租赁服务。

3.2 恢复契约

局部依赖伴随于任务间交互，全局依赖往往存在时序和条件约束。LRT中任务间前后执行时序采用事件约束描述：σ1▷e▷σ2,σ1▷e和e▷σ2，其中，事件e{∈Activate(),Run(),Fail(),Abort(),Cancel(),Retry(),Compensate,Hcompensate(),Commit()}，σ1▷e▷σ2使得e一定发生，记为∇e；而σ1▷﹁e▷σ2则禁止e发生，记为﹁∇e。扩展后的串行约束σ1▷(e1,…,en)▷σ2记为∇(e1,…,en)，等价于∇e1⊕ …⊕ ∇en，表明事件e1,…,en均发生。

为了更好地采用Petri网描述恢复契约，引入扩展谓词逻辑CTR，除了,,∨∧﹁,∀和∃等算子外，还包括连接算子(⊕和|)和模态算子⊙。∇e1⊕∇e2指先后执行e1和e2；∇e1||∇e2指e1和e2以交织方式并发执行；∇e1∧∇e2指e1和e2同时执行；∇e1∨ ∇e2仅e1或e2执行。⊕,||,∧和∨分别用于sequence,And-split,Or-split控制流交互，并伴有数据流。此外，还存在如下复杂约束：① ∇IiRun()∧ ∇IiCommit()指Ii执行了Run()和Commit()；② ﹁∇IiFail()∧﹁∇IiCommit()指Ii不可能执行了Fail()和Commit()；③∇IiCompensate()→∇IiCommit()指Commit()需要在Compensate()之前执行；④∇IiRetry()→ (∇IiFail().⊕ ∇IiRetry())指Retry()需要在Fail()之后执行；⑤∇IiCommit()∧ ∇IiCompensate()→(∇IiCommit()⊕ ∇IiCompensate())指Commit()和Compensate()都发生，且Commit()在Compensate()之前执行。

任何复杂约束都可以转换为∨i(∧jConstri,j)，其中，Constri,j为约束表达式。同样可以讨论Ii和Ij之间的复杂约束，例如∇IiActivate()→∇IjCommit()是指如果Ii执行Activate()，则Ij必须在其之前执行Commit()；∇IiFail()→∇IiCompensate()是指Ii执行失败将导致Ij补偿。

LRT执行过程中，可能出现3种类型失败：①调用Web服务执行失败，失败信息在调用服务描述文档中给出；② 调用或执行服务超时；③ 执行引擎失败。本文讨论的失败恢复主要针对前2种情形，因此在发布服务时，需要给出服务契约，任务执行时，给出调用契约：① 若Ii和Ij存在满足契约CnlCon tract(Ij)，当且仅当Ii失败且Ii.Failed∈CnlContract(Ij)，则触发依赖② 若Ij满足中止契约Abt Contract(Ij)，Ii.failed∈AbtContract(Ij)∨Ii.Aborted∈AbtContract(Ij) ∨Ii.Cancelled∈AbtCon-tract(Ij)，中止Ii则触发中止依赖③ 若Ii和Ij满足补偿契约CptContract(Ij)，Ii.failed∈CptContract(Ij)∨Ii.Compen sated∈CptContract(Ij)，Ii失败则触发依赖为了更准确地选择RHS提供失败恢复，RH用恢复契约来配置RHS，优点是随时增加或减少契约条目。

图3 嵌套范围

4 失败恢复模型及算法

目前业界所提供的失败处理规范主要是向后恢复，恢复代价较高开销大，其没有考虑失败修复后LRT继续执行。基于此，本文提出一种支持组合事务的综合恢复策略，除了保留向后恢复，还扩展了向前和替代恢复。

4.1 向后恢复模型及算法

LRT执行失败，Ij激活fail()，中止正向流，触发RH，RH捕获Ij事件fail()，计算Ξ，抽取执行日志，计算恢复输入Ii′.in (从Ii.In和Ii.Out获取)和Ii′.Cp(由Ii.TBP和Ii.State产生)，启动向后恢复策略。为便于问题描述，将逆向恢复流从正向事务流中分离出来，Ξ中的任务满足Ii.TBP{∈Compensable,Vital}，RH 激活Ii′，Ii逐个映射Ii′。下面给出向后恢复配对策略BRPS的形式化定义。

假定I=(P,T,F)和I'=(P',T',F')分别表示LRT的正向和逆向流，∃Ξ∀I∈Ξ|I÷I'∈T÷T'，tic映射Ii到Ii+1的补偿，tif映射Ii到Ii′的失败转移，ti'c描述Ii'到Ii+1'的逆向转移。BRPS的三元组表示为其中下面给出BRPS的逆向构建算法。

算法1 构造恢复流算法

输入：LRT中任务I的集合, 失败任务Iℓ和补偿依赖集CP

输出: 恢复流Rflow

该算法的时间复杂度与 LRT中任务数目及Ξ中补偿任务数有关，若max(|LRT|,|Ξ|)=n，则该算法的时间复杂度为O(mn)。下面给出向后恢复算法。

算法2 RH恢复执行算法

输入: LRT中任务I的集合, 恢复流Rflow

输出: 补偿服务执行信息

若|Rfolw|=n和Edge(Iℓ)=m分别为Rfolw中任务数和边数，该算法的时间复杂度为O(mn)。

4.2 向前恢复模型及算法

与BRPS模型构造类似，不同的是向前恢复模型回滚到TDP后，RH注入正确输入，重启正向流执行。假定I=(P,T,F)是LRT正向流，若Ij执行失败，计算其Ii.TDP和Ξ，向前恢复策略FRPS的三元组表示为，其中：下面给出FRPS恢复算法。

算法3 向前恢复FRPS算法

输入：失败任务Iℓ，执行日志Log，业务流程LRT

输出：恢复成功或失败信息

逆向执行恢复流的时间复杂度为O(n)，而从TDP重新执行LRT的时间复杂度为O(n)，因此，FRPS算法的时间复杂度为O(n)。

4.3 替代恢复模型

LRT失败，失败任务Ii.TDP={Ij}且Ii.Ξ=Ii，若{Ii}={Ij}，则Ii的失败发生不依赖其他任务，选择FRPS或BRPS恢复代价都过高，仅需要选择Ii的替代服务，替代恢复ARS的形式化描述如下。

假定Ii=(Pi,Ti,Fi)是LRT正向流，Ij执行失败，计算Ii.TDP和Ii.Ξ，若∃Ξ∀Ij∈Ξ|Ii=Ij，引入替代流Ii″=(Pi″,Ti″,Fi″)，ARS 三元组表示为，其中：LRT执行失败，依据iI失败类型选取 RHS，BRPS恢复代价最高，ARS最低，FRPS介于两者之间。

5 LRT的事务性质扩展

LRT往往涉及复杂恢复行为，并以不同聚合模式构造。LRT的事务性质需借助基本聚合模式的事务性质，并扩展LRT的事务性质。假定有3个聚合服务cs1、cs2和cs3对应的聚合片段分别为Ii⊙…⊙Ij、Im⊙…⊙In和Ip⊙…⊙Iq，其中，{⊙∈⊕,||,⊗ ,Θ}，借助形成一组新的聚合服务集合和

1) 对于顺序聚合cs1⊕cs2，cs1.TBP⊗cs2.TBP的聚合事务性质需检查cs1中Ii⊙…⊙Ij的Ij.TBP，cs2中Im⊙…⊙In的Im.TBP，检查连接点Ij.TBP⊕Im.TBP的事务性质，特别地，Ij.Retriable⊕Im.Compensable不能保证LRT的原子性。

2) 并行组合cs1⊕(cs2||cs3)需要检查连接点Ij.TBP⊕Im.TBP和Ij.TBP⊕Ip.TBP的事务性质；而(cs1||cs2)⊕cs3则需要检查连接点Ij.TBP⊕Ip.TBP和In.TBP⊕Ip.TBP的事务性质。

3) 选择聚合cs1⊕(cs2⊗cs3)和鉴别器cs1⊕(cs2Θcs3)类似于cs1⊕ (cs2⊗cs3)连接点分析，检查Ij.TBP⊕Im.TBP和Ij.TBP⊕Ip.TBP的事务性质；分析(cs1⊗cs2)⊕cs3和(cs1Θcs2)⊕cs3类似于(cs1||cs2)⊕cs3。

6 失败恢复网的性质分析

依据 RHS定义，仅有一个初始托肯处于源库所，如果执行LRT没有点火任何失败变迁，托肯将随正向传递，直到成功到达槽库所。但是，LRT的执行可能导致失败发生，设失败恢复网系统依据失败恢复类型不同，选取那么按流方向Σ

被划分为正向网系统∑e=(Ne,Me)和恢复网系统若∀σ∈T*∧∃tf∈σ∧tf∈Tf，满足：存在恢复路径σ=σ1， 使 得即 细 化，使得点火Σr中恢复步序列σ2∈使得，称σ2是σ1的恢复路径。分别为Ie及其恢复任务Ir在σ1和σ2上的投影序列，若则有恢复映射f:σ1→σ2；③σ2是σ1的恢复路径且存在映射f:σ1→σ2，若||σ1||≠0，则||σ2||≠0，称Σ是可正确恢复的。

定理 1 设失败恢复网系统Σ=(FRS,M0)，其正向网和恢复网系统分别为Σe=(Ne,Me)和Σr=(Nr-1,Mr)，若Σe执行失败，则Σ是恢复可达的。

证明Σe和Σr中正向流和恢复流分别为(P×T)∪ (T×P)和(P′×T′)∪(T′×P′)，由Σe执行失败，依据恢复策略定义，构造(P×Tf)∪(Tf×P′)∪(T×Pf)∪(Pf×T′)失败转移，从而转向恢复流σ(σ∈TPfT′或σ∈(TP)*Tf(P′T′)*)，Pf或Tf使得Σ恢复可达。设M1,M2∈M0[＞∧M1∈RS(Σe)，存在恢复步序列σ，使得M1[σ＞M2∧M2∉RS(Σe)，若失败发生使得即tf点火Σ中的步序列σ2，使得从而Σ恢复可达。

定理2 设失败恢复网系统∑=(FRS,M0)，其中RHS可以是(保证正确恢复。

证明 设Σ的正向网系统和恢复网系统分别是是Σ的失败发生，那么中任意包含tf的执行路径若[Me,Mr1]RS(∈Σ,M0)∧Me1∈RS(eΣ,Me0)∧Mr1RS(∈rΣ,Mr0)，存在正向执行路径σ1，使得M0[σ1＞Me1[tf＞Mr1，依据tf失败类型，FRS触发失败恢复策略则tf点火Σr恢复步σ2 f，并执行σ2 f，使得Mr1[(σ2 f)＞，满足f:σ1→σ2，Σ是可正确恢复的。

对于(FRS,M0)中的σ，若步序列，由 BRPS 有且f:I→I′(其中，I∑∈e，I′∈rΣ)，即tf点火rΣ，I′消除I的影响；若M0)，其中，使得点火rΣ恢复步σ2 f并执行，使得恢复后执行继续，称Σ是可恢复的。

定理 3 设失败恢复网系统Σ=(FRS,M0)，RHS是分别是Σ的正向网和恢复网系统，Σ失败恢复是安全的。

证明 ∀Mrf1∈(Σ,M0)∃tr∈T*，依据tf失败类型，触发分3种情形证明Σ的安全性：① 若tr∈，由于Σe=(Ne,Me)是安全的，存在执行路径，使得仅影响Σe中Me1，而Σr中标识不变，依据Σr定义，存在标识转移Me1[tr＞Mr1[σ1＞(其中，确保Σ安全恢复。

7 基于组合事务恢复的应用

组合事务应用实例用经典的旅行预订流程TRP，如图4所示，旅行者TE向旅行社TA提交旅行需求说明CRS；由CRS分别预订机票FB(或火车票 TR)和宾馆 HB，租赁小车 CR(或大巴 BR)，TE确认预订并在线支付OP，快递 EMS(或 UPS)投递给 TE，TE签收确认 TC。聚合嵌套后的事务流程为CRS⊕((FB⊗TR)||HB||(CR||BR))⊕OP⊕(EMS⊗UPS)⊕TC。实例中旅行社在广州，而航空公司、酒店和汽车租赁公司分布于全国 20多个景点，表 2给出了 TRP中可能组合的服务及其事务性质。若TRP聚合了WSp，其既不可补偿也不可重试。要获得LRT事务原子语义，WSp必须保证在执行向后恢复之前提交或确保不发生失败。

图4 旅行预订流程

试验环境配置：执行引擎选用ActiveBPEL，2台服务器IBM x3650 (4核Intel 2930MHz CPU、1GB RAM和SuSE 10.2 Linux OS)和12台网络工作站(Intel E5200 2.5 GHz CPU, 2GB RAM和Windows XP SP2)。TE自主选择旅行路线并提交给TA，TA生成路线图(协商最短路线)，TE确认路线，旅行社预订机票、火车票、酒店以及出行交通工具，向TE提交预算，一旦预订失败，协商预订子流程：① 变更无法预订的服务，如将交通工具从火车改飞机、将酒店单人间改双人间。② 变更不能成功预订的景点，系统推荐景点。模拟事务回滚机制，自动退订已预订的机票和酒店等。③ 删除不能预订的景点。预订成功，将预订信息返回给 TE。组合事务的执行语义保证组合事务正确执行，其不仅可以检测TRP执行的逻辑错误，还能检测执行失败恢复的正确性（如图5所示）。如图6所示，若预订type为hotel，进入酒店预订子流程，当star为三星级进入 orderwanjia，Towanjia预订万家酒店，Invokewanjia调用 WanJia HotelServcie。退订 type为 hotel时，进入退订酒店子流程，当退订酒店为huatian，将 HuaTianReturnReq传递到 tohuatian退订酒店，invokehuatian调用HuaTian HotelService，完成相应的恢复。

表2 可用服务及其事务性质

图5 TRP组合业务流及其恢复流

图6 TRP执行预订及其变更

TRP预订流程中，旅行社负责预订航班、酒店和租赁汽车。如果预订机票失败，需要取消酒店预订和汽车租赁，最后与旅行者协商改火车出行，一旦成功预订火车票将不能再次变更。表3描述TRP中多伙伴协作操作对，失败恢复时，首先检查发生失败任务是否存在恢复任务，如果存在，执行恢复；否则，执行空操作。恢复对用I.action÷I'.action表示，其中，I.action表示I正向执行操作，I'.action表示I'所执行恢复，特别地，Ø是空操作。

表3 TRP中恢复对描述

图7 失败聚合性能比较

图8 失败恢复后性能比较

本文将TRP组合服务分为4组，前3组分别在不同执行任务点失败，第4组则执行成功，比较4组恢复策略下的失败率比较。图7给出了TRP执行失败的聚合性能曲线，这里的聚合曲线是累计聚合值。应用第4节给出的组合事务恢复算法讨论TRP失败恢复，更好地指导事务恢复。分5组聚合服务来执行TRP流程，结果显示，仅QoS0曲线成功执行，其他4条曲线QoSC1、QoSC2、QoSC3和QoSC4分别执行到第3、4、7和8个服务时失败，从图7可以看出，失败率与选取不同性质的原子服务有关，失败率与服务信誉度基本一致，与响应时间相比仅在第7和第8个失败处显著增加，与可靠性相比仅在第3、4和8个失败处一致，与可用性相比仅在第7个失败处一致，但执行代价和执行时间在执行恢复策略前后几乎无变化。

图7中曲线分别对应图8中QoS0、QoSC1、QoSC2、QoSC3和QoSC4恢复曲线，在第3、4、7和8个失败处启动恢复策略，恢复执行后，对响应时间产生了影响，但执行时间和代价变化不大。综上分析，可以得出以下结论：① 采用合适的恢复策略，可有效减少失败恢复代价；② 尽管失败不可避免，但最终可筛选出失败率较低的LRT；③ 受失败率影响，聚合曲线可协调LRT中参与组合的服务，消除不利因素影响。

8 结束语

鉴于LRT事务的复杂性，LRT中被组合任务可能具有不同的事务性质，确保其在SOC环境中可靠执行，需要构建有效的失败恢复策略。为此，本文提出一种支持组合事务的失败恢复算法，为不同的失败发生选取合适的恢复策略。旅行预订实例分析表明该算法可确保LRT可靠执行，最后通过对TRP失败恢复分析，表明选择合适的恢复算法对减少事务失败率和消除不利因素影响是有利的。

未来的工作主要包括如下 4个方面：① 引入事务流日志挖掘算法；② 建立组合事务恢复的依赖规则；③ 深入研究事务恢复的局部和全局约束；④ 违反组合事务性质的检测技术。

[1] LAKHAL N B, KOBAYASHI T, YOKOTA H. FENECIA: failure endurable nested-transaction based execution of composite Web services with incorporated state analysis[J]. The International Journal on Very Large Data Bases, 2009, 18(1):1-56.

[2] LIU A, LI Q, HUANG L S,et al. FACTS: a framework for fault-tolerant composition of transactional Web services[J]. IEEE Transactions on Services Computing, 2010, 3(1):46-59.

[3] HEWETT R, KIJSANAYOTHIN P. Privacy and recovery in composite Web service transactions[J]. International Journal for Infonomics, 2010, 3(2): 240-248.

[4] KOLLINGBAUM M, SYCARA K, VACULIN R,et al. Recovery mechanisms for semantic Web services[J]. Distributed Applications and Interoperable Systems, 2008, 17(3): 100-105.

[5] MINH T, LE N, CAO J L. Flexible and semantics-based support for Web services transaction protocols[A]. Grid and Pervasive Computing[C]. 2008. 492-503.

[6] BHIRI S, GAALOUL W, GODART C,et al. Ensuring customised transactional reliability of composite services[J]. Journal of Database Management, 2011, 22(2): 64-92.

[7] YANG Z H, LIU C F. Implementing a flexible compensation mechanism for business processes in Web service environment[A].International Conference on Web Services[C]. Salt Lake City, USA,2006.753-760.

[8] SCHAFER M, DOLOG P, NEJDL W. An environment for flexible advanced compensations of Web service transactions[J]. ACM Transactions on the Web, 2008, 2(2):1-36.

[9] SCHAFER M, DOLOG P, NEJDL W. Engineering compensations in Web service environment[A]. International Conference on Web Engineering[C]. Como, Italy, 2007. 32-46.

[10] KIM Y, KIM J. Allowing user-specified failure handling in Web services composition[A]. Proceedings of the 2nd International Conference on Ubiquitous Information Management and Communication[C]. Kuala Lumpur, Malaysia, 2008. 452-458.

[11] BRUNI R, FERRARI G, MELGRATTI H,et al. From theory to practice in transactional composition of Web services[A]. International Workshop on Web Services and Formal Methods[C]. Versailles,France, 2005. 272-286.