Web服务上的事务支持系列2
BTP协议简介
传统的ACID（原子性、一致性、隔离性和持久性）事务结构并不适用于现在的B2B协作应用程序，特别是当Web服务用于此类程序中来整合跨企业间的过程与应用程序，因为在ACID事务中要求细粒度的加锁和高度信任，而这些在B2B环境下没有必要。
B2B协作过程大都比较复杂、且长时运行，有时需要取消已完成的任务（为此要进行许多恢复工作，）或选择另外一条执行路径（应该说，类似传统事务，只是执行时间长），而且如果资源提供给第三方时并被锁定时，可能会导致其它事务无法运行。
尽管有一些扩展事务模式支持复杂事物结构并且放宽了ACID的限制，但是它们的目标大都是为了保持共享数据的一致性，而没有考虑到业务过程恢复，所以不适合于这些包含了松散耦合、基于Web(Web-based)商务服务。为此Organization for the Advancement of Structured Information Standards（OASIS）提出了商务事务协议（Business Transaction Protocol）用于满足Web-based、长时运行的协作商务应用程序的需要。OASIS的BTP针对长时运行的协作型应用。
支持B2B交互的事务模型需要有以下性质：
在保持自治和对所管理的资源的控制权的同时，服务提供者应该允许用户能保留可选项。（拿确定一个包含订飞机票、旅馆和包车的行程为例来说，用户可以只订机票和旅馆而不订车，也就是说要在整个事务中区分出关键项目和可选项目）
事务可以处理多个不同的成功结果，因为用户也许会有若干的可以接受的选项。（比如在上面的例子中，用户可以从多次航班、多个旅馆中选择想要的。）
每一个事务应该可以包含多个不同的共识组（consensus group），因为在一个事务中不是所有参与者（participants）需要同一个结果（outcome）。（这一点不太明白。举上面的例子来说，用户确定行程包含订飞机票、订旅馆和包车三个环节，原文并没有说明在这个例子中consensus group是指什么。）例如，共识组1是总价<3000元，共识组2是总价在3000到4000元之间）
事务中的参与者participant需要支持临时性或试探性状态变化（provisional or tentative state change），比如在这个例子中如果用户订票超过时间未确认，那么订单将被释放。
事务的各部分需要了解各自的终止条件（confirmation或cancellation）。
在Web服务的环境下，各部分要根据各自的环境、商务关系以及其他商务或逻辑因素来决定消息交换的方法，交互事务中的消息交换对于承载协议应该是不可知的。
BTP协议设计的目的有：处理长时运行事务、允许事务行为具有灵活的结果、并且支持超越在以数据为中心的事务的事务概念。最后一点尤为重要，因为在网上进行的商务交互一定要保证执行的一致性。
以下是具体应用在Web服务环境中的BTP协议的一些设计细节：
1. 主张的一致性(Consensus of Opinion)：
传统事务系统为了在多个参与者之间保证事务原子性，通常使用了两阶段或多阶段协议（Multiphase Protocol）。第一阶段为准备阶段，各个参与者需要让事务范围内的任何状态变化到达稳定状态。这样一旦达成共识（achieve consensus，我对这个的理解是：整个事务中的各个部分都达成一致，决定成功提交commit事务或是取消undo事务），这些变化都可以根据达成一致的结果来被回滚（roll back）或be made durable。
BTP协议使用两阶段输出协议（two-phase outcome protocol）保证原子性，但这并不意味需要某种特定的实现如补偿机制（specific implementations），为了说明这种区别，BTP将第二阶段中ACID事务所称的commit和rollback改称为confirm和cancel。这样的目的是为了将阶段与想像实现中会采用的向后补偿这些机制相区别。
2. 顶端开放式协作（Open-Top Coordination）：
对于传统的系统，应用程序一般具有一些原语（比如begin、commit、rollback等）用来控制事务。在应用程序要求一个事务提交时，协调者（coordinator）执行整个两阶段协议，然后才返回结果--这被BTP称为顶端封闭式提交协议，两个阶段之间的操作完全处于协调者的控制之下。这样的缺点就是执行时间越长，出故障的可能就越大，而且资源被锁定的时间也越长。
BTP使用了一种顶端开放式的提交协议，通过扩展可用原语范围（prepare、confirm、cancel等）来允许应用程序设定各阶段之间持续的时间，从而达到显式控制两个阶段的目的。
3. 为Web服务进行的扩展事务：
为了解决商务事务的一些特殊需要，BTP引入了两种扩展事务：atom和cohesion。这两种事务都使用了顶端开放方式和两阶段协议，并且直接由应用程序驱动。
原子事务（atom）可以保证逻辑工作单元（logical unit of work）得到一个一致的结果，它的特点是工作单元中的所有操作要么一次全部完成、要么就都不做。但原子事务放宽了隔离性，即事务进行过程中中间结果对其他事务可见，这点可用于支持长事务。
内聚事务（cohesion）则放宽了对原子性的要求，允许根据更高层次的商务应用规则来决定事务的终止。与原子事务不同的是，内聚事务可以让参与者（participants）各自按照不同的方式终结，比如有些确认，有些取消。实质上内聚事务的两阶段协议参数化了，以允许应用程序明确决定哪些参与者进行准备（to prepare），那些则取消。内聚事务很适合作长时间运行的商务活动的模型，在商务活动允许的过程中，它可能会遇到各种条件来决定prepare或cancel其中的工作单元，直到内聚事务到达一个确认集（confirm-set），该集包含了要使商务活动成功结束必须要确认的参与者。一旦这个确认集确定后，整个内聚事务就退化成为一个原子事务，所有确认集成员都必须到达同一个结果。
4. 模型细节
关系与角色（role）：
在BTP中定义了角色的概念以及和角色相关的关系。有两类角色：superior和inferior，superior和inferior形成树状的关系。根据软件代理（software agent，又称为BTP actor）在商务事务树中的位置不同，这些actor扮演不同的角色，superior一般是协调事务的，inferior通常与应用活动有关，应系统其他部分的要求做出诸如对数据进行修改或入队等操作。
不管相关的操作是被确认还是被撤销，inferior都有责任报告给superior自己已准备就绪。而superior则从它管理的inferior处收集报告，并根据事务的类型（原子事务还是内聚事务）决定如何终结整个事务。
其他角色：
coordinator和composer：
atom事务中最重要的superior称为coordinator，cohesion事务中最重要的superior被称为composer，它用于将业务逻辑连入两阶段完成协议。这两者都是用来管理事务结果outcome的，后者对结果的控制更为细密。在多级的结构中，又细分出了subcoordinator和subcomposer。
transaction factory：一般来说是一个Web服务，用来建立一个商务事务的上下文，并管理相关的coordinator；或者把subcoordinator并入已经存在的事务上下文中（transaction context，我的理解是指事务的标识ID、资源管理器信息、协调者信息等）。
initiator：按照应用程序的要求开始一个商务事务，它发送适当信息给coordinator，然后在事务工厂或coordinator帮助下创建一个事务上下文。
participant：是直接对事务输出结果负责的inferior，它是为Web服务做实际工作的实体。通常是coordinator要求participant，participant则对资源进行操作。
terminator：指挥coordinator确认或者取消事务。
以上这些角色的协同工作过程：
首先事务代理（agent，在这里作为initiator）将事务上下文传递给Web服务，确保coordinator控制整个事务。然后initiator唤起service上的操作，service引入相关的participants。服务站点作为回应返回确认号以及participants的状态、保持服务的承诺时间等信息。Agent收到这些信息后如果同意接受，就从initiator变成terminator，通知coordinator最后的决定，并向所有相关participants发送适当的信息，然后这些参与者向coordinator发送confirm消息来确认事务，再由coordinator通知Web服务confirmed。
5. BTP消息交换
在一个典型的简单事务中，根据各个不同阶段，请求－应答信息交换如下：
建立新事务：initiator发送begin要求给transaction factory。如果是建立一个新的顶级事务，那么该消息创建一个coordinator/composer；如果是在已有的事务之下建立新事务，则该消息创建一个subcooridinator/subcomposer。作为回应，factory发送一个begun消息给initiator，通知新创建的事务的相关上下文。
向事务中引入participant：当服务需要注册一个participant时，它发送enroll要求给事务的superior，superior作为回应发送enrolled消息，表示所要求的inferior已经成功引入。
确认事务第一阶段：当商务级的工作完成后，terminator初始化两阶段协议的第一阶段，superior给inferior发送prepare，inferior在确定它能或不能完成所要求的工作之后发回prepared消息给superior。
确认事务第二阶段：如果第一阶段成功结束，则terminator向decider发送消息confirm-transaction，该消息引发confirm消息发送给每个加入事务的participant。收到confirm消息之后，如果participant（这里就是inferior）完成确认就发回一个confirmed消息。当所以confirm-set中的inferior都完成它们的工作并发回confirmed消息后，decider发送transaction-confirmed消息给terminator。
小结
为了迎合Web服务的需求，BTP协议一开始设计时就满足成员自治，而且使用一些优化方法比如one-shot、Web Service栈等来提高性能。成员自治这一点是其他任何事务协议都没有实现过的，这一点也是BTP宣称之所以能够支持Web服务的关键。因为把Web服务作为成员来整合一个事务的时候，并没有一个最高协调者能够对其中的各个Web服务成员进行直接控制，所以需要一套机制对整个事务过程中各个成员进行协调，同时把具体任务下放给成员服务让它们自行进行操作，并收集成员的返回结果来决定事务的成功与否。
all rights reserved by tyloon@smth
--
FROM 159.226.5.*