一种ESB事务模型的设计与实现

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环境下太复杂而且效率低。
 

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友