在年前寫一個幾篇關於分布式事務的文章，實際上這些都是為了係統介紹WCF事務處理體係而提供的相關的背景和基礎知識。今天發最後一篇，介紹分布式事務采用的兩種協議，即OleTx和WS-AT，內容比較枯燥，但對於後續對WCF事務處理框架進行深入剖析的係列文章來說，確是不可以缺少的。總的來說，基於WCF的分布式事務采用的是兩階段提交（2PC：Two Phase Commit）協議。具體來說，我們可以選擇如下兩種事務處理協議實現WCF的分布式式事務，它們按照各自的方式提供了對兩階段提交的實現。

• OleTx：OleTx采用RPC作為通信的手段，通信消息采用二進製編碼方式，所以OleTx是最為高效的分布式處理協議。但是也正是由於OleTx自身的通信和編碼方式，使它成為了專用於Windows平台下的分布式處理協議。也就是說，當一個分布式事務的所有參與者均基於Windows平台，OleTx是最好的選擇，如果有任何一個非Windows的事務資源參與進來，OleTx就無能為力了。說白了，OleTx並不具有跨平台的特質；
• WS-AT：WS-AT（WS-Atomic Transaction）是WS-*大家庭中的一員，是由結構化信息標準促進組織（OASIS：Organization for the Advancement of Structured Information Standards）製定的基於分布式事務的標準。對於WCF來說，WS-AT彌補了OleTx不具備跨平台的不足。

限於篇幅的問題，本書不會對OleTx具體的實現進行介紹，有興趣的讀者可以從MSDN網站下載OleTx事務管理的規範文檔，地址為https://msdn.microsoft.com/en-us/library/cc229116%28PROT.10%29.aspx。接下來，我們來討論WS-AT是以怎樣的方式來對分布式事務的管理的。實際上，WS-AT建立在另一個WS規範之上，即我們將要介紹的WS-Coordination。

一、 WS-Coordination

以SOAP和WSDL為核心的Web服務規範定義了一套完善的協議以實現Web服務的互操作，使我們可以將若幹的參與者組合起來構成一個分布式的計算單元（Distributed Computational Unit），我們將這些計算單元稱為分布式活動（Distributed Activity）。這些活動可能在結構上非常複雜，各個參與者之間具有複雜的關係；也可能由於業務流程的複雜性或者需要用戶交互，需要很長的執行時間。分布式事務和工作流就是兩個典型的分布式活動。

由於組成這個分布式計算單元或者活動的參與者隸屬於不同的廠商，有效地協調這些參與者必須依賴於一個開放的、大家均遵守的標準或者規範，我們本節介紹的WS-Coordination就是這樣一個規範。WS-Coordination有一個稱為“結構化信息標準促進組織（OASIS：Organization for the Advancement of Structured Information Standards）”的標準製定，到目前為止先後推出了兩個版本：V1.1和V1.2，本節我們討論的是WS-Coordination 1.1。

WS-Coordination通過一個協調器（Coordinator）和若幹協調協議（coordination protocol）定義了一個擴展的框架去協調組成一個分布式活動的所有參與者。這樣一個框架使這些參與者達成一種一致性的協定，合力完成這個依賴於所有參與者的活動。WS-Coordination為分布式活動協調定義了一個統一的、抽象的處理協議，其本身並不用於解決具體的協調問題。基於WS-Coordination定義的標準，一係列的具體標準會被陸續製定出來意解決具體的分布式活動的協調問題。WS-AT（WS-AtomicTransaction）和WS-BA（WS-BusinessActivity）就是兩個基於WS-Coordination的協調協議。接下來，我們就按照逐層深入的方式介紹基於WS-Coordination的分布式活動協調機製。

1、基於協調器（Coordinator）的協調模型

WS-Coordination的協調模型以協調器（Coordinator）為中心，協調器由一係列進行協調操作的服務構成。分布式活動的參與者調用本地協調器相應的服務，各個分布的協調器相互通信從而構建了一個統一的協調環境，並將所有的參與者納入其中。

圖1 基於協調器（Coordinator）的協調模型

我們說一個協調器可以看成是一個協調服務的容器，包含在該容器中的所有服務按照其不同的作用可以分成如下三個類型，不同服務在協調器中的構成如圖2所示。

