用两阶段提交协议保证WEB服务的事务

用两阶段提交协议　

保证ＷＥＢ服务的事务　奠裕清湖南信息职业技术学院　４１　０２　００　

前育　ｗｅｂ服务是一种新的技术．它从根本　上解决了企业之间硬企业内部异构系统之　间的互操作和　通信的问题。它的一个目　的是保证下一代的软件能枉数槲服务之间　动态组合。但是在松耦合的环境下．对　ＷＥＢＩ］Ｉ务的事务集成还没有～种可靠的解　决方案。庆幸的是，现在出现了几种不同　的事务标准协议，如ｉｂｍ和微软的Ｗ　ｓ　ｔ　ｒ　ａ　ｎ　ｓ　ａ　ｃｔｉ　０　ｎ和蛳调框架：Ｗ　ｓ—　ｃｏｏｒｄｉｎａｔｉｏｎ，还有ＯＡＳＩＳ的商业事务　议：ＢＴＰ．但是他们猩相互竞争。ＢＰＥＩ　商　业可执行语言，目Ｉ】ｗＥＢ服务中的工作流，　它的目的是组合一系列分布ｌ在不　地方的　ＷＥＢ服务作为一个大的服务．放到ＢＰＥＬ　引擎中来执行。但是要在流程－ＩＩ加入事务，　到现在还没有一种可靠的方案　原子提交协议是支持分布式事务的原　子性的一个笑健元素。两阶段攫变　议　是标准的原了．提交曲－议。广泛的认为．　在复杂的分布式事务中，２ＰＣ是僳虹Ｅ事务　正确性的关键。因此，用２　Ｐ　Ｃ来保证　ＷＥＢ服务的组合应Ｈ１是可行的。但是　异构的．分布式的ＷＥＢ服务中，义有新　的特点．比如它是・个松敞的，　确　定事务的边界等。本文牧Ｊ｛ｃ｛Ｗ　Ｓ　ＣＯ０ｒｄｉｎａｆｉｏｎ和ＷＳ　ｔｒａｎｃａｔｉｏｎ．在Ｂ［】ＥＬ　引擎中，提¨｛了一种有敏的方案．来保　虹糍成ＷＥＢ服务的原子性。　本文在第二节简单介绍ＷＥＢ睢务巾　的事务慨念，在第三节【羊细介绍Ｔ２ＰＣ的概　念・在第四节给出了一个可用于ＢＰＥＩ　中的　蛮际框架一然后在第五节给Ｌｔ　５　ｒ例　来　明　框架的町行性。　一．ＷＥＢ服务中的事务　传统的事务是处于个紧耦台的系统　ｒ｛｜．要求满足ＡＣＩＤ四个性质：　◆原子性（Ａｔａｍ　Ｊｃ　Ｊｉｙ）：要幺执行所　有操作．要么一个也不执行。　◆一致性（Ｃｏｎｓｉｓｔｅｎｃｙ）：得到一致　的结果，隐蔽中间状态的改变。事务的作　用就是保持不变性　◆隔离性（Ｉｓｏｌａｔｉｏｎ）：枉事务成功完　成之前．各项操作的结果都不能｝业外界所　见。　◆持九性（Ｉ）１ｗａｂｉｌｉｔｙ），薜务完成之　后，其作用将永久保留在系统中　但是在ＷＥＢ服务中．　・个松耦合的　分布式环境中．要求满足这四个性质是　还不太实际。　为，一方面在有螳情况要　用补偿来回滚事务，另一方面有些事务可　能发生一些比较复杂的故障．而无法确定　原因。迁有传统的锁定技术会把资源锁定　几个小时．或者几天，薜至垂长地时间．这　样导致其它的事务长时间的等待是不合理　的．这时就必需臻引进　个新的算法或著　是一种新的技术来解决选种锁定　此外．　离性在分布武环境Ｆ一直　是一个比较热的话题，闽为商业上厦埘资　源的不确定的锁定。　为此需放宽ＡＣ１Ｄ的定义．…如表１。　二．２ＰＣ协议　２．Ｉ原理　２ＰＣ（两阶段提交）是一个原予事务　．定殳了多个参与者如何就一个原＿】！．　事务的输出结果这成・致。它可以分为两　个阶段：准备阶段和提交阶段。在准备阶　段，每一个参与嚣就结　进行投票，要求　垒部同意提交才能提交．否则Ｒｏｌｌｂａｃｋ。　陶１这个状态嘲指定了在协谰程序与　它的其中一个器与者喹换消息刖双向｝办故　的行为”Ｊ。状态ｊ互映双方时它仃ｌ之间关系　的丁解。省略ｒ一些细节问题．比如因｝办　议错误而覆新发送消息或暂交换错误消息。　佯细情况可以参考文献”。。　惆程序发送Ｐｒｅｐａｒｅ、Ｒｏｌｌｂａｃｋ和　Ｃｏｍｍｉ　ｅ消息。　参与者返回Ｐｒｅｐａｒｅｄ．Ａｂｏｒｔｅｄ、　性质　顾子事务　Ｋ删搿舟　原子性　垒做戏仝　做　绌粜ｍ　Ｃｏｏｒｄｉｎａｔｏｒ和ｐａ，ｌｉｃｉｐｍｌｔ商议确定　一致性　秆ｊ到一致的绌聚．胁　中恻状　褂到，敛ｆｆＪ鲇　．略微巾ｎ；ｌＪ状忐的改变　们足客户　志的改变　Ｃｏｏｒｄｉｎａｔｏｒ出，Ｕ“　・・｝ｌＪｌ”状卷舶列艟决定站粜。　躏尚性　埘见』壁幂『妁ｌ嫩性艘般务控制　ＩＩｆ地＿堑乖¨约嫩性被舭务拧沌４　持久性　窒占粜的持久稳定性　蚰　的持久秘ｌ　性，仍付　ｌ　ｌＩ】能　稳定　

