跟WCF相关的事务协议有三个。

1.1. Lightweight protocol

这是个轻量级的本地事务协议，限制管理在一个AppDomain中的事务。不能跨AppDomain边界传播事务，也不能跨服务边界传播事务。跟其他协议比，Lightweight protocol是最有效率的协议。

1.2. OleTx protocol

这个协议可用于跨AppDomain，进程和机器边界，管理两阶段提交的事务协议。这个跨边界的事务协议使用RPC，是二进制的，windows专有的协议，不能穿越防火墙，也不能用于与非windows系统的互操作。在windows环境下的局域网，OleTx协议是很好的分布式事务的管理协议。

1.3. WS-Atomic Transaction (WSAT) protocol

WSAT跟OleTx协议类似，也可以跨AppDomain，进程和机器边界，管理两阶段提交的事务协议。但WSAT不是微软的专有协议，此协议是微软、IBM、BEA等公司共同提出的工业标准。此协议也可用于Intranet中，但是更多的是用于在Internet环境下，或者跟非windows系统进行互操作的分布式事务。

说到WSAT协议这里有必要一下分布式事务的发展。

分布式事务：

分布式事务在企业应用中是很重要的一个方面，微软使用MSDTC作为分布式事务管理器，使用OleTx事务协议进行分布式事务管理，但是OleTx事务协议是微软的专有协议，不是公认标准。在分布式环境中异构系统的交互一定要有个公认同意的分布式事务标准才能在异构的系统中实现分布式事务的协调。

l OGM的XA事务规范

1994年，开放组织（Open Group）的 X/Open 分布式事务流程（DTP）模型，它定义了应用程序如何使用事务管理程序跨多个资源管理程序来协调分布式事务。如果事务是通过遵循 XA 的事务管理程序来进行协调的，则任何遵循 XA 规范的资源管理程序都可以参与该事务，因此就可以让不同厂商的事务产品可以共同工作。所有遵循 XA 的事务都是分布式事务。XA 既支持一步提交，也支持两阶段提交。

对象管理组（Object Management Group）的通用对象请求代理体系结构对象事务服务（Common Object Request Broker Architecture Object Transaction Service） -- 定义遵循规范的流程如何跨多个流程线程将事务上下文从一个流程传播到另一个流程。这种传播使得即使分布式对象运行于来自不同厂商的容器中，也可以在单个事务中合作。CORBA OTS 规范建立在 XA 规范的基础之上。

l OASIS的Business Transaction Protocol（BTP）标准

在 2001 年，一个由各大公司（包括惠普公司（Hewlett-Packard，HP）、甲骨文公司（Oracle）及BEA公司）组成的联盟开始着手创建 Organization for Advance Structured Information Systems (OASIS) Business Transaction Protocol（BTP）标准。

BTP 不是专门用于 Web 服务的事务处理协议，它的目的是它也能用于其他的环境中。因而，BTP 定义了事务性的 XML 协议，并且必须在规范中指定所有的服务依赖性。

BTP协议相对比较复杂，并且它把原子性事务和长时间运行的商业事务放在一起进行管理，这样它必须解决各种各样不同的问题。它是通过放松限制来这样做的，这表面上给人感觉灵活度很高，但是很多东西就留给实现者去实现了，导致使用比较复杂。

l OASIS的WS-Transactions

在BTP出现后，其他一些行业大公司，包括 IBM、Microsoft 和 BEA，又发布了它们自己的规范： Web 服务事务处理（WS-Transactions），由三部分组成WS-Coordination（事务协调器）、WS-AtomicTransaction（实现原子事务）、WS-BusinessActivity（实现长时间运行的商业事务）。WS-Transactions比BTP好的方面是它将事务协调器独立出来，另外用两个标准在WS-Transactions基础上分别实现原子事务和长时间运行的事务，这样简化了复杂性。

WS-Transactions是专门用于web services的事务规范。

2005年，WS-Transactions发布了第一个版本，Version 1.0。