• 激活服務（Activation Service）：當一個分布式活動開始的時候，初始化該活動的參與者調用激活服務的CreateCoordinationContext創建協調上下文（Coordination Context）；
• 注冊服務（Registration Service）：的參與者通過調用注冊服務的Register方法參與到相應的協調協議之中；
• 協議服務（Protocol Service）：一個協調器會有一係列基於具體協調協議（比如WS-AT和WS-BA等）的服務。

圖2 協調器的服務構成

接下來我們詳細介紹基於WS-Coordination協議如何實現將分布式活動在不同的參與者之間進行傳播，整個過程如圖3所示。整個活動具有兩個參與者：Application 1和Application 2，它們具有各自的協調器Coordinator1和Cooridiatior2，AS和RS分別表示協調器的激活服務和注冊服務。假設協調整個活動的具體的協調服務為Q（你可以假設這就是我們接下來要介紹的WS-AT），而PS1和PS2分別表示給予該協調類型的協議服務。由於PS1和PS2最終實現了對整個活動的協調管理，所以整個流程的目的在於如何讓PS1和PS2能夠互相通信。說得更加具體一點，按照WS-Addressing規範，服務通過終結點引用（Endpoint Reference）來定位，整個流程的目的在於交換PS1和PS2的終結點引用，使之能夠彼此調用。

步驟1：活動的初始化者Application1調用本地的協調器Coordinator1的激活服務AS1創建協調上下文。我們稱該上下文為Context1，Context1包含了如下信息：活動標識、協調器Coordinator1的注冊服務RS1的終結點引用和協調類型Q。

步驟2：Application1將創建的協調上下文Context1發送到另一個活動參與者Application2。

步驟3： Application2以此協調上下文Context1作為輸入，調用本地協調器Coordinator2，並創建新的協調上下文Context2。Context1和Context2具有相同的活動標識和協調類型，但是注冊服務終結點指向本協調器的注冊服務RS2。

步驟4：Application2根據接收到的協調上下文中的協調類型信息Q確定具體的協調協議，調用注冊服務RS2將PS2注冊到Coordinator上。注冊的結果是Application2和PS2進行了終結點引用交換，從而建立起兩者之間的邏輯關係。

步驟5： RS2根據接收到的協調上下文Context1得到RS1的終結點引用，將PS2的終結點引用作為輸入調用RS1注冊到Coordinator1上，RS1將PS1的終結點引用返回。到此為止，PS1和PS2實現了相互之間的終結點引用的交換。

圖3  基於WS-Coordination協議對一個分布式活動進行協調的全過程

2、從消息交換看激活服務和注冊服務

從上麵的步驟我們不難看出，整個處理流程主要涉及到對協調器兩個服務的調用，即激活服和注冊服務。接下來，我們從消息交換的角度對這兩個服務的調用進行進一步的介紹。在這之前我們先來看看介紹一下上麵我們頻繁體積的協調上下文（Coordination Context）。

協調上下文（Coordination Context）

當一個分布式活動需要從一個參與者傳播到另一個參與者，相應的協調上下文文需要傳播到目標參與者，換句話說，協調上下文的傳播是分布式活動傳播的手段。協調上下文的傳播通過應用定義的機製實現，比如將協調上下文至於SOAP消息相應的報頭中。協調上下文包括活動標識、協調的具體類型、注冊服務的終結點地址以及其他一些擴展信息。順便提一下，https://docs.oasis-open.org/ws-tx/wscoor/2006/06是WS-Coordination 1.1對應的命名空間。

激活服務（Activation Service）

激活服務的目的就是創建協調上下文，所以它隻有一個唯一的操作CreateCoordinationContext。當活動初始化參與者需要創建協調上下文時候，向激活服務發送相應請求，指定具體的協調類型已經以及其他相關信息。下麵的XML片斷表示了一個CreateCoordinationContext請求消息的結構：

   1: <CreateCoordinationContext ...="">

   2:   <Expires> ... </Expires>?

   3:   <CurrentContext> ... </CurrentContext>?

   4:   <CoordinationType> ... </CoordinationType>

   5:   ...

   6: </CreateCoordinationContext>