Ｉ６２　表１　ＡＣＩ

Ｄ的定义　维普资讯 http://www.cqvip.com ｌ　图２　２ＰＣ时序图　

１６３　ＲｅａｄＯｎｌｙ和Ｃｏｍｍｉｔｔｅｄ消息　图２表示客户端调用两个参与者，成功提交两阶段事务的序列　图。　对图中的步骤解释如下：　１．客户发送ｂｅｇｉｎ信息到协调器开始一个事务，协调器产生　一个事务上下文ｃｏｎｔｅｘｔ返回给客户端。上下文和其它交互作用　信息在参与者和协调者之间流动，是上下文把整个集合的动作粘　合在一起形成一个事务活动。协调器记录该ｃｏｎｔｅｘｔ－－直到事务完　成。　２．返回上下文给客户。　３．客户用ｃｏｎｔｅｘｔ｝／ＩＩ调用信息来调用参与者。Ｃｏｎｔｅｘｔ的作用　是通知参与者要到协调器上注册。因为ｃｏｎｔｅｘｔ是包含在ｓｏａｐ信　息的头部，如果要调用的ｗｅｂ服务没有处理事务这一功能，也不　会影响到正常调用。　４．参与者拿到包含有事务上下文的调用信息，会到ｃｏｎｔｅｘｔ　指定的协调器上注册（或是本地协调器，再把本地协调器当作远　程协调器的下一级），这时参与者进行町回滚的操作，并把操作　记录到日志上，以便以后进行回滚，然后把结果返回给客户。　５．协调者记录参与者，把它作为事务的一个资源记录下来。　然后返回注册成功的信息。　６．参与者把操作结果返回给客户。　７．同第３步。　８．同第４步。　９．同第５步。　ｌ０．同第６步。　１　１．客户根据返回的消息进行确认，用ｃｏｎｔｅｘｔ来通知协调者　提交哪一个事务。　１　２．协调器根据ｃｏｎｔｅｘｔ找到对应事务的资源，发送ｐｒｅｐａｒｅ　信息，通知参与者准备提交事务。准备意味着准备好接受提交或　回滚的命令。　ｌ３．参与者接到ｐｒｅｐａｒｅ消息，进行试探性的提交，并记录　在日志中。返回ｐｒｅｐａｒｅｄ消息，说明已经准备好了，可以提交了。　否则，返回Ｒｏｌｌｂａｃｋ。　ｌ４．同第１２步。　ｌ５．同第ｌ３步。　ｌ６．协调器根据参与者的“投票结果”，发出提交或者回滚信　息，并记录在日志上。　１　７．参与者接到提交信息，进行提交，这时才是真正的操　作。如果操作成功则返回ｃｏｍｍｉｔｔｅｄ。　１８．同第１６步。　ｌ９．同第１７步。　２０最后返回最终结果给客户，事务成功或者失败。　假设有两个Ｃｏｏｒｄｉｎａｔｏｒ，一个上级的，一个下级的，要　进行两阶段提交，可以这样进行：首先，上级的Ｃｏｏｒｄｉｎａｔｏｒ　向下级的Ｃｏｏｒｄｉｎａｔｏｒ和ｐａｒｔｉｃｉｐａｎｔ发出ｐｒｅｐａｒｅ消息，然后，　下一级的Ｃｏｏｒｄｉｎａｔｏｒ进行第一阶段提交，即向它的ｐａｒｔｉｃｉｐａｎｔ　发出ｐｒｅｐａｒｅ消息，如果所有的ｐａｒｔｉｃｉｐａｎｔ返回ｐｒｅｐａｒｅｄ消息，　则它向上一级的Ｃｏｏｒｄｉｎａｔｏｒ返回ｐｒｅｐａｒｅｄ，否则的话返回　Ａｂｏｒｔｅｄ。接下来，上一级的Ｃｏｏｒｄｉｎａｔｏｒ根据返回的消息进行　第二阶段提交。当下一级的接到消息后，进行第二阶段提交，　把最终结果返回给上一级。相应的时序图见图３（Ｎ设下　‘级有两　ｌ　。

