SOA 事務管理，第 1 部分：事務協調服務

事務幾乎是所有業務交互的必要部分。事務的存在是為了確保適當地記錄下特定業務運作的所有部分，如果任何一個單獨的部分失敗了，那么為了維持數據一致性，事務在整體上應該失敗。由于基于 Web 服務的特性，面向服務體系架構的到來為事務管理增加了一層復雜性，服務常常是異步的、無狀態的、分布式的，且不透明的。為了讓商家從面向服務的方法中獲得充分的價值，服務開發人員必須了解事務管理的機制，包括資源募集、業務功能協調、一致性控制，及恢復。

這個兩部分的文章討論了在復雜的面向服務的體系架構中實現事務的特性，以及周圍的問題。此處是第一部分，我通過一個事務協調服務（Transaction Coordination Service，TCS）來介紹事務管理，其必須具有組織并控制復雜的業務運作的能力，包括資源募集、業務功能管理、并發控制，及失敗恢復。第二部分將介紹事務控制服務（Transaction Control Service）的候選架構。

自動化及業務運作

一百年前，業務運作是勞動密集的。辦公室中充滿了繁忙，忙碌的職員必需跟蹤每個業務交互并且維護一個用于訂單、交付，和支付的有組織且一致的記賬系統。他們利用人工技術，如雙份的會計賬目，用以確保在錯誤實質上影響到業務之前檢測并分辨出它們。一個業務“事務”是完整的賬目記錄，從拿到訂單，到客戶為產品或服務的最終支付。

現今，軟件自動化已經允許以幾乎無人的方式來處理業務運作。在沒有人工干涉的情況下，接收 Web 訂單、評估收費，并交付產品。因此，在維持一個高水平的記賬精確性的同時，對商家來說，處理操作已經更加快捷且更加便宜。事實上，事務已經復雜得多，并且在對客戶的最終交付時，可能涉及許多公司。例如，設想一個光纜電信服務，客戶從電信廠商那里購買衛星頻道接入、寬帶因特網、蜂窩服務，及因特網游戲預定。該廠商依次與其他廠商簽署協議，提供每一種服務并且分享最終付款的一部分。缺少了某種形式的自動化監控，管理這樣復雜的業務交互會十分困難（且昂貴）。因而，業務運作現在可能會涉及許多獨立的軟件系統，以分布式的異步方式進行交互。

面向服務的體系架構（Service-Oriented Architectures，SOA）的引入將此互操作性帶到甚至更高層的復雜性。在基于 SOA 的系統中，服務是以松散耦合且獨立于平臺的方式由一個系統提供給另一個系統的（經常來自多個競爭的公司）。這些服務可以提供任意層次的業務功能，從訂單管理，到記賬，到存貨清單，到執行。通過將一組服務收集到一起，就可能建立一個任意復雜的業務運作，所有的都跨越分布式的網絡無縫地交互。當來自一個操作的業務是另一個所需時，錯綜復雜的部分出現了：例如，存貨清單分配需要一個訂單號，其順次生成一個用來計算月記賬綜述的記賬系統所使用的記錄。確保此環境下的數據一致性需要事務協調服務（Transaction Coordination Service，TCS）的某種形式的事務管理。TCS 必須有能力組織并控制復雜業務運作，包括資源募集、業務功能管理、一致性控制，及失敗恢復。

協調分布式的服務

處理分布式的服務需要非常了解要自動化的業務功能。面向服務的體系架構靈活性（這樣服務可以快速地換入換出）的代價是組織并控制業務活動的額外費用。每個服務只提供整個業務事務的一小部分，結果是一個操作進入另一個的處理中（例如訂單執行和記賬）。要成功地創建復雜、相互依賴的一系列服務，服務協調者（Services Coordinator）（也就是，系統架構師）必須定義每個服務接口，那些服務創建并消費的工作產品，以及處理異常條件的規則。

