1.背景
SOA（Service-Oriented Architecture，SOA）是一种软件构架，它由服务和基础设施构成，通过运行于基础设施之上的服务和服务的联合灵活地实现功能需求。企业服务总线（Enterprise Service Bus，ESB）是SOA软件构架基础设施的一种实现方式，它提供了服务通信、服务发现/注册、服务事务处理、服务管理和服务安全等功能，其中服务事务处理功能是保证服务和服务联合正确有效运行的一个关键。
在早期的事务处理技术上主要有分布事务处理[1] 模型和对象事务服务[2]模型，它们主要解决的是紧耦合环境下的面向数据库的短事务处理问题，其特点是严格保证数据的ACID特性。随着分布计算的发展出现了工作流、协同工作等分布计算系统，它们的事务处理由于实现上的难度和特殊的应用场景需要放宽对数据ACID特性的要求[3]。因此，研究人员基于早期事务处理模型，通过从不同方面放宽ACID特性，提出了各种扩展事务模型（Extended Transaction Model，ETM），包括Sagas事务处理模型、嵌套事务处理模型等来解决这些特定分布计算环境的事务问题。由于扩展事务处理模型有其特定的应用条件，而且不支持严格的ACID特性的事务，难以全面满足SynchroESB环境下事务处理需求。
在SOA环境下的事务问题的研究主要集中Web 服务事务处理模型[4]的研究，目前还没有被广泛使用的事务处理模型。Web服务事务处理模型由Web服务协作和两个协调协议组成。由于Web服务协作框架使得事务的参加者动态注册到事务协调者，它适用于Web服务的动态组合运行环境而不适合SynchroESB中已编排好的服务流程的运行环境；Web服务事务处理模型中事务的划分依赖于应用程序的硬编码缺少灵活性，不适用于以服务组合形式提供功能的服务流程的事务划分；两个协调协议是为Web服务环境量身定做的，直接应用到SynchroESB环境下就很复杂、效率低，Web服务事务模型也不能直接应用到SynchroESB环境下。
2.相关事务模型
2.1.扩展事务模型
扩展的事务处理模型是在传统事务模型（即，平坦事务模型）的基础上，从不同方面放宽ACID特性的要求，增加特定的应用语义而设计的事务模型。扩展事务模型为设计和实现新的事务处理模型的提供了良好的思路。下面是常见的几种ETM：
Sagas模型是1987年Princeton大学的H. Garcia-Molina and K. Salem提出的扩展事务模型，目的是解决会长时间运行的事务由于对资源的长时间锁定产生的性能问题。Sagas模型有两个前提：①这些特殊的应用不需要原子操作，所以通过在事务结束之前对部分事务对象资源释放锁以提高事务处理的性能；②由于操作的非原子性，为得到结果的一致性，要求所有的子事务都要有相应的补偿操作；嵌套（Nested）事务的概念较早出现在1981年的J. E. B. Moss的名为《Nested Transactions: an approach to reliable distributed computing》的论文中，核心思想是允许在一个事务内部启动新的事务，这个过程的递归将形成一棵事务树，其特点是对外的最终结果由事务树的根事务决定，对子事务提交的结果其兄弟事务、祖先事务可见 ； Flexible事务模型是Purdue大学提出的事务模型，它通过定义了两种子事务之间的依赖关系：①子事务间的执行顺序；②两个子事务集合的优先关系，可以实现灵活的执行流程控制。
扩展事务模型依赖于特定的应用语义，放宽ACID特性的严格要求从而提高了事务处理系统的性能，得到传统事务处理模型所没有的灵活性。扩展事务模型一方面放宽了ACID特性，一方面依赖于特定的应用语义。这使得扩展事务模型不能向SynchroESB中关键服务提供严格ACID特性的事务支持，同时基于服务的多样性，服务流程很难完全满足某个扩展事务模型对特定应用语义的要求。
2.2.Web服务事务处理模型
Web服务事务处理(WS-Transaction)是由微软等软件厂商提出的、已成为OASIS标准的解决Web服务环境下事务问题的事务处理模型。Web服务事务处理包括3个部分：Web服务协作（WS-Coordination）、Web服务元处理（WS-AtomicTransaction）和Web服务业务活动（WS-BusinessActivity），Web服务协作是一个可扩展的Web服务协调框架，是Web服务元处理和Web服务业务活动两个协议工作的基础。
Web服务协作：协作的多个Web服务组成的分布计算单元称为活动。Web服务协作通过对活动的参加者的协调来达到一致同意的活动的输出结果。包含三个组成部分：激活服务（Activation service）使得应用可以构造一个协调实例或者上下文。该协调实例或上下文唯一标识了一个活动。注册服务（Registration service）使得活动的参与者可以注册协调协议。协议集合（Set protocol）协调者支持的实际进行协调工作的协议（其定义在相应的协议规范中）集合。
Web服务元处理：Web服务元处理定义基于Web服务协作进行工作的具有“全部或者什么也不做”属性的协调协议。它定义有两种协议：活动发起者与协调者之间的完成协议和协调者与活动参与者之间的两阶段提交协议。该协议对已有事务处理系统的私有协议进行封装对外交互的形式是Web服务的形式。
Web服务业务活动：Web服务业务活动是Web服务长时间事务处理模型。业务活动事务模型和Web服务元处理的主要的区别是，它放宽了对事务参加者的一致性要求，提出了AtomicOutcome和MixedOutcome两种协调类型。对于AtomicOutcome，所有的参加者的最后状态是一致的，要么是Closed要么是Compensated；而MixedOutcome所有的参加者只要都达到一个状态，可以是Closed、可以是Compensated不要求它们是一致的。同时，Web服务业务活动事务处理模型提供了两个协调协议，分别是BusinessAgreementWithParticipant
Completion和BusinessAgreementWithCoordinatorCompletion。两者的主要区别是，前者知道什么时候它的任务完成了，而后者要依赖于协调者给它“告诉”它什么时候完成了任务。
Web服务事务模型为解决松散耦合环境下的事务处理问题提供了良好的思路。但由于Web服务事务模型太多地考虑对Web服务环境的适应性使得难以直接应用到SynchroESB系统中。主要原因有三个方面：事务注册，由于Web服务之间的交互没有流程概念，事务参与者在接收到功能调用时进行动态注册，而在SynchroESB环境下，静态编制出的服务流程通过一次性以流程进行注册实现更简单同时获取更好的性能；事务划分，Web服务中事务的划分由应用程序决定，这与SynchroESB环境下不存在这样的应用程序，一切都是松散耦合的服务交互，同时让发起事务的服务划分事务也行不通；事务协调协议，Web事务协调协议专为高自治的Web服务环境设计，直接应用到SynchroESB环境下太复杂而且效率低。
3.面向流程事务模型设计
首先简要介绍SynchroESB的体系架构，同时对SynchroESB环境下对事务处理功能需求进行了描述，然后提出了面向流程的事务模型的设计。
3.1.SynchroESB平台框架设计
SynchroESB系统是一个集中式管理分布式运行的ESB系统，它分为工具层、管理层和服务运行层。工具层包括实现流程的配置编排和管理的服务流程编排工具（Process Orchestration）和ESB系统管理的控制台；管理层是实现整个系统的功能管理控制的中心服务器（UltraServer）；服务运行层由一台或多台实现服务的部署、运行、管理等功能的PeerServer服务器。服务流程通过服务流程编排工具配置、编排后由UltraServer部署服务流程的各个服务到相应的PeerServer服务器上进行运行，服务之间通过基于JMS技术的分布式规范消息路由（Distributed Normalized Message Router，DNMR）进行透明通信。SynchroESB系统的框架设计如图1所示：
图1 SynchroESB框架设计图
如图1所示，组成服务流程的松散耦合的服务被部署到PeerServer服务器上运行，这些服务分为两类：流程控制服务与流程功能服务。流程控制服务的功能是控制消息的处理流程 如，消息的过滤、分发、聚合等；流程功能服务是对消息进行功能处理的服务如，存取数据库、访问JMS服务器、访问MIS系统等功能。
SynchroESB环境下的事务功能是保证流程中所有功能性服务对外部资源的修改，也就是事务性消息对服务流程中相关服务产生的影响，满足不同程度的事务性，包括在关键性服务流程中保证严格的ACID特性和非关键性服务流程通过补偿机制保证弱ACID特性。
3.2.模型流程事务模型设计
POTM模型以Web服务事务模型为基础，由通过Web服务事务模型的事务协作框架修改得到的事务注册、事务协调/补偿、事务协调协议、分布通信和增加的基础服务功能与事务管理功能共六部分组成。POTM模型如图2所示。
事务注册功能：基于服务流程拓扑结构和服务参加者的静态编制这样的应用场景，采用Web服务事务模型的事务参与者动态注册到事务协调者的注册方式，注册过程复杂、效率低也没有必要。POTM模型中，通过服务流程的事务配置属性，首先以服务流程为单位进行注册，服务流程运行时配置参数和相关协议的参数都已确定，运行时只需要进行事务划分就可以进行事务的协调，不需要运行时事务注册。不仅实现简单而且提高了效率；
事务协调/补偿功能：在Web服务事务模型中，事务划分的功能是由应用程序实现的。在SynchroESB环境下，不存在操作服务的应用程序，服务之间是松散耦合的。事务协调/补偿功能通过对事务消息的跟踪完成事务划分功能，并驱动相应的事务协调协议实例进行事务协调动作；
事务协调协议：按照对事务ACID特性的要求的严格程度相应地驱动事务的提交、回滚、补偿和出错处理；
事务管理功能：在事务协调协议实例执行补偿动作出错时，将把错误交给该功能模块，由用户根据业务功能逻辑进行适当地处理；
分布通信功能：实现分布的POTM之间的透明信息透明，使得多个POTM系统表现为单一虚拟的分布事务环境，实现事务的分布处理和冗余容错功能；
基础服务功能：为事务注册、事务协调/补偿、分布通信以及事务管理功能模块提供日志、持久保存实例对象和远程POTM实例中相关对象的备份功能，是POTM模型中系统容错、错误恢复的关键功能。
4.相关实现
在SynchroESB系统环境中采用POTM模型来解决ESB系统中的服务流程的事务问题，主要实现了如下几个功能模块：在SynchroESB系统的服务流程编排工具上实现了事务可视化配置；在SynchroESB系统的ESB管理工具上实现了事务可视化管理；在SynchroESB系统的PeerServer上实现了POTM子系统；针对资源的类型实现了多种资源代理服务。POTM模型在SynchroESB系统环境下的应用框架如图3所示。
图3 POTM模型在SynchroESB系统中的应用
POTM模型的实现以及SynchroESB事务功能框架的实现的关键部分POTM模型中的事务协调/补偿功能部件的实现。事务协调/补偿功能主要由完成各事务参与者之间的协调，需要补偿时驱动补偿服务执行，补偿服务运行出错向事务管理功能报告三个功能，其核心是两种事务协议的实现：原子事务协议、业务事务协议。
（1）原子事务
在POTM模型中原子事务是指，一个或多个事务消息对流程相关的服务产生的影响是原子的。原子事务适合短时间运行、要求满足严格ACID事务特性的服务流程配置使用。
原子事务发起者（Atomic Transaction Beginner，ATB），发起事务消息的服务称为事务发起者，事务发起者可能是一个也可以是多个，ATB服务通过发送带有相应事务属性标识的消息实现事务的发起；原子事务结束者（Atomic Transaction Ender，ATE），事务消息最后到达的服务称为事务结束者，ATE可以由服务根据流程的拓扑情况主动表明自己的角色，也可以由事务协调者通过超时判断出ATE服务。从ATB发出第一个事务消息开始到ATE处理完最后一个事务消息结束称为一个原子事务（Atomic Transaction，AT）。在原子事务内相关的服务都是原子事务参与者（Atomic Transaction Participant，ATP）。
原子事务协调协议扩展了2PC协议，其事务状态转换如图4所示。
图4 原子事务协调协议
如图4所示Active状态表示事务处于活动状态；Ended状态表示事务的结束；Prepared状态表示准备好了提交；其他状态是中间状态。下面从ATP角度解释该协议：
ATP发送：发现自身没有使用事务资源时发出Exit消息给事务协调者，直接退出事务；在处理事务消息时出错了，回滚其做的工作，发送Halt消息通知协调者，由协调者回滚所有事务参与者；准备好提交和提交完成时分别发送Prepared消息和Committed消息到协调者，报告所处状态。
ATP接收：ATP接收并执行协调者发出的两阶段提交命令。
（2）业务事务
在POTM模型中业务事务是指，一个或多个事务消息对服务流程相关服务产生的影响是通过配置补偿服务来保证事务性资源一致性的事务协调类型。业务事务适合长时间运行、对ACID特性要求不严格、对一致性可以通过补偿实现的应用场景。
业务事务中根据服务流程的业务需求把流程中的服务划分成多个事务范围（Transaction Scope，TS），事务范围内的服务执行原子事务协议，所不同的是由指定的事务结束者（指接收事务范围内事务消息向事务范围外发送事务消息或不发送任何消息的服务）代替了ATE的角色。事务范围内的协调者是业务事务中的事务参与者，称为事务范围参与者（Transaction Scope Participant，TSP）。事务范围的补偿配置有两种方式，对事务范围本身的补偿服务配置和对事务范围内特定服务的补偿服务配置，执行事务范围补偿服务优先于执行服务的补偿服务。补偿服务运行失败将交给POTM的事务管理功能部件，通过可视化方式展现由用户根据业务场景决定如何处理（Handle）。
该协调协议是通过在Web服务事务规范的BusinessAgreementWithParticipantCompletion协议中去除“NotCompleting”状态和添加“Handling”状态得出的，其状态转换图如图5所示。由于在SynchroESB环境下，服务执行的事务协调协议是确定的，不存在不能完成协议的情况，所以去除了“NotCompleting”状态；添加“Handling”状态使得事务补偿出错时，可以通过事务管理功能部件根据业务需求进行适当处理。
图5 业务事务协调协议
如图5所示，业务事务协调协议是事务协调者和TSP（即，事务范围的事务协调者）之间执行的协调协议。Active状态表示该事务正在活动；Ended状态表示事务结束。下面从TSP的角度解释该协议：
TSP发送：事务范围没有使用事务性资源时发送Exit消息退出事务；事务范围事务完成时发送Completed消息，等待协调者对事务进行补偿或者关闭；关闭完成时发送Closed消息；取消完成时发送Canceled消息；补偿完成时发送Compensated消息；活动过程中、补偿中和取消中失败将发送Fail消息；补偿过程中出错时发送Fail消息，通过人工处理结束事务。
TSP接收：当服务流程异常结束时事务协调者发送Cancel消息给活动的TSP，使其取消所做的工作；给完成了的TSP发送Compensate消息补偿所做工作；对于处于完成状态的TSP，如果没有配置补偿服务，协调者直接发送Close消息给TSP，使其结束事务。
5.应用场景分析
下面以数据抽取应用场景下的一个包括三个数据库服务的、采用原子事务协调的流程为例，阐述在SynchroESB环境下事务模型的工作机制。场景描述：服务S1从数据库A中取数据发送到服务S3，服务S2从数据库B中取数据发送到服务S3，S3把接收到的两路消息按照某种规则配对存放到数据库C中，S1、S2和S3编排为服务流程P1。工作机制如下：
（1）流程P1编排，通过可视化工具配置P1采用原子事务协调；
（2）流程P1部署，进行流程事务注册生成相应的原子事务协调实例AC1并把P1和AC1关联，同时给S1、S2和S3分别配备资源代理A1、A2和A3；
（3）流程P1运行，流程运行过程事务协调分为事务划分和事务提交，其中事务划分时序图如图6所示。
图6 流程P1事务划分时序图
A1首先发起事务T1，A2随后发起事务T2。假设T1和T2标识的事务消息正好在S3中配对成功，产生了新的事务消息。A3使用T1和T2为参数参加事务，此时CA1认为A1、A2和A3都是属于同一事务。A3发现事务消息不再发往下一个服务，于是向CA1发送事务结束消息。随后CA1将执行原子事务协调协议。原子事务协调过程比较简单，限于篇幅从略。
6.结语
面向服务的事务处理技术目前还没有成熟的解决方案，本文通过对扩展事务处理模型、Web服务事务处理模型的研究，结合SynchroESB环境特点设计并实现了一个基于流程的事务处理解决方案。目前POTM模型已应用到SynchroESB1.0系统中，保证其事务消息对服务流程影响的事务性，并取得了良好的效果。
