http://wenku.baidu.com/view/f3126425ccbff121dd3683b3.html
在現在的企業應用程序的開發中，Web 服務已經越來越普遍。然而，從傳統意義上來說，它們還沒有達到和所支持的服務相同的水平。當構建 J2EE 應用程序，特別是事務服務的時候，企業依賴于這些服務。本文概述了事務服務是如何在一個使用 Java Transaction API 的 J2EE 環境中的 Web 服務事務的幫助下，與 Web 服務實現無縫連接的。
本文簡要地概述了這項新的 Web 服務技術和已被證實的傳統的事務技術，解釋了它們是如何能夠跨分布式的 J2EE 環境甚至跨不同的事務體系結構來實現互操作的。
本文假設您已經對事務服務的概念（例如，ACID properties、提交/回滾、事務劃分，等等）的理解達到中級水平。要想了解事務服務的進一步信息，特別是 JTS，請參考文章 Java theory and practice：Understanding JTS —— An introduction to transactions。這篇文章可以在 developerWorks 上找到（請參閱 參考資料）。同樣，我也想要推薦一本關于事務的更全面信息的好書，它就是由 Philip Bernstein 和 Eric Newcomer 合著的 Principles of Transaction Processing（請參閱 參考資料）
什么是 Java Transaction API（JTA）？
JTA 是事務服務的 J2EE 解決方案。本質上，它是描述事務接口（比如 UserTransaction 接口，開發人員直接使用該接口或者通過 J2EE 容器使用該接口來確保業務邏輯能夠可靠地運行）的 J2EE 模型的一部分。
JTA 具有的三個主要的接口分別是 UserTransaction 接口、 TransactionManager 接口和 Transaction 接口。這些接口共享公共的事務操作，例如 commit() 和 rollback() ， 但是也包含特殊的事務操作，例如 suspend() ， resume() 和 enlist() ，它們只出現在特定的接口上，以便在實現中允許一定程度的訪問控制。例如， UserTransaction 能夠執行事務劃分和基本的事務操作，而 TransactionManager 能夠執行上下文管理。本文僅僅需要您對 JTA 有一個基本的了解。
JTA 的好處？
JTA 是一個定義明確的事務服務，向 J2EE 應用程序開發人員提供一種可以直接使用的服務。作為選擇，一個應用程序也可能這樣部署，容器將代替開發人員來管理事務行為。在后一種情況下，開發人員能夠全神貫注于他們的應用程序的業務邏輯，同時由 J2EE 容器來負責事務邏輯。
模型明確的事務服務的好處是對于每個單獨的事務總是維持四個 ACID 特性。盡管這是一個實現相關的問題，WebSphere Application Server 提供為每個導入的或者導出的事務保護這些 ACID 特性的能力，而不管并發的事務數目是多少。
JTA 的限制？
經歷過所有的事務體系結構，想要有效地將一組事務傳送給其他并不共享同樣模型的事務服務，同時保持原子的工作單元，是非常困難的。在我們的案例中，建模的 JTA 運行在 Java Transaction Service（JTS） 之上，JTS 處理輸入和輸出事務傳送的請求。
因為 JTS 是一種由 CORBA 定義的對象事務服務（OTS）的 Java 實現，它只能夠與另一個 OTS 模型連接。因此， 一個事務只能傳送給另一個 OTS-兼容的目標，典型地即另一個 J2EE 實現。因為 JTA 和 JTS 規范沒有對這些接口的底層實現加以限制 （只要它們符合模型），事務可以安全地在兩個 J2EE-兼容的應用程序服務器之間傳送，而沒有丟失它們的 ACID 特性的風險。然而，J2EE 服務器并不必須處理非 J2EE 調用。
某些 J2EE 服務器可能是例外；例如，WebSphere Application Server 將正確地處理一個與 CORBA 兼容事務相關聯的輸入的 CORBA 請求，將這個事務傳送給線程，然后在它的上下文里執行事務工作。然而，在大多數情況下，當您試圖在事務模型之間移動的時候，您不得不超越 JTA 和 JTS，把目光投得更遠，在這里 Web 服務出現了。
什么是 Web 服務？
Web 服務是一種能夠作為應用程序一部分部署在可訪問的服務器上供內部和外部客戶使用的對象。Web 服務由它的 Web 服務描述語言（WSDL）來描述。它定義了一個使用基于 XML 調用（典型地使用 SOAP 協議）的 Web 服務的輸入和輸出參數的用法。例如，客戶端可以查看已經由服務器發布的 WSDL，然后構造客戶端代碼來調用 Web 服務。一旦完成，它就能夠通過將 SOAP 消息傳遞給 Web 服務的一個方法來調用它。在這條 SOAP 消息中包括諸如方法 名稱的信息以及任何它所需要的參數。返回值將在另一條 SOAP 消息里被傳送回來，再由客戶提取出來。
使用 Web 服務的好處？
Web 服務由哪種語言編寫而成并不重要，因為 WSDL 沒有定義語言或者編程的模型相關的細節（例如，Java 和 J2EE 技術）。這就給了 Web 服務的作者和客戶端的作者選擇他首選的解決方案 的靈活性。
讓我們來比較一下 Web 服務和 Enterprise JavaBean（EJB）組件。EJB 組件要求 RMI-編譯的代碼，以便使客戶端能夠訪問，所以 它能夠像它的代理一樣創造本地的存根（stub）對象。因此，這將需要在每一次它們改變的時候，向所有的客戶端重新分配存根（stub）。 無論如何，和 Web 服務一起您將使用 WSDL，所以客戶端能夠構造它們自己的客戶端調用代碼，在本地類路徑上不需要服務器的類來執行調用。這個模型提供了一個非常巧妙的方法調用過程。 EJB，作為 J2EE 模型的一部分，必須使用 Java 客戶來調用，最好是一個 J2EE 管理的客戶端。另一方面，Web 服務可以被任何客戶端代碼所調用，這個代碼能夠構造一個結構良好的 SOAP 請求。因而，舉例來說，一個部署在 J2EE 服務 器上的 Web 服務能夠使用 C++ 客戶來調用。
Web 服務的限制？
因為 Web 服務請求（通過 HTTP 的 SOAP）的性質與其他的方法調用（例如，一個使用通過 IIOP 的 RMI 的 EJB 調用）差別很大，支持執行分布式事務的代碼直到最近才可獲得。這已經成為在 使用 Web 服務作為分布式事務企業應用程序一部分時，主要的問題。本質上，Web 服務不能運行在 Web 服務調用之前開始的事務上下文 中，也不能將一個事務上下文傳送給另一個組件。
那么，問題是什么呢？
如果 Web 服務被用于工業，必須確保它們在事務環境 中運行的時候，以可靠的和可預知的方式工作。直到現在，Web 服務只能夠使用獨立于其他組件的事務——在 Web 服務的方法范圍里劃分的 和服從它的底層的事務實現的規則——并且物理上不能離開 Web 服務或者進入另一個 Web 服務。企業應用程序具有始終在企業組件間流動 的事務。這需要成為 Web 服務的標準來確保它們能夠被正確地使用，通過利用 Web 服務的功能僅僅忽略在我們的所有嚴格的企業應用 程序中依賴的和使用的事務支持來避免改變您的編程風格。
那么，解決方案是什么呢？
解決方案就是一種稱為 Web 服務事務（WS-Transaction） 的新技術。它能夠調整事務的上下文。這個上下文可以被 Web 服務、其他的諸如 EJB 的 J2EE 組件、甚至其他支持 WS-Transaction 的 非 J2EE 事務服務使用。
WS-Transaction 是一個規范。它擴展了 Web 服務協調（WS-Coordination）規范來定義一種支持原子事務的協調。
什么是 WS-Coordination
WS-Coordination 是一個協調框架來使分布的參與者 能夠在他們個體行動之上就一個通用的結果達成協議。
本質上，這意味著分布式的參與者（例如，在不同機器上的兩個應用程序服務器）將能夠使用 WS-Coordination 把每個參與者 的行為集在合一起，進一步地，并且通過確保它們完全同意對于在這個協調上下文里它們各自執行的所有行為均產生單一的結果，來 進一步管理這些行為。否則，則不能以一個受控的方式來完成這些功能。
協調上下文可以被看作是一個標識符，行為執行在這個標識符之下。作一比較，這個概念非常類似于事務上下文。當事務工作完成， 在事務上下文里管理它，當調用這個上下文去確定或會滾時這個工作完成。協調上下文包含的附加信息是一個協調標識符、關于協調類型的 詳細資料以及包括端口信息以便協調服務能夠被訪問的協調協議。在下面定義了這些術語。
協調服務，或者 協調器（Coordinator）， 進一步由三個服務組成： 激活服務（activation service）、 注冊服務（registration service）和 協調協議（coordination protocol） 服務。激活服務支持 CreateCoodinationContext 操作來允許新的協調上下文存在。注冊服務支持 Register 操作來允許參與者 在協調上下文中執行工作。協調協議服務支持協調協議的使用，這個協議定義了協調器（Coordinator）和參與者之間的行為和通信。
協調類型是一個協調行為的固定的集合，這個集合詳細說明了協調協議的集合以及協調器（Coordinator）應該如何驅動完成。 WS-Transaction 規范描述了兩個協調類型—— 原子事務（Atomic Transaction）（AT）和 業務協定（Business Agreement）（BA）。 這些協調類型中的每一個都包括協調協議。例如，原子事務（Atomic Transaction）協調類型包括像 two-phase commit protocol（Durable2PC）和 phaseZero protocol（Volatile2PC）這樣的協調協議。 您可以希望在支持原子事務的環境中使用這兩個協議。
業務協定（Business Agreement）協調類型提供了一種不同的功能類型。它被設計成用于更長的時幀。而不像原子事務，正常地您 與它聯系一個非常短的生命期。業務協定協議（Business Agreement protocol）的一個例子就是它自己，被稱作業務協定（Business Agreement） 它是一個補償協議。
WS-Coordination 和 WS-Transaction 之間是什么關系？
WS-Coordination 是基本的框架，使參與者之間活動的分布式結果成為可能。WS-Transaction 定義了協調類型，例如原子事務（Atomic Transaction），協調類型使用 WS-Coordination 框架來定義規則。在協調器（Coordinator）和參與者通信時，它們必須遵循這些規則。兩者之間的這個區別很重要。
兩個應用程序和一個協調器（Coordinator）之間主要的協調流程如下面的 圖 1所示。
- App1 向在協調器上的激活服務提出一個請求。
- 協調器開始一個新的活動，使用它的
CoordinationContext （協調器的 XML 消息）來對 App1 做出響應。 - App1向注冊服務提出請求來注冊使用協調協議X。
- App1 以它期望的方式調用 App2，傳遞
CoordinationContext 給協調器。 - App2 向注冊服務提出請求（使用諸如端口信息的參數，它們 可以在 App1 傳遞的
CoordinationContext 中找到）來注冊使用協調協議Y。 - App2結束它的工作，將控制返還給 App1，活動結束。
- 協調器使用協議 X 類型消息響應 App1。
- 協調器使用協議 Y 類型消息響應 App2。
協調器調解
在一個現實世界的情況中，Web 服務可能是事務的和分布式的，協調器的發起者（ App1）將 CoordinationContext 傳遞給任何它所期望的活動中的參與者（ App2）。這個上下文的接收者有兩種選擇：它們可以使用已經創建好了的協調器（ Ca），或者如果它們愿意，也可以在初始的 CoordinationContext 中傳遞創建的新的協調器。然后，第二種選擇將新的協調器（ Cb） 作為 App2的代理協調器。它將包括與協調器 Ca相同的活動標識符，但是當 App2向它的協調器 Cb注冊 Durable2PC 協議的時候，它的請求直接傳送給了協調器 Ca。 類似地，在結束時，準備和提交消息在最終到達 App2（它已經注冊過 Durable2PC 協議）之前將從協調器 Ca傳遞給協調器 Cb。
請參閱 WS-Transaction 規范的 4.1 節 AT3.1 Example Atomic Transaction Message Flow，在那里您將看到一個應用程序和調解的協調器之間的 WS-Coordination 流程的非常好的示例（請參閱 參考資料）。
Web 服務事務：原子事務（WS-AtomicTransaction）
WS-AtomicTransaction 是一種對于原子事務的特殊的協調類型，它提供了一組協調協議。這些協調協議是：
- Completion
- CompletionWithAck
- Volatile2PC
- Durable2PC
- OutcomeNotification
當協調上下文創建以后，協調類型被指定，但是協調協議直到注冊時才被指定。任何參與者可以注冊任意數目的協調協議，應該發送和接收 由協議定義的恰當的消息。例如，如果一個參與者在協調器中注冊了 Durable2PC 協議，當完成時一條準備消息將被發送給這個參與者，它們將被認為以與正常的事務資源相似的方式投票。想要了解這里每個協議的信息和它們的狀態圖，請查閱 WS-Transaction 規范， 第 4 節 AT3 Coordination protocols（請參閱 參考資料）。
如何能將 JTA 事務和 WS-AtomicTransaction 一起使用？
因為 JTA 和 JTS 是實現相關的，我將使用的這個示例是 WebSphere Application Server V5.0.2 和 WS-Transaction Tech Preview。這個場景將有兩臺機器，每個上都運行有應用程序服務器，如 圖 2 所示。 應用程序服務器A部署并運行一個 Bean Managed Transaction（BMT）EJB 組件。應用程序服務器B部署并運行一個 Web 服務。 EJB 組件通過使用 JTA 提供的接口 UserTransaction 開始一個事務。它對 XA-compliant database 執行事務工作（步驟 1），然后使用 SOAP/HTTP 向在應用程序服務器B上的 Web 服務發送一個請求（步驟 2）。Web 服務對 XA-compliant database 執行工作（步驟 3），然后返回到 EJB 組件（步驟 4），由它再次使用 UserTransaction 接口來提交事務。所有由 EJB 和 Web 服務對數據庫執行的事務都已經被包含在一個活動的范圍里，這個活動是由協調器恰好在調用 Web 服務（步驟 2）之前創建的，它已經被提交，同時保存著所有的 ACID 特性，它就好像是單一的工作單元。
讓我們來看看下面的兩個領域——J2EE 領域和 Web 服務領域。在 J2EE 領域里，使用的事務模型是 JTA。在 Web 服務領域里， 使用的事務模型是 WS-AtomicTransaction。WebSphere Application Server 把一個 Java Web 服務看作是一個 J2EE 對象，因此也就 意味著，Web 服務的實現屬于 J2EE 領域，而調用屬于 Web 服務領域。在 WebSphere 領域，正確地驅動協議總是正在被使用的模型 （JTA 或者 WS-AtomicTransaction）的責任。
圖 2 展示了 在一個事務企業應用程序中包含 Web 服務是多么的容易，同時也展示了對于沒有費一行代碼麻煩就在導入的事務上下文中運行這個 Web 服務的用戶來說，它又是多么的無縫。
請注意：The EJB 組件正運行在一個受管理的環境中（EJB 容器）并且 Web 服務是符合 JSR 109。
它只能和 JTA 一起工作嗎？
WS-Coordination 依靠它的基于XML的調用來 利用它本身是 Web 服務的優勢。因為用來調用 WS-Coordination 操作的協議是 SOAP，消息內容是 XML 格式的純文本。這意味著，當使用 HTTP 傳遞給 Web 服務時，將不能僅僅通過 SOAP 包本身來確定客戶的詳細資料，例如編程語言。因此，WS-AtomicTransaction 將能夠與任何其他的使用任何支持 WS-AtomicTransaction 的編程語言編碼的事務服務相連接。
在近來的一個由 IBM 和 Microsoft 主辦的 Web 服務演示上，展示了 WS-AtomicTransaction 的這個跨事務服務和編程語言的互操作性。 圖 3 展示了一個示范這項技術的場景。
在 圖 3 中有一個.NET 服務器開始一個非 JTA 事務，向兩個 WebSphere 應用程序服務器和另外一個.NET 服務器提出了 Web 服務調用請求。每個應用程序服務器都使用它們的底層事務服務來執行事務工作。每次您能夠使用 WS-Transaction 調用一個您將轉到的 Web 服務。當發起者完成事務，您使用 WS-Transaction 技術來協調每個參與者，確保它們都已完成，就好像它們是單一的工作單元似的。
總結
在本文中，您已經了解到 WS-Coordination 和 WS-Transaction 的基本概念。到現在為止，Web 服務還不能在分布式環境里使用事務。WS-Transaction 允許 Web 服務執行事務工作，這個事務工作作為更廣泛的活動生成組件、應用程序服務器、甚至實現的一部分，正如在 IBM 和 Microsoft Web 服務演示中所展示的。
在 WS-Transaction 的支持下，我們能夠可靠地使用 Web 服務作為我們的企業應用程序的一部分，因為它已經為事務支持嵌入到其他的企業組件里。