BPEL事务与补偿机制

      事务(transaction)对于软件工程师来说是一个非常重要的概念。按照非正式的表述方式，事务是指一组作为同一单元的活动，要么全部成功，要么全部失败。这种“全部或者没有”的语义是数据库访问的基础。按照正式的表述，事务包括如下属性：原子性、一致性、隔离性和持久性(Atomic、Consistent、Isolated和Durable)——ACID。

　　事务对于业务交互来说至关重要，为了保证一致性，一个ACID事务用到的数据库条目通常会在处理过程中被锁定。如果事务失败，数据库将会回退到之前的状态。这一功能由数据库提供商提供。

　　对于一组被调用的Web服务，BPEL也可以采用类似的思路，使用Web服务的相应规范来实现业务流程的事务支持。WPS 6.0提供了WS-Atomic标准的支持。

　　但是，通常我们无法锁定跨越企业的资源。当进行酒店预订时，您的旅行代理无法在预定过程中(或者在打预定电话的过程中)锁定酒店的预定数据库或者让系统主动停下来。取而代之的操作是，连锁酒店数据库的本地ACID事务作为一个整体，包括以下几个任务：更新房间总量，添加信息到预订表和生成一个确认号。如果旅行代理需要取消预定操作，一个补偿动作将被完成。某些时候补偿需要一定的代价。例如，如果预定取消得太晚，可能需要收取一定费用。

　　由于一个业务流程可能需要运行几天、几个月甚至几年，而且流程可能涉及外部服务。在流程完成前，单个活动有可能已经完成，如果随后某个事件或错误发生而导致流程取消，已经完成的活动需要被复原。这种情况下，我们无法使用简单的事务处理机制来实现回退，我们需要补偿支持来完成这一任务。

　　补偿是管理业务数据的一种特定方式，它总是业务逻辑的一部分。补偿与数据库为ACID事务提供的原子性回滚不同。补偿可以避免另外一个问题;Internet上的任何人都可以锁定公司的数据可能会引发的拒绝服务攻击。采用补偿方案意味着数据不会被长时间锁定，但同时也失去了ACID事务，至少隔离性保证无法满足，因为数据在最初的修改和补偿操作之间是可见的。在BPEL中，Compensation(补偿)用来还原已经完成的活动。一旦进行补偿，它就要流程中已经运行完成的所有活动都会依照特定的逻辑进行补偿。

　　在工作流中，每个Invoke活动的调用都被称为一个转发服务(forward service)，用于执行特定的服务调用。相关联用于补偿调用行为的服务被称为补偿服务。补偿服务仅当转发服务完成时才能够被调用。当流程中发生故障时，执行可选的补偿服务来补偿转发服务的行为。当一个服务活动完成时，如果已经定义了补偿服务，那么就向工作流的补偿域(Compensation Sphere)注册补偿服务及其输入数据。在流程实例结束时，补偿域查看是否抛出了故障。如果这个流程成功地完成，那么就不需要补偿任何活动。另一方面，如果这个流程失败了，那么您就需要执行补偿。如果需要流程补偿，补偿域就会调用它在后进先出(last-in first-out)队列(与转发服务完成的次序相反)中注册的补偿服务。

　　如图1所示是一个结合了错误处理与补偿机制的例子。第1个和第2个请求服务在同一个作用域中，它们都成功完成调用，作用域成功结束。属于流程作用域的第3个请求也成功完成。然而第4个请求调用却失败了，触发了错误处理程序。在第6步，错误处理程序执行补偿活动，将依次调用已注册的补偿处理程序，参见第7至第10步。

　　

　　图1 错误处理与补偿机制示例