6.始终信守你的诺言

　　为什么数据库不能一直信守诺言

　　接收一个服务请求的动作是通过定义一个承诺，即向请求者承诺服务请求会被执行，来确定的。这种执行定义了一个流程，其至少包含一个步骤，但通常是多个步骤。

　　数据库化的思考和流程不能融洽相处。从它们各自的本质来看，数据库就像是一个个孤岛。而孤岛会促使偏狭地思考问题：任何孤岛之外的东西都不重要。可以通过数据库中的事务概念来形象地解释这个问题：某个工作单元把数据库从一种一致性状态转移到另一个。在一些特殊的情况下，该概念可能会被扩展到多个数据库，虽然可以通过两阶段提交技术来做，但这也有局限性。逻辑一致性可能需要贯穿整个业务流程得以维护，而不只是恰好在某个时刻;需要在信息改变波及的所有地方去维护，其中不仅包括数据库还有流程管理系统、信息以及发送和接受信息的人工代理，而这一切从数据库世界的观点看来是完全陌生的。

　　SOA交易概念

　　对数据库世界陌生的东西对与SOA来说却是再自然不过了。业务交易——实现它的一般是一个流程——就是服务。为了理解SOA何以能很好支持逻辑一致性需求，理解业务交易的需要很重要。业务交易由下面元素组成：

　　厂商给客户提供信息，客户据此可作出采购决定。一般来说，这种信息包括出售商品和服务的属性、得到该商品的条件——包括，当然，价格——以及可用性。从法律的角度，厂商所描述的这一信息是真实的。

　　用户基于厂商描述的信息下采购订单。

　　厂商核实该采购决定依据的信息是否仍然适用，如果是，则确认该订单。如果有变化——可能由于产品或服务已终止，或产品已经涨价，也可能是货物或服务的规格已经变更——那么需要一些处理来决定到底应该如何做：是不管三七二十一继续提交订单，还是通过协商修改订单，或者干脆取消订单。

　　厂商和客户双方履行采购协议中各项条约。

　　SOA怎样维持一致性

　　SOA通过多种方法维护业务交易的逻辑一致性。第一，所有暗含对前一个状况改变的通信都要使用能够保证消息安全交付的协议来完成。只要厂商或用户做出某个承诺，为实现该承诺所要做的动作就应该包含这样的改变。这样的话，客户和厂商就不可能对当前业务状态持有不同的看法了。

　　第二，数据库的逻辑一致性和流程管理系统中处理过程的记录可以通过两阶段提交协议来维护。跨多个数据库的逻辑一致性通过一连串这样的两阶段提交维护。首先让数据库A和流程管理系统同步，然后流程管理系统再和数据库B同步，以此类推。

　　第三，从厂商给客户展示产品到订单下达期间，厂商面对的任何改变都可以使用乐观锁并发控制机制来处理。这种处理方式对SOA来说很自然：判断是否存在相应改动的过程可以完全自动化。因为SOA使得数据在被用来作决定的同时也可以进行访问，找不到乐观锁而需要人工介入的情况几乎鲜有发生。

　　最后，一笔交易的中止——比如说用户撤销了订单，原因可能是用户没有能力支付，或者用户去世了——使用SOA可以相对容易地处理。因为在交易上下文中使用或产生的记录可以被清晰地识别，所以可以确定需要哪些补偿信息用以纠正用户和厂商的不同认知。因为哪个数据库更新和该交易有直接关系是很清楚的，在数据库中的哪些变更需要使用补偿交易服务做回滚也很清楚。假设，交易中止的发生相对不那么频繁，使这些活动完全自动化通常是高投入低产出的，但是你的设计必须要考虑到这些。

　　请注意业务交易的范围限制在那些为了处理某个服务请求而直接完成的操作。在SOA中，编排你自己的流程并提供事件通知给他人，是一条守则。如果服务中止了，那么有必要发通知用户这一个变化。至于他们要怎么处理，则完全是他们自己的事。

　　也请注意，创建用户服务请求的内容，严格说起来，应该在流程处理之前进行，而不应该作为流程处理的一部分。这真的不是你该做的事：原则上，提供消息的XSD和消息验证服务给用户就够了，让他决定是从键盘录入数据还是从他自己的信息系统以某种方式直接生成数据。对消费者来说，这并不是——尚未成为——一个可行的方法，但采集数据和处理数据是两件独立的事情，并使用不同工具在各自的环境中执行这些事情，对于这一点仍然是有效的。同样是数据采集，有很多实现方式，这取决于用户的期望以及他们和你沟通的渠道，但不管怎样都应该只有一个服务去处理这事儿。