使用 Reservation 模式实现 SOA 事务

关于 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 模式可能是一个更为简单的方案。

查看英文原文： SOA Transactions Using the Reservations Pattern