　维普资讯 http://www.cqvip.com 个参与者）。　３．２故障的数据恢复　恢复处理其实不是两阶段提交的‘部　分。不过更确切地说，２ＰＣ启用恢复。也　就是说，因为所有的协调器使用２ＰＣ，它　们可以执行这里所描述的动作并且保证数　据的完整性。通过确认所有的可恢复的动　作或者向前或者后退来维持数据的完整性。　据恢复使用基于事务状态的规则，　其中事务状态是由协调器和参与者记录　的。这里给出恢复规则。故障发生后：　◆如果协调器不了解事务（换句话　说，是在协调器日志上有记录之前），那么　恢复规则是撤销所有的动作　◆如果协调器了解事务，但是事务状　态是Ａｃｔｉｖｅ或ｐｒｅｐａｒｉｎｇ，那么规则是　撤销所有的动作。　◆如果协调器了解事务且事务状态是　Ｃｏｍｍｉｔｔｉｎｇ，那么规则是提交所有的动　作。同样，如果状态是Ａｂｏｒｔｉｎｇ，那么　规则是撤销所有的动作。　◆如果参与者发现有不完全的事务，　就根据记录信息，联系协调器。如果协　圈科技信息２００６年第９期　ＣＨＩＮＡ　ＳＣｌＥｔ，ＣＥ＿＾柚－－　．ａ制瓯＿ｃ旧　州陶　＾铆　２。晤≯　％　

调器没有发现该事务，则参　者回滚事　务。如果协调器发现了此事务，则根据　协调器的信息重新进事务的提交。　三．ＢＰＥＬ流程中的事务框架　由于在ＢＰＥＬ巾，整个流程的生命周　期有可能是长时间的，比如人工的参与审　批。因此事务也可能是长事务，那么上面　所讲的２ＰＣ就不适应了，为此，本文扩展　了２ＰＣ协议，并把整个流程划分为若干个　原子事务的组合，任个个部分应用扩展的　２ＰＣ协改（图４）。　可以在ＢＰＩｅＬ引擎中加进一个协调　器，作为默认的流程协调器。另外提供　一个ｐｏｒｔｔｙｐｅ包括三个ｏｐｅｒａｔｉｏｎ：ｂｅｇｉｎ，　ｃｏｍｍｉｔ和ｃａｎｃｅｌ，为用户在流程叶１来调　用，分别作为事务的开始，提交和回　滚。用户在书写流程的时候可以在流程　中调用ｂｅｇｉｎ操作，和ｃｏｍｍｉｔ或者ｃａｎｃｅｌ　操作，来确定事务的范围。引擎在执行　流程的时候，首先扫描整个流程看否有　上述的两个标识，若有引擎就会到协调　器上注册一个协调　下文，拿到协调卜　下文后，在调用事务范围之内的ＷＥＢ服　

