阅读笔记之——《SOA架构模式》三

事务处理模式服务

服务构建的另一个重要属性是：怎么处理从边界组件或服务中得到的信息？事务处理服务模式（Transactional Service Pattern）可以解决这种问题，并且还能解决可靠性问题。

可以把SOA活动简化为服务收到服务消费者要求做某件任务的请求，服务处理请求（可能还会请求其它服务一起做这件任务），然后回应发起请求的服务消费者。图6显示了这样的一个商业系统中的活动场景。前台与订购服务进行对话。订购服务登记订单，把订单发送到供应商，然后通知账单服务。这些事件处理完成后，订购服务向电子商务前台应用发送一条确认信息。

事务处理服务模式的主要组件是消息泵（message pump），见图7。消息泵监听着终端或边界传入的消息。如果接收到消息，消息泵就开始一个事务操作，读取消息，把消息发送到其它组件/类进行处理，处理后，结束事务操作（完成或失败）。如果可以以事务处理的方式发送请求或回应，就可以把这些操作放入到事务处理中，否则你就需要为操作失败准备补偿逻辑。

使用事务处理编程模型的好处是它要么是纯语义学的，要么完全不是，因此不存在边界效应。由于事务的四个属性（ACID），所有的操作和消息都一定会被完全处理完、或完全没有被处理，所以如果有消息离开了服务，那么触发这个行为的传入消息肯定是被完全处理过了。 ACID事务

实现事务处理服务模式的一种方法是为所有服务间的消息使用事务消息传输。事务消息传输 （transactional message transport）使得模式的实现变得非常简单——只要按照前面提到的步骤来就可以了：开始事务、读取、处理、发送、完成。另外一种方法，也是更常见的一种方法，是在接收到消息后把消息放到事务处理资源中（比如队列或数据库），然后向服务消息者发送一条确认消息。但是这种情况下最初的消息不包括在事务处理中，因此你要准备应付服务消费者的多次消息发送。比如，服务消费者没有收到确认消息，于是“又”发送了一条请求消息提取100万美元。