第一步是定義業務功能，由信息自動化支持的業務過程的一個確定部分。利用 XML 說明業務流和參與者的規范，最近由商業伙伴聯盟（包括 IBM、BEA Systems、Microsoft、SAP AG，和 Siebel Systems）發布。該規范稱為 Business Process Execution Language for Web Services (BPEL4WS) ¹ 。該規范允許以獨立于平臺的方式定義業務功能，類似于 WSDL（Web 服務描述語言（Web Services Description Language））對 Web 服務的聲明。當然，實現 BPEL 定義的客戶系統必須解析并解釋規范的 XML 標簽，但是此方法比對服務描述和序列信息硬編碼要靈活得多。業務事務由另一組標準來描述 —— WS-Transaction —— 業務功能綁在一起（WS-Coordination）形成要么是工作的獨立單元（WS-AtomicTransaction），要么是長期進行操作的集合（WS-BusinessActivity） ² 。

業務功能協作

在 SOA 團隊中，業務功能定義用來生成確定的工作產品的分布式服務的集合。例如，lookupOrder（參見圖 1）是一個返回詳述客戶訂單信息的確定的數據結構的業務功能。一個更復雜的實例是 finalizeOrder（參見圖 2），在其中執行一系列操作來實現訂單并更新記賬信息。業務工作流中的每個活動由引入的服務、輸入參數列表，及輸出數據定義。

圖 1. 查找訂單服務

圖 2. 訂單服務定案

活動定義（服務和消息）

大多數服務由 WSDL 描述定義，如圖 3 所示，其中包含支持的消息類型和服務綁定信息的描述。 ³ 服務由六個主要要素定義：數據類型、輸入或輸出 消息、消息傳遞端口類型、綁定協議、綁定地址端口，及命名的服務。消息數據類型和結構可能遵從一個現有的業務數據傳遞定義，例如各種各樣的 ebXML 實現， ⁴ 或者可能由每個服務提供者定義。綁定協議經?；?SOAP（簡單對象訪問協議（Simple Object Aclearcase/" target="_blank" >ccess Protocol））或 HTTP（超文本傳輸協議（Hypertext Transport Protocol）），但是面向服務的體系架構不要求所有服務使用單獨的協議，只要求協議是定義了的。連接端口和服務信息也是典型定義了的，盡管如果使用了 UDDI （Universal Description and Discovery and Integration）注冊，那么活動定義可能包括用于鑒別來自注冊中心的有效服務的信息。

圖 3. WSDL 服務模型

功能組織（工作組）

一旦確定了業務功能工作單元及服務，下一個步驟就是將這些活動組織到有意義的工作組中。業務功能工作組是擁有整體統一目的的業務功能集合。 ⁵ 例如 OrderManagementGroup，如圖 4 所示，將負責引入搜索、檢索、創建、修改，和取消客戶訂單的業務活動。這些服務中的每一個可能由一個有序的服務集執行（一個訂單創建業務功能首先檢查，看訂單還沒有存在），包括多種已經傳遞的消息?；顒拥慕M織還提供事務劃分的起始點（在下面討論），在此，特定的業務運作在事務的情況下執行。工作組可能更進一步地鏈接到鏈式操作中，在此，要么執行串行的操作（例如訂單創建、處理，及實行），要么執行并行的操作（例如存貨分配、賬單生成，及賬目更新）。

圖 4. 服務組（服務劃分）

協調點（事務劃分）

一旦確定了業務活動，并且定義并將服務集分了組，那么下一個步驟就是指示 事務劃分點。不是所有的業務運作都需要事務管理，只有那些包含多個操作，需要以所有操作必須成功完成的方式協調的。在圖 5 中所示的實例中，LookupCustomer 和 CreateCustomerRecord 沒有包裝到事務中，但 FinalizeCustomerOrder 參與了一個 Create Order Transaction 劃分了的服務集。在此實例中，FinalizeCustomerOrder 服務使用 Transaction Management Service（TCS）來控制其他四個服務的順序操作，并提供對 TCS 進行的每個操作所必要的消息（顯示為 FinalizeCustomerRequest 的附件）。