图３两级协调器的２ＰＣ时序图　务的时候，会自动的把协调上下文加到　ＳＯＡＰ消息的头部。当流程执行到ｃｏｍｍｉｔ　或者ｃａｎｃｅｌ时，引擎自动发送提交或回滚　消息到协调器上，进行２ＰＣ提交。　另外，用户还可以在调用ｂｅｇｉｎ时传　入协调器的地址，这时引擎就会把此协调　器当作流程中的事务协调器。　图５展示了在ＢＰＥＬ中整合事务的框　架图。　四、实例　接下来讲的是一个旅游公司为客户提　供的一个服务，通过它客户可以订购机　票和旅馆。大概流程如下：首先，客户　访问首页，浏览可以订购的机票和旅　馆，然后根据自己的情况选择机票和旅　馆，然后提交。提交之后要进一步的确　认，因为有可能在你选择的时候被他人　订购了或者出现其它意外，那么客户需　要重新订购。当订购成功之后，就会返　回成功信息，否则返回错误信息。整个　事务原则是要么机票和旅馆都订购成功，　要么都失败。所以　以用两阶段提交来　保证。　＜／ｐａｔ￣ｎｅｒＬｉｎｋｓ＞　＜ｖａｒｉａｂｌｅｓ＞　

图５　

１６４　

图４　维普资讯 http://www.cqvip.com ＜／ｖａｒｉａｂｌｅｓ＞　＜ｓｅｑｕｅｎｃｅ＞　＜！～接收客户的访问信息～＞　＜ｒｅｃｅｉｖｅ　ｎａｍｅ－－”ｒｅｃｅｉｖｅｌｎｐｕｔ”…／＞　＜！　分别调用航空公司和旅馆的服务，得到可以订购的机　票和旅馆　＞　＜ｉｎｖｏｋｅ　ｎａｍｅ＝”ｇｅｔＦｉｇｈｔ”…／＞　￣Ｉ＇ＩＶｏｋｅ　ｎａｍｅ＝”ｇｅｔＨｏｔｅｌ”…／＞　＜Ｉ＿返回机票和旅馆信息给用户一一＞　＜ｒｅｐｌｙ　ｎａｍｅ＝　ｖａｌｉｄｅｄＦｉｇｈｔＨｏｔｅｌ”…／＞　＜Ｉ＿一接收客户的ｉｒ购信息一一＞　＜ｒｅｃｅｉｖｅ　ｎａｍｅ＝”ｒｅｃｅｉｖｅＢｏｏｋ”…／＞　＜！一到事务服务器上注册一个事务　＞　＜ｉｎｖｏｋｅ　ｎａｍｅ＝　ｂｅｇｉｎ”…／＞　＜！　根据订购信息调用航空公司和旅馆的定购服务　＿）＜ｉｎｖｏｋｅ　ｎａｍｅ＝”ｂｏｏｋＦｉｇｎｔ”…／＞　＜ｉｎｖｏｋｅ　ｎａｍｅ＝＂ｂｏｏｋＨｏｔｅｌ”…／＞　＜卜－返回订购信息给客　户一一＞＜ｒｅｐｌｙ　ｎａｍｅ＝”ｌｘ￣ｏｋｅｄＭｅｓｓａｇｅ”．．．／＞　＜Ｉ＿接收客户的确认信息　＞　＜ｒ　ｅ　ｃ　ｅ　ｉ　ｖ　ｅ　ｎ　ａ　ｍ　ｅ＝“ｒ　ｅ　ｃ　ｅ　ｉ　ｖ　ｅ　Ｃ　Ｏ　ｎ　ｆｉ　ｒ　ｍ”　ｖａｆｉａＭｅ＝”ｂｏｏｋＭｅｓｓａｇｅ”…／＞　＜Ｉ＿一根据确认信息进行两阶段提交事务　＞　＜ｓｗｉｔｃｈ　ｎａｍｅ＝　ｓｗｉｔｃｈ－１　’＞　＜ｃａｓｅ　ｃｏｎｄｉｔｉｏｎ＝”ｂｐｗｓ：ｇｅｔＶａｒｉａｂｌｅＤａｔａ　（’ｌｘ￣ｋｌｖＩｅｓｓａｇｅ。）＝’ｃｏｎｆｉｒｍ　＞　＜ｓｅｑｕｅｎｃｅ＞　＜ｉｎｖｏｋｅＤａｍｅ＝”ｃｏ￣ｈｎｎ”…／＞　＜／ｓｅｑｕｅｎｃｅ＞　＜／ｃａｓｅ＞　＜ｏｔｈｅｒｗｉｓｅ＞　＜ｓｅｑｕｅｎｃｅ＞　＜ｉｎｖｏｋｅ　ｎａｍｅ＝…ｃｏｎｃｅｌ”…