本文共 2083 字，大约阅读时间需要 6 分钟。
在一个基于SOA架构的分布式系统体系中，服务（Service）成为了基本的功能提供单元，无论与业务流程无关的基础功能，还是具体的业务逻辑，均实现在相应的服务之中。服务对外提供统一的接口，服务之间采用标准的通信方式进行交互，各个单一的服务精又有效的组合、编排成为一个有机的整体。在这样一个分布式系统中某个活动（Activity）的实现往往需要跨越单个服务的边界，如何协调多个服务之间的关系使之为活动功能的实现服务，涉及到SOA一个重要的课题：服务协作（Service Coordination）。而具体来讲，一个分布式的活动可能会执行几秒钟，比如银行转帐；也可能执行几分钟、几个小时、几天甚至更长，比如移民局处理移民的申请。事务，无疑是属于短暂运行服务协作（Short-Running Service Coordination）的范畴。
通过的介绍，我们知道了SOA真正需要的是一个能够协调服务操作直接（通过服务自身访问的资源）或者间接（通过被调用服务访问的资源）访问的所有资源的分布式事务管理系统，这是一个复杂的架构体系。WCF，作为Windows平台下基于SOA的分布式框架，对分布式事务提供全面的支持。不过，WCF并不是另起炉灶，而是充分地利用了Windows现有的事务控制基础架构。本节着重讨论Windows事务处理模型，首先来看看在这个模型中各个事务参与者各自扮演怎样的角色。
当基于LTM或者KTM的事务提升到基于DTC的分布式事务后，DTC成为了本机所有事务型资源管理器的管理者；此外，当一个事务型操作超出了本机的范围，出现了跨机器的调用后，本机的DTC需要于被调用者所在机器的DTC进行协助。上级对下级（包括本机DTC对本机所有资源管理器，以及上下级 DTC）的管理得前提是下级在上级那里登记，即事务登记（Transaction Enlist）。所有事务参与者，包括所有资源管理器和事务管理器（即DTC）在进行了事务等级完成之后形成了一个树形的层级结构，该结构的形成是后续的事务提供成为可能，因此我们将其称之为事务提交树（Transaction Commit Tree）。
不同于基于单一资源管理器的本地事务，在一个分布式环境中时实现一个涉及到多个资源管理器的分布式事务，实现事务的ACID四大属性，要麻烦得多。当事务初始化服务（应用或者组件，为了更佳贴近WCF，我们都称服务）完成所有相关的操作，决定提交该事务。对于分布式事务的提交，最终的结果有两个：如果所有的操作能够顺利完成，需要持久化的数据被相应的资源管理器写入到目标资源；如果任何一个环节失败，所有持久化资源管理器将数据恢复到原来的状态。分布式事务的整个提交过程，采用两阶段提交（2PC：Two-Phase）Commit协议完成。顾名思义，“两阶段提交”意味整个整个事务提交阶段分两个阶段，我们现在就来详细介绍分别在这两个阶段中，都在做些什么。
在.NET 1.x中，我们基本是通过ADO.NET实现对不同数据库访问的事务。.NET 2.0为了带来了全新的事务编程模式，由于所有事务组件或者类型均定义在程序集中的命名空间下，我们直接称基于此的事务为System.Transactions事务。System.Transactions事务编程模型使我们可以显式（通过）或者隐式（基于）的方式进行事务编程。
在System.Transactions事务体系下，事务本身通过类型类型表示。只有可提交事务才能被直接初始化，对可提交事务的提交驱动着对整个分布式事务的提交。可提交事务通过类型表示。
的定义中，信息的读者应该看到了一个叫做DepedentClone的方法。该方法对用于创建基于现有对象的“依赖事务（DependentTransaction）”。不像可提交事务是一个独立的事务对象，依赖事务依附于现有的某个事务（可能是可提交事务，也可能是依赖事务）。依赖事务可以帮助我们很容易地编写一些事务型操作，当环境事务不存的时候，可以确保操作在一个独立的事务中执行；当环境事务存在的时候，则自动加入其中。
确实能够使我们的事务控制变得非常的简单。实际上，在利用System.Transactions事务进行编程的时候，我们一般不会使用到可提交事务，对于依赖事务也只有在异步调用的时候会使用到，基于的事务编程方式才是我们推荐的。 正如其名称所表现的一样，TransactionScope就是为一组事务型操作创建一个执行范围，而这个范围始于创建之时，结束于被回收（调用Dispose方法）。