其中隻有<CoordinationType/>結點是必須的，表示具體的協調類型，比如WS-AT（https://docs.oasis-open.org/ws-tx/wsat/2006/06），其他均為可選元素。<Expires/>結點的值是一個以正數表示的過期時限，單位是毫秒，自該上下文被接收的那一刻算起。<CurrentContext>結點表示的是當前的協調上下文，如果為空則創建一個全新的上下文，否則創建一個與之關聯的上下文（具有相同的活動標識）。通過指定當前上下文，讓創建的上下文和當前上下來建立起一種上下級的依賴關係。此外，CreateCoordinationContext請求消息還可以根據具體協調類型的需要添加任意擴展的元素。

當激活服務接收到CreateCoordinationContext後，根據請求的內容創建相應的協調上下文，並將其置於CreateCoordinationContextResponse消息中返回。CreateCoordinationContextResponse消息的主體結構如下麵的XML片斷所示。其中CoordinationContext就是創建出來的協調上下文。

   1: <CoordinationContext> ... </CoordinationContext>

   2:   ...

   3: </CreateCoordinationContextResponse>

注冊服務（Registration Service）

當分布式活動的參與者從本地協調器獲取了協調上下文，就可以調用相應的注冊服務將具體的協調服務注冊到該上下文對應的活動中。此外，位於活動參與者與上級協調器之前的中介協調器（圖3中的Coordinator2）通過調用上級協調器的注冊服務進行相類似的注冊操作。

注冊服務具有一個唯一的Register操作，注冊者（活動參與者或者下級協調器）發送相應的Register請求，並指定具體協調協議的標識和參與方協調服務的終結點引用。Register請求消息主體部分結構如下。

   1: <Register ...="">

   2:   <ProtocolIdentifier> ... </ProtocolIdentifier>

   3:   <ParticipantProtocolService> ... </ParticipantProtocolService>

   4:   ...

   5: </Register>

下麵是WS-AT基於Volatile2PC（WS-AT定義了兩個2PC協議：Volatile2PC和Durable2PC）協議的Register請求消息，其中參與方Volatile2PC服務終結點引用的地址為https://Adventure456.com/participant2PCservice。

   1: <Register>

   2:   <ProtocolIdentifier>

   3:     https://docs.oasis-open.org/ws-tx/wsat/2006/06/Volatile2PC

   4:   </ProtocolIdentifier>

   5:   <ParticipantProtocolService>

   6:     <wsa:Address>

   7:       https://Adventure456.com/participant2PCservice

   8:     </wsa:Address>

   9:     <wsa:ReferenceParameters>

  10:       <BetaMark> AlphaBetaGamma </BetaMark>

  11:     </wsa:ReferenceParameters>

  12:   </ParticipantProtocolService>

  13: </Register>

當注冊服務接收到Register請求後，會返回相應的RegisterResponse消息，該消息中包含己方相應的協調服務的終結點引用。RegisterResponse消息主體部分結構如下：

   1: <RegisterResponse ...="">

   2:   <CoordinatorProtocolService> ... </CoordinatorProtocolService>

   3:   ...

   4: </RegisterResponse>

二、WS-AT

WS-Coordination為處理不同類型的協調定義了一個統一的、可擴展的框架，而原子事務（AT：Atomic Transaction）是眾多協調類型中最為典型的一種。原子事務協調的對象是那些運行生命周期相對短暫的活動（Short Lived Activity），是之保持“要麼全做，要麼都不做（All or Nothing）”的屬性。WS-AT（WS-Atomic Transaction）在WS-Coordination的基礎上，為原子事務這樣一種協調類型定義了若幹協議，使隸屬於不同平台或者廠商的事務處理係統可以進行互操作。

WS-AT規範的製訂者也是結構化信息標準促進組織（OASIS），目前的版本有兩個：WS-AT 1.0和WS-AT1.1，我們主要介紹後者。由於WS-AT建立在WS-Coordination之上，完全按照WS-Coordination規定的方式進行協調上下文的創建和服務注冊，我們先來簡單介紹一下基於WS-AT的協調上下文。

1、WS-AT協調上下文（Coordination Context）

