一、 事务概述
1、 事务协议
跟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管理器。
2.2. KTM
Vista和windows2008引入了内核事务管理器Kernel Transaction Manager (KTM)，
Windows Vista中还引入了两个主要的事务资源，事务NTFS和事务注册表，称作核心资源kernel resource managers (KRM)，KTM可以管理这两类资源。
事务性 NTFS，也称为 TxF，使用TxF可以将文件操作纳入到事务管理中，在事务中的的文件操作将同事务中的其他事务资源一样在事务前后保持一致性。
同样事务性注册表，也称作TxR，注册表的操作也可以纳入到事务管理中。
KTM跟LTM一样，使用Lightweight protocol管理两阶段提交的事务，只能管理本地事务，事务在一个AppDomain内，只能管理单一的可持久化的资源。
2.3. DTC
DTC可以管理任何跨越执行边界的事务，跨AppDomain，跨进程，跨机器，跨服务。DTC可以使用OleTx 或者WSAT事务协议。
DTC既可以管理本地事务，更重要的是它能够管理跨边界的服务。
在使用WCF的场景下，每台运行WCF服务的机器都默认使用DTC。DTC建立一个新事务，并跨机器把事务传播到其他机器，发起事务的机器上的事务为根事务，这个机器上的DTC就要负责这个分布式事务的协调任务，负责启动事务，提交事务，和回滚事务。
事务管理器可使用的事务协议：
| Protocal | LTM | KTM | DTC |
| Lightweight protocol | Yes | Yes | No |
| OleTx protocol | No | No | Yes |
| WS-Atomic Transaction | No | No | Yes |
3、 事务资源
在事务范围内，可纳入事务管理的资源，即可以在事务正常执行后提交生效，在事务失败可以回滚恢复到事务启动前状态的资源成为事务资源。最常见的事务资源就是常用的数据库操作。但是在vista开始引入了两个核心事务资源：TxF事务文件和TxR事务注册表。
可用的事务资源：
3.1. 新sql server事务资源
Sql 2005或sql 2008的事务资源是新sql server，LTM事务管理器可以管理这类事务。
3.2. 核心事务资源
Vista开始引入的TxF事务文件和TxR事务注册表。可以对文件和注册表进行事务性操作。KTM可以管理这类资源。
3.3. 传统事务资源
SQL Server 2000, Oracle, DB2, 和MSMQ这类资源是传统的事务资源，这些资源只能由DTC事务管理器进行管理。
事务管理器可管理的事务资源：
| Resource | LTM | KTM | DTC |
| 新Sql Server事务资源 | Yes | No | Yes |
| 核心事务资源 | No | Yes | Yes |
| 传统事务资源 | No | No | Yes |
4、 事务管理器的升级
每个WCF中启动的事务都是先由LTM事务管理器管理，一旦事务中出现现有事务管理器无法管理的资源或情况，WCF会提升事务管理器的级别。分别从LTM升级到KTM，最高级别升级到DTC。事务管理器可以多次升级，事务管理器一旦升级后不能降级。
事务管理器的升级规则：