2007年，WS-Transactions发布了Version 1.1，并被OASIS组织接受为标准，成为WS-*标准的一部分。

WCF支持的可互操作的分布式事务协议只有WS-Transactions，并且只实现了WS-Coordination、WS-AtomicTransaction，WS-BusinessActivity没被实现。

1.3.1. WS-Coordination

WS-Coordination它描述了一个可扩展的交流协议框架，该框架对分布式的请求进行其请求协议的判断与处理，处理后再将请求向下方的业务处理模块进行分发。

该框架最大特点是其能够以系统流程代理的身份来处理请求。当不同的请求，无论是内部的同系统的请求或外部的异构系统的请求，经过该框架处理后，再其原有的特殊的传输代理层上添加了符合本系统信息流规则的本地协议。也就是本系统允许已经存在的事务、工作流或其他服务的请求隐藏其自身独特的传输协议，并可顺利运行于异构式的系统环境中。

当前WS-Coordination稳定的版本是1.1，同样是OASIS于2007年发布的国际标准。现在1.2版本也在起草过程之中。WS-Coordination规范的具体实现需要开发中在基于XML的配置文件中引入WS-Coordination规范的命名空间，如指定<xs：schema>字段的值为ws-addr.xsd。由于是基于XML文件来实现，WS-Coordination规范易于实现，且对日后的扩展支持度高。

通过WS-Coordination的使用，一方面通过附加统一的本地协议，在使用不同通信协议的请求到来时，进行统一的协议处理，加快了请求的处理速度，提高了系统的松耦合性；另一方面WS-Coordination规范所定义的框架加强了系统的异构性，使系统不因请求所使用的协议不同而无法处理，这提升了系统整体的兼容性，加强了系统的综合服务能力。

1.3.2. WS-AtomicTransaction

WS-AtomicTransaction 定义了一组特定的协议，这组协议可以插入 WS-Coordination 模型，以实现传统的两阶段原子事务处理协议。注意到原子的两阶段模型只是就涉及的服务而言的非常重要。提供服务的站点或基础体系结构可能大肆宣传两阶段提交，但是却使用一些其他的企业内部模型，比如补偿模型或版本模型。这种自由使简单的两阶段提交模型对于长期运行的 Internet 计算更有用。

WCF实现了WS-AtomicTransaction协议，事务管理器是由MSDTC实现，也就是说在WCF中可以使用WS-AtomicTransaction协议进行分布式事务的管理，并跟其他实现了WS-AtomicTransaction的异构分布式事务互操作。

1.3.3. WS-BusinessActivity

WS-BusinessActivity 定义了一组特定的协议，这组协议可以插入 WS-Coordination 模型，以实现长期运行的、基于补偿的事务处理协议。

WS-BusinessActivity定义的是long-running事务，所谓long-running事务是指那些企业业务流程，需要跨应用、跨企业来完成某个事务，甚至在事务流程中还需要有手工操作的参与，这类事务的完成时间可能以分计，以小时计，甚至可能以天计，这类事务也被称为SAGA。

这类事务如果按照事务的ACID的要求去设计，势必造成系统的可用性大大的降低。试想一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。

WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。

目前的WCF中未实现WS-BusinessActivity，在WCF 4.0 beta2中也为实现，估计在WCF 4.0正式版中也不会实现WS-BusinessActivity协议。

2、事务管理器

管理事务必须有相应的协议外，还必须有个事务管理器，事务管理器通过相应的事务协议对本机的事务进行管理。如果同一个事务需要跨机器，则每台参与事务的机器的事务管理器之间进行相互协调共同完成一个分布式事务。

2.1. LTM

轻型事务管理器Lightweight Transaction Manager，只能管理本地事务，事务在一个AppDomain内。LTM使用Lightweight protocol管理两阶段提交的事务。LTM只能管理单一的可持久化的资源，如果有两个以上的可持久化资源登记到事务中，LTM将被升级到DTC管理器。