當一個分布式事務的參與者需要將當前事務傳播給另外一個事務參與者的時候，需要調用本地協調器的激活服務創建基於原子事務協調類型的協調上下文，並將上下文通過消息交換的方式進行傳播。如果采用SOAP消息，需要按照SOAP綁定將上下文作為SOAP報頭進行傳輸。下麵的XML展現的一個簡單的原子事務協調上下文的結構。

   1: <CoordinationContext>

   2:   <Expires>100000</Expires>

   3:   <Identifier>urn:uuid:f0660731-4eb8-4ed2-a7bd-1b3a68d2443a</Identifier>                  <CoordinationType>https://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType>

   4:   <RegistrationService>

   5:     <wsa:Address>

   6:       https://Business456.com/tm/registration

   7:     </wsa:Address>

   8:     <wsa:ReferenceParameters>

   9:       <myapp:PrivateInstance>1234</myapp:PrivateInstance>

  10:     </wsa:ReferenceParameters>

  11:   </RegistrationService>

  12: </CoordinationContext>

其中表示協調類型的<CoordinationType>的值為https://docs.oasis-open.org/ws-tx/wsat/2006/06，代表基於WS-AT 1.1的原子事務協調類型。這個URI也這正是WS-AT 1.1的命名空間。<Expires>結點代表上下文過期的時限，單位是毫秒，自上下文被創建或者被接收的那一刻算起，這實際上也就是分布式事務超時時限。<RegistrationService>是創建該上下文協調器注冊服務的終結點引用。

在介紹WS-Coordination的時候，我們談到協調上下文通過調用協調器激活服務的CreateCoordinationContext操作獲得。在CreateCoordinationContext請求中，我們是可以製定一個現有的協調上下文的，在這種情況下，注冊服務會創建與該上下文相關聯的上下文，這種關聯即它們具有相同的上下文標識。反映在具體事務場景中，就是這樣：事物初始化者調用原子事務協調器的激活服務創建一個全新的上下文，而事務後續參與者在創建上下文時候，會將接收到的上下文作為輸入，調用本地的協調器創建與之管理的上下文。兩個原子事務協調器建立起一個上下級的關係，兩個上下文具有的相同的標識即事務的分布式ID。

2、 原子事務協議

WS-AT為原子事務處理定義了如下的協議：Completion和兩階段提交（2PC）。

完成（Completion）

分布式事務的初始化應用使用Completion協議通知協調器提交或者中止開啟的原子事務。當事務結束後，最終的狀態（被中止或者被提交）返回到該應用。Completion協議的協調器必須是原子事務的根協調器。對於非根協調器的注冊請求，注冊服務將會返回“Cannot Register Participant”WS-Coordination錯誤（Fault）。注冊Completion協議采用的協議標識為：https://docs.oasis-open.org/ws-tx/wsat/2006/06/Completion。

兩階段提交（2PC）

該協議通過協調原子事務的所有參與者，並對整個事務作出最終的決定（提交或者中止），並確保最終的結果抵達所有的參與者。根據事務參與者的不同，兩階段提交協議具有兩個變體：

• Volatile 2PC：事物的參與者管理易失型事務資源（Volatile Transactional Resource），注冊Volatile 2PC協議采用的協議標識為：https://docs.oasis-open.org/ws-tx/wsat/2006/06/ Volatile2PC；
• Durable 2PC：事物的參與者管理持久化型事務資源（Durable Transactional Resource），注冊Volatile 2PC協議采用的協議標識為：https://docs.oasis-open.org/ws-tx/wsat/2006/06/ Durable2PC。

限於篇幅的問題，我們不能夠對WS-AT的三種協議進行深入的討論，有興趣的讀者可以從OASIS的網站上直接下載WS-AT的官方文檔。後續博文中我將來介紹WCF基於事務的編程問題，敬請期待！

分布式事務係列:
談談分布式事務之一：SOA需要怎樣的事務控製方式
談談分布式事務之二：基於DTC的分布式事務管理模型[上篇]
談談分布式事務之二：基於DTC的分布式事務管理模型[下篇]
談談分布式事務之三: System.Transactions事務詳解[上篇]
談談分布式事務之三: System.Transactions事務詳解[下篇]
談談分布式事務之四: 兩種事務處理協議OleTx與WS-AT