关于SOA的事务处理的讨论已经持续若干年了。尽管为解决这个问题人们已经提出了好几个标准，如 BTP，WS-BusinessActivITy, WS-AtomicTransaction, WS-Coordination等，但仍然没有被人们广泛认可的方案。在Arnon Rotem-Gal-Oz的这篇新博文中，他为大家呈现了他即将出版的《Practical SOA》中的一段书摘，也就是Reservation模式。

　　Arnon对SOA事务的相关问题的描述如下：

　　……在分布式的世界，不管是SOA还是其他，采用短期事务想法基本不是一个好想法……人们使用Saga模式的一个主要原因是基于不推荐使用跨服务的事务这个事实……而使用Saga模式的一个明显缺点就是无法执行回滚……再者，由于交互通常是长运行的，它可能失败，也可能被取消，Saga提供了补偿（Compensation）的概念。补偿的概念很酷：既然不能回滚，那我们就把交互的操作倒退回来，从而实现伪回滚……然而，补偿也存在很多问题，这些问题来自于以下事实：它和ACID事务不一样，Saga活动所作的修改不是孤立的。缺乏孤立性意味着服务所操作的数据可能已经被其他Saga活动所修改 ，使得补偿不可能实现。

　　Arnon还提到了补偿和Saga模式本身的另一限制，它需要外部协调者的参与，这就可能给外部协调者引入一些不必要的服务

　　Arnon在他的博文中提出了的模式是为了回答以下问题：

　　我们如何在保留服务的原子性和一致性的同时，以松耦合的方式有效地为服务提供一层保证？

　　答案是Reservation模式，它需要引入一个内部服务组件来处理预订（reservation），该组件的职能包括以下方面：

　　预订——当一个被视为“预订”的消息到达时，执行预订。比如，当一个订单到达时，除了对订单执行某些持久性存储（如，数据库）的更新之外，还要为订单确认（译注：即定单处理结束）设定一个计时器或到期时间 ，也可以设置一个标记，表示订单尚未完成。

　　验证——确保在流程结束时预订仍然是有效的。在上文提到的订单场景中，要确保分配给该订单的物品未被分配给其他订单。

　　到期——当条件改变时将预订标记为失效。比如，如果一个VIP客户需要该订单所预订的物品，系统可以把相应物品分配给该VIP。同时也应该要让该预订失效，使得该订单最后提取物品时系统知道物品去了哪里。也可以将到期设置成定时的，比如，“我们将为你的预订保留到明天中午”。

　　这种模式通过实现一个两道门协议（某种程度上类似于两阶段锁），从而让资源分发流程的管理以顺序的方式进行。在通过第一道门时，发起者通知所有其他参与者预留自己，如果发起者从所有参与的服务处（在超时范围内）得到的回答是OK，那么它将通过第二道门，并确认对所有参与者的预订。

　　不同于其他SOA模式，Reservation模式是一个业务模式，而不是一种技术模式。也就是说不存在一个直接的1对1的技术去实现它，Arnon描述了基于EJB3.0的一种实现。

　　由于事务处理是当今软件技术实现可靠和可管理的分布式计算的基础，被广泛用于交通、金融、保险、电信和制造等行业的大企业中，它们依赖事务处理对资金转账、支付处理、电子通讯、库存控制以及其他方面的支持， 在SOA中实现某种形式的事务显得极为重要。而Arnon的博文中定义的Reservation就是SOA架构师的工具箱中的一个重要工具。

　　但是这里有一个问题：服务该互相调用吗？如果有这么一个编排其他服务的流程呢？在后面的情况中，流程是有效的协调者，如果被调用的服务接口既支持动作（action）执行又支持补偿，那么Saga模式可能是一个更为简单的方案。