事務協調圖用來顯示確定的事務的構成、處理順序（順序的 vs. 并行的），及嵌套的事務。在圖 5 中的實例中，GenerateShippingRequest 是 Assign Inventory Item 服務所創建的嵌套事務。嵌套事務出現的原因可能有許多，例如，如果打算將服務獨立使用，或作為更大事務環境的一部分。注意到嵌套的事務可以使用同一個 TCS，確保如果嵌套事務失敗了，那么父事務也將失敗。

當事務處理完結時，TCS 輪詢事務的所有參與者，決定該事務是否應該提交。在一個兩階段提交協議中，TCS 首先輪詢參與者，看是否它們準備好了，然后依次向每個參與者發布提交。如果事務參與者沒有準備好，那么所有其他的參與者得到回滾命令。在參與的服務察覺不到事務（舉例來說，無狀態的）的情況下，TCS 將調用補償操作（也就是，“取消”）。

圖 5. 提交訂單事務劃分

處理控制（串行的或并行的）

如上面所提到的，事務控制可能是串行的、并行的，或兩者的組合。定義為串行的事務必須按照特定順序發生，且典型的是在來自一個操作的完成的事務環境信息是另一個的必需輸入時（舉例來說，當訂單號記錄在存貨分配或記賬記錄參考上的時候）需要串行事務。另一方面，并行操作是互相獨立的，因此可以同時執行。例如，由空中旅行、飯店逗留，及汽車租賃所組成的旅行計劃可能并行執行，因為一個操作的結果不是完成另一個所必要的，如圖 6 所示。當事務的一個部分是串行的，而其他部分是并行的時，會出現組合的處理。此類型的事務的一個實例是光纜產品的訂單，在此第三方供應商獨立供應。

圖 6. 并行事務處理

處理環境（內部映射、外部映射）

最后，TCS 要求在事務開始之前分配事務環境信息映射。這意味著服務協調者（Service Coordinator）必須知道每個服務所需的信息，并確保每個服務調用都配備必要的事務環境。在之前圖 5 中所示的串行實例中，CreateOrder 服務生成一個其他兩個服務所需的接口上的一部分，OrderID。服務協調者該提供內部映射和外部映射信息來考慮要添加到隨后的服務調用中的環境信息。如圖 7 所示，外部映射將顯示 CreateOrder 服務創建的 OrderID 映射到 Billing 和 Inventory 操作的輸入內部映射。此映射讓 TCS 將環境信息傳播到事務的所有單元。

圖 7. 事務環境映射

實現 TCS

面向服務的體系架構包含一組服務，每個服務需要特定系統資源來執行其工作。一個預定服務可能需要有權安排信息，而一個發貨服務可能需要調用上述的預定服務來安排一個特定的發送給客戶的存貨條目。服務可以聲明其功能、向注冊中心提交此信息，并提供安全通信。TCS 可以在事務過程中利用此信息，定位正確的服務集、發現其功能，并依次向每個服務傳遞環境信息。

資源發現和注冊（UDDI）

TCS 可以通過兩種方式了解到哪個服務參與到事務中：每種都是計劃性的，通過服務協調者在給 TCS 的注冊消息中指定服務細節，或者通過在注冊中心中進行查詢。UDDI (Universal Description Discovery and Integration) 注冊規范設計讓服務實現者連同集成信息（例如安全性、事務意識、恢復等）一起注冊服務。

資源功能聲明（策略）

事務中涉及的服務需要對 TCS 聲明其功能。 ⁶ 特別地，一個服務必須聲明其處理事務的能力，或者如果它不能（舉例來說，CreateOrder 服務必須擁有 CancelOrder 服務），就要提供補償服務。此外，功能聲明說明了安全策略，以便多種服務可以參與安全事務通信。

安全（驗證或授權）

服務負責實現安全性。安全策略 ⁷ 定義用于在 TCS 和服務之間創建一個安全訪問通道的聲明。策略定義了安全協議及 TCS 和服務之間的安全互通性所需的信任通道。

