（湖南信息职业技术学院，长沙410200）
（CollegeofMathematicsandComputerScience，Hu'nanNormalUniversity，Changsha410200，China）
摘要：本文详细介绍了两阶段提交协议的基本原理和扩张到WEB服务中来保证其可靠性。在此基础上,介绍了，在BPEL中，如何用两阶段提交协议来保证组合几个WEB服务的原子性。
Abstract:Theprincipleof2PCisparticularintroducedinthispaper.Then,howtoexpendittowebservicesisdiscussed.Finally,itprovidestheideaofhowtoguaranteethecompositewebservicesusingthe2PCintheBPEL.
关键词：web服务；事务；两阶段提交2PC；原子事务；BPEL
Keywords:webservices；affairs；2PC；atom-transaction；BPEL
中图分类号：TP39文献标识码：A文章编号：1006-4311（2011）07-0158-02
0引言
web服务是一种新技术，它从根本上解决了企业之间及企业内部异构系统之间的互操作和互通信的问题。它的一个目的是保证下一代的软件能在数据服务之间动态组合。但是在松偶合的环境下，对WEB服务的事务集成还没有一种可靠的解决方案。庆幸的是，现在出现了几种不同的事务标准协议，如ibm和微软的ws-transaction和协调框架：ws-coordination，还有OASIS的商业事务协议：BTP，但是他们在相互竞争。原子提交协议是支持分布式事务的原子性的一个关键元素。两阶段提交协议是标准的原子提交协议。广泛的认为，在复杂的分布式事务中，2PC是保证事务正确性的关键。因此，用2PC来保证WEB服务的组合应用是可行的，但是在异构的，分布式的WEB服务中，又有新的特点，比如它是一个松散的，不好确定事务的边界等。本文按照ws-coordination和ws-trancation，在BPEL引擎中，提出了一种有效的方案，来保证集成WEB服务的原子性。
1WEB服务中的事务
传统的事务是处于一个紧偶合的系统中，要求满足ACID四个性质：①原子性（Atomicity）：要么执行所有操作，要么一个也不执行。②一致性（Consistency）：得到一致的结果，隐蔽中间状态的改变。事务的作用就是保持不变性。③隔离性（Isolation）：在事务成功完成之前，各项操作的结果都不能被外界所见。④持久性（Durability）：事务完成之后，其作用将永久保留在系统中。
但是在WEB服务中，一个松偶合的分布式环境中，要求满足这四个性质是还不太实际。为此需放宽ACID的定义[1]：
22PC协议
2.1原理2PC（两阶段提交）是一个原子事务协议，定义了多个参与者如何就一个原子事务的输出结果达成一致。它可以分为两个阶段：准备阶段和提交阶段。在准备阶段，每一个参与者就结果进行投票，要求全部同意提交才能提交，否则Rollback。
图1这个状态图指定了在协调程序与它的其中一个参与者交换消息时双向协议的行为[3]。状态反映双方对它们之间关系的了解。省略了一些细节问题，比如因协议错误而重新发送消息或者交换错误消息。协调程序发送Prepare、Rollback和Commit消息。参与者返回Prepared、Aborted、ReadOnly和Committed消息。
对于整个事务来说，一旦所有的Prepare应答消息都已返回，协调程序就可以决定整个事务的输出结果是要提交还是要异常终止。它在稳定的存储器上永久记录该决定，并向所有的参与者发送Commit或Rollback，让双边协议中的每一方都处于相同的Committing或Aborting状态。当每个参与者都已经完成了提交或异常终止时，它就用Committed或Aborted确认消息进行应答。
图2表示客户端调用两个参与者，成功提交两阶段提交事务的序列图。对图中的步骤解释如下：①客户发送begin信息到协调器开始一个事务，协调器产生一个事务上下文-context返回给客户端。上下文和其它交互作用信息在参与者和协调者之间流动，是上下文把整个集合的动作粘合在一起形成一个事务活动。协调器记录该context一直到事务完成。②返回上下文给客户。③客户用context加调用信息来调用参与者。Context的作用是通知参与者要到协调器上注册。因为context是包含在soap信息的头部，如果要调用的web服务没有处理事务这一功能，也不会影响到正常调用。④参与者拿到包含有事务上下文的调用信息，会到context指定的协调器上注册（或是本地协调器，再把本地协调器当作远程协调器的下一级），这时参与者进行可回滚的操作，并把操作记录到日志上，以便以后进行回滚，然后把结果返回给客户。⑤协调者记录参与者，把它作为事务的一个资源记录下来。然后返回注册成功的信息。⑥参与者把操作结果返回给客户。⑦同第3步。⑧同第4步。⑨同第5步。⑩同第6步。{11}客户根据返回的消息进行确认，用context来通知协调者提交哪一个事务。{12}协调器根据context找到对应事务的资源，发送prepare信息，通知参与者准备提交事务。准备意味着准备好接受提交或回滚的命令。{13}参与者接到prepare消息，进行试探性的提交，并记录在日志中。返回prepared消息，说明已经准备好了，可以提交了。否则，返回Rollback。{14}同第12步。{15}同第13步。{16}协调器根据参与者的“投票结果”，发出提交或者回滚信息，并记录在日志上。{17}参与者接到提交信息，进行提交，这时才是真正的操作。如果操作成功则返回committed。{18}同第16步。{19}同第17步。{20}最后返回最终结果给客户，事务成功或者失败。
假设有两个Coordinator，一个上级的，一个下级的，要进行两阶段提交，可以这样进行：首先，上级的Coordinator向下级的Coordinator和participant发出prepare消息，然后，下一级的Coordinator进行第一阶段提交，即向它的participant发出prepare消息，如果所有的participant返回prepared消息，则它向上一级的Coordinator返回prepared，否则的话返回Aborted。接下来，上一级的Coordinator根据返回的消息进行第二阶段提交。当下一级的接到消息后，进行第二阶段提交，把最终结果返回给上一级。
2.2故障的数据恢复恢复处理其实不是两阶段提交的一部分。不过更确切地说，2PC启用恢复。也就是说，因为所有的协调器使用2PC，它们可以执行这里所描述的动作并且保证数据的完整性。通过确认所有的可恢复的动作或者向前或者后退来维持数据的完整性。据恢复使用基于事务状态的规则，其中事务状态是由协调器和参与者记录的。这里给出恢复规则。故障发生后：①如果协调器不了解事务（换句话说，是在协调器日志上有记录之前），那么恢复规则是撤销所有的动作。②如果协调器了解事务，但是事务状态是Active或preparing，那么规则是撤销所有的动作。③如果协调器了解事务且事务状态是Committing，那么规则是提交所有的动作。同样，如果状态是Aborting，那么规则是撤销所有的动作。④如果参与者发现有不完全的事务，就根据记录信息，联系协调器。如果协调器没有发现该事务，则参与者回滚事务。如果协调器发现了此事务，则根据协调器的信息重新进事务的提交。
2.3规范事务的关键部分：事务上下文，它包含：①Identifier：一个唯一的名称，用来标识CoordinationContext。②Expires：活动的超时值。③CoordinationType：一组已定义的协调协议，这些协议描述所支持的完全处理行为。④RegistrationService：注册服务的地址，这个服务用来注册协调协议中的兴趣点（interest）和参与方式（participation），以确定活动的整体输出结果。⑤Extensibilityelement：是为可选的特定于实现的扩展而提供的。
例如：
<wscoor:CoordinationContextxmlns:wscoor="http://schemas.xmlsoap.org/ws/2002/08/wscoor"
xmlns:wsu=http://schemas.xmlsoap.org/ws/2002/07/utility
xmlns:myApp="http://www.w3.org/2002/08/myApp">
<wsu:Identifier>http://foobaz.com/SS/1234</wsu:Identifier>
<wsu:Expires>2002-08-31T13:20:00-05:00</wsu:Expires>
<wscoor:CoordinationType>
http://schemas.xmlsoap.org/ws/2002/08/wstx
</wscoor:CoordinationType>
<wscoor:RegistrationService>
<wsu:Address>
http://myservice.com/mycoordinationservice/registration
</wsu:Address>
<myApp:BetaMark>...</myApp:BetaMark>
<myApp:EBDCode>...</myApp:EBDCode>
</wscoor:RegistrationService>
<myApp:IsolationLevel>RepeatableRead</myApp:IsolationLevel>
</wscoor:CoordinationContext>
在第一次调用participant的时候，如果不包括CoordinationContext，participant就不需要进行事务，直接永久化操作，返回就行了。如果包括，就根据CoordinationContext，到相应的事务服务器中注册，并不马上提交，先返回临时结果给用户看，然后等待消息进行相应的处理（提交或回滚）。因此，participant除了自身的应用操作外，还要提供几个用于事务的操作接口，所以，参与者的服务定义如下（省略了自身的应用operation）：
<wsdl:portTypename="2PCParticipantPortType">
<wsdl:operationname="Prepare">
<wsdl:inputmessage="wstx:Prepare"/>
<wsdl:outputmessage=”wstx:Prepared”/>
</wsdl:operation>
<wsdl:operationname="Commit">
<wsdl:inputmessage="wstx:Commit"/>
<wsdl:outputmessage=”wstx:Commited”/>
</wsdl:operation>
<wsdl:operationname="Rollback">
<wsdl:inputmessage="wstx:Rollback">
<wsdl:inputmessage="wstx:Aborted">
</wsdl:operation>
</wsdl:portType>
由于协调者可以作为上一级协调者的一个参与者，所以它应具有参与者的性质，另外还要提供一个供用户或参与者注册的端口，因此协调者的服务定义如下：
<wsdl:portTypename="2PCCoordinatorPortType">
<wsdl:operationname="Enroll">
<wsdl:inputmessage="wstx:CoordinationContext"/>
<wsdl:outputmessage="wstx:CoordinationContext"/>
</wsdl:operation>
<wsdl:operationname="Commit">
<wsdl:inputmessage="wstx:Commit">
<wsdl:inputmessage="wstx:Committed">
</wsdl:operation>
<wsdl:operationname="Rollback">
<wsdl:inputmessage="wstx:Rollback">
<wsdl:inputmessage="wstx:Aborted">
</wsdl:operation>
<wsdl:operationname="Prepare">
<wsdl:inputmessage="wstx:Prepare"/>
<wsdl:outputmessage=”wstx:Prepared”/>
</wsdl:operation>
</wsdl:portType>
3BPEL流程中的事务框架
由于在BPEL中，整个流程的生命周期可能是长时间的，如人工的参与审批。因此事务可能是长事务的，那么上面所讲的2PC就不适应了，为此，本文扩展了2PC协议，并把整个流程划分为若干个原子事务的组合，在个个部分应用扩展的2PC协议（图3）。图4展示了在BPEL中整合事务的框架图。
4结论
本文详细描述了2PC协议的基本原理，从此可以看出用2PC能高效的保证一个工作流中调用各个WEB服务的原子性，要么全部成功，要么全部失败。从而利用2PC协议，还是能够满足大部分的商业需求，为WEB服务的应用提供了保障。另外，本文简单提出了在BPEL引擎中怎样整合事务，来保证整个流程的一个高可靠性。后期工作，由于这里只是考虑到了原子事务，而没有实现长期事务，但是在WEB服务事务领域这是不可缺少的一部分，因为长事务也是由原子事务构成的，所以我们要按照规范，把长期事务也加进来。使WEB服务真正满足各种需求，成为商业上一个高可靠的体系结构。
参考文献：
[1]OASIScommittee.BusinessTransactionProtocol.2002.
[2]F.Cabreraetal.WebServicesCoordination.http://www.ibm.com/developerworks/library/ws-coor/.
[3]F.Cabreraetal.WebServicesTransaction.http://www.ibm.com/developerworks/library/ws-transpec/.
[4]NeilaBenLakhal，TakashiKobayashiandHaruoYokota.THROWS：AnArchitectureforHighlyAvailableDistributedExecutionofWebServicesCompositions.IEEE.2004.2.
[5]WeihaiYu，YanWang，CaltonPu.ADynamicTwo-PhaseCommitProtocolforSelf-AdaptingServices.IEEE.2004.
[6]MarkLittle,ThomasJFreund.Web服务事务处理协议的比较.http://www-128.ibm.com/developerworks/cn/webservices/.backup/ws-comproto/index.html.
[7]TonyAndrewsetal.BusinessProcessExecutionLanguageforWebServices.http://www.ibm.com/developerworks/library/ws-bpel/.
作者简介：莫裕清（1977-），女，四川人，讲师，本科，研究方向为计算机应用。