分布式環境中的并發控制

除了服務所需的其他資源管理以外，處理并發的能力是糾正事務管理的關鍵。每個參與 TCS 中事務的服務必須能夠確保事務過程中執行的變更不被其他事務覆蓋。 ⁸ 例如，一個事務開始時，用新購買的產品更新客戶訂單。在該訂單處理時，另一個事務開始取消某些變更。如果這些事務沖突了，那么要取消的產品將被替代，其他將要被供應的可能取消 —— 一點也不管客戶要的內容！

因此，當服務參與事務時必須實現某種形式的數據加鎖或發布策略。這與關系數據庫中為了維護多個并發事務所使用的操作類似。這些策略包括檢查每個操作的時間戳及為進度確定的正確順序，以及什么時候或如何鎖定記錄（舉例來說，樂觀的 vs 悲觀的加鎖）。最后，當資源出現死鎖（一個服務持有另一個服務需要的鎖，反之亦然）時，服務將需要實現某種形式的死鎖消除。 ⁹

恢復及重試

TCS 的最后一個需求是在事務失敗時實現重試及恢復。要考慮兩種事務失?。旱谝环N是所有服務都能夠參與事務時，而第二種是包括一個或多個不能參與事務的服務。在第一種情況下，TCS 可以使用兩階段提交協議 ¹⁰ 來管理事務步驟。在第二種中，服務必須擁有補償服務來考慮第一種動作的取消。第一種情況的一個典型的例子是所有的服務訪問標準的關系數據庫（其實現了兩階段提交），或者由 OpenGroup X/Open transaction 語義定義。 ¹¹ 第二種（不幸地是更加通用）的一個實例是在服務完成處理時提交操作 —— 例如對飯店預定利用飯店的 Web 服務接口。

TCS 也可以實現重試語義。在這種情況下，TCS 將長期執行的事務存儲到持久存儲設備上，并且試圖在較后的時間完成事務。例如，如果在購買旅行計劃的地方建立事務，那么航空預定部分也許在飯店、汽車、高爾夫、正餐、巡航等部分之前完成。TCS 可能在舍棄初始的航空預定之前推選重試任一或所有余下的事務單元。這是“保險的”事務的一個實例，TCS 將試圖通過多次重復提交失敗單元來完成事務。

在面向服務的體系架構中實現事務的挑戰

存在許多在面向服務的體系架構中實現事務管理才有的挑戰。首要的是服務自身的特性：服務是松散耦合的，所以它們試圖成為無狀態、異步、分布式，且不透明的。無狀態的服務意識不到事務狀態，因此如果事務失敗時，不能請求它們“回滾”一組變更。如果按照 Web 服務來實現一個服務，那么當前的協議利用 Internet 的異步特性，這意味著服務不能夠及時地對請求進行響應。對于并行操作，這不是一個因素，但考慮當事務是串行的且來自一個服務調用的信息可能是其他服務調用所需時。

以 Web 服務形式實現的服務是可以在任何位置訪問到的，因此它們是分布式的定義的，對潛在性、可靠性，和安全性的關注的引入影響了事務管理。

最后，服務只是由對 TCS 的確定接口可知的，在服務處理的內部沒有詳細信息。這導致“黑盒”使用模式，一個服務在不知道客戶端知識的情況下利用其他服務，因而傳播帶有二次影響的變更。對于事務，這可能意味著，作為事務一部分的服務可能調用了同是該事務一部分的另一個服務。這可能導致重要的并發問題，因為第一個調用可能更改了第二個所需的數據，導致一個很難跟蹤的問題。

假設存在所有這些挑戰，創建一個可靠的 TCS 對任何實現面向服務的體系架構的人來說都是困難的任務。TCS 必須能夠管理帶有嵌套、并發、安全、進度，及本文中所討論的所有其他問題的任意復雜的事務。因此一個可憐的服務架構師能做什么？本文的第二部分將通過介紹一個事務控制服務的候選架構來解決這些問題。