轉自：http://www.ibm.com/developerworks/cn/webservices/ws-soa-axis2-1/index.html

Deepal Jayasinghe (deepal@apache.org), 高級軟件工程師, WSO2

2006 年 12 月 28 日

Apache Axis2 是 Apache Axis SOAP 項目的后繼項目。此項目是 Web 服務核心引擎的重要改進，目標是成為 Web 服務和面向服務的體系結構（Service-Oriented Architecture，SOA）的下一代平臺。作為一個干凈的可擴展的開放源代碼 Web 服務平臺，它正逐漸受到廣泛的關注。Axis2 的體系結構高度靈活，支持很多附加功能，如可靠消息傳遞和安全性等。

引言

Web 服務的歷史非常悠久，在其發展期間經歷了多次迭代。第一代 Web 服務是受到高度控制的交互，可以視為僅是對可行性的測試。Apache SOAP 是第一代中值得注意的 SOAP 引擎之一，主要用作“概念驗證”，而根本沒有考慮性能。第一代 SOAP 引擎的整個目的是為了讓人們認識到 Web 服務是一個理想的選項。

不久，第一代 SOAP 引擎獲得了回報。越來越多的公司開始對此產生興趣，SOA 的概念逐漸成形?？梢詫⒋穗A段稱為第二代 Web 服務，它要求更好更快的 SOAP 引擎。發現和定義等方面已經得到標準化，并需要 SOAP 引擎來支持這些標準。Axis 是這些第二代 SOAP 引擎之一。

現在，第二代 Web 服務的時代已經接近尾聲。Web 服務現在的要求非常高，Web 服務領域的參與者也非常多。用于控制 Web 服務交互的不同方面的涉及內容已得到標準化。第三代 Web 服務要求使用更快、更可靠的 SOAP 引擎——現有的 Axis 已不足以滿足此要求。Axis2 應運而生，填補了這一空白。

Axis2 體系結構

Axis2 具有模塊化體系結構，由核心模塊和非核心模塊組成。據說，Axis2 核心是純 SOAP 處理引擎，并沒有包含 Java™ API for XML-based RPC (JAX-RPC) 概念作為其核心的一部分。同時，Axis2 體系結構的設計充分考慮了以下原則：

• 邏輯和狀態分離，以提供無狀態處理機制，因為 Web 服務是無狀態的。
• 所有信息位于一個信息模型中，允許對系統進行掛起和恢復。
• 能夠在不更改核心體系結構的情況下擴展功能，能以最小或沒有核心更改的情況下直接支持新 Web 服務規范。

Axis2 核心體系結構包括以下核心和非核心組件：

• 核心組件
  • XML 對象模型 (AXIOM)
  • SOAP 處理模型：處理程序框架
  • 信息處理模型：上下文和描述
• 其他組件
  • 部署模型
  • 傳輸
  • 客戶機 API
  • 核心生成模型

您可以在圖 1 中看到這些組件。

圖 1. Axis2 體系結構關系圖

Axis2 主要特性

Axis2 不僅是 Apache 的新 Web 服務框架。它還體現了從 Axis 1.x 系列獲得的經驗和最近兩年在 Web 服務領域的發展。推出 Axis2 的主要原因之一是從速度和內存方面獲得更好的性能——不過還添加了一些新特性和功能。大部分新特性都是為了提高 Axis2 的易用性，并同時保留通過各種方式擴展功能的空間。大部分新功能所添加到的主要領域如下所示：

1. 新 XML 對象模型 (AXIOM)
2. 基于消息傳遞的核心
3. 經過改進的部署模型
4. 可插入數據綁定
5. 新客戶機 API
6. 信息處理模型

新 XML 對象模型：AXIOM

正如上面提到的，與 Axis 1.x 相比，Axis2 構建于全新的體系結構之上。引入 Axis2 的主要原因之一是獲得合適的 XML 處理模型。Axis 1.x 使用 DOM 作為其 XML 表示機制，但使用 DOM 的缺點是，需要在內存中保存完整的對象層次結構（與傳入消息對應）。對于小消息，這將不是問題，但對于大型消息就是問題了。為了克服此問題，Axis2 引入了新的 XML 表示形式作為其基礎。

Axis2 對象模型（AXIs2 Object Model，AXIOM）是 Axis2 的基礎，任何 SOAP 消息在 Axis2 中都表示為 AXIOM。AXIOM 相對于其他 XML 表示形式的優勢在于，它基于 pull 解析器技術，而其他大多數則基于 push 解析器技術。pull 與 push 的主要不同之處在于，在 pull 技術中，調用者對解析器具有完全控制權，可以要求下一個事件；而對于 push，當要求解析器繼續處理時，它將觸發事件，直到達到文檔最后為止。

由于 AXIOM 基于 pull 解析器技術，因此具有“隨需應變構建”功能，僅在被要求時才會構建對象模型，而且，如果需要，可以直接從 AXIOM 訪問基礎 PULL 解析器并對其加以使用，而不用構建對象模型（Object Model，OM）。

基于消息傳遞的核心

Axis2 核心是純 SOAP 處理引擎，并不了解數據綁定、傳輸、WSDl 等內容。Axis2 核心的主要功能是處理傳輸消息，并將其交付給目標應用程序。與 Axis 1.x 一樣，Axis2 也具有用于擴展其主要功能的處理程序概念。

階段和階段規則 階段是一個或多個處理程序的邏輯集合，有時候階段本身也充當處理程序。Axis2 引入了階段概念，以方便地對核心功能進行擴展。在 Axis 1.x 中，如果您希望向處理程序鏈添加處理程序，需要更改全局配置文件，但對于 Axis2， 您并不需要進行此工作，因為階段和階段規則可解決此問題。階段規則用于指定如何在階段內對給定處理程序集進行排序。圖 2 說明了階段如何組成流。

Axis 1.x 并沒有異步 Web 服務調用的概念，它完全綁定到請求-響應調用，但在 Axis2 中卻是另一番景象。Axis2 體系結構能夠支持在客戶端和服務器端同時支持異步調用。同時，Axis2 也支持請求-響應樣式的調用，但這會以兩個異步調用的方式進行。在 Axis2 中，進入系統的消息可能有也可能沒有響應，應該注意，Aixs2 支持 WSDL 2.0 中定義的所有八種消息交換模式（Message Exchange Patterns，MEP）。

Axis2 具有流的概念，流是階段的集合，而階段是處理程序的集合。根據給定方法調用的 MEP，與其關聯的流的數量可能會有所變化。如果僅傳入的 MEP 對應方法只具有一個流，則稱為 inflow；而對于傳入-傳出，則具有兩個流——inflow 和 outflow。在大多數情況下，inflow 從傳輸偵聽器開始，到消息接收方處結束，而 outflow 能以不同的方式開始，大多數情況下都在傳輸發送方處結束。

消息接收方 如果消息在沒有出現問題的情況下通過執行鏈，則引擎會將消息轉交給消息接收方來進行業務邏輯調用，此后，將由消息接收方調用服務并在必要的情況下發送響應。圖 3 說明了消息接收方如何適合執行鏈。

圖 2. 流中的階段


圖 3. Inflow 和消息接收方

新部署模型

Axis 之前的版本沒有處理好 Web 服務部署中涉及的用戶友好因素，因此開發了 Axis 1.x，其主要目的是為了進行 Web 服務概念證明。因此，在 Axis 1.x 中，用戶必須手動調用管理客戶機，并更新服務器類路徑，然后重新啟動服務器，以應用更改。這個有點麻煩的部署模型對新手肯定是一道障礙。Axis2 經過了精心的設計，能夠克服此缺點，并提供靈活、用戶友好、可方便進行配置的部署模型。

Axis2 部署引入了類似于 Java™ 2 Platform Enterprise Edition (J2EE) 部署機制的概念，開發人員可以在其中將所有類文件、庫文件、資源文件和配置文件一起打包為存檔文件，并將其放置在文件系統中的指定位置。

熱部署 和熱更新 的概念并不是新技術術語（對于熟悉 Web 服務平臺的人更是如此），但對于 Apache Axis 則是一個新特性。因此開發了 Axis2 來提供進行“熱”部署的空間。

熱部署：在系統啟動并運行時部署服務的功能。系統可用性在實時系統或業務環境中非常重要。如果系統停機（即使很短的時間），損失會很大，可能會影響業務的生存期。不過，會同時需要向系統添加新服務，如果可以在不關閉服務器的情況下完成，則是一個極大的進步。因此 Axis2 對此問題進行了處理，提供了 Web 服務熱部署功能，可以在不必關閉系統的情況下部署新 Web 服務。所需要進行的工作就是，將所需的 Web 服務存檔放入到存儲庫的 services 目錄中。然后，部署模型將自動部署服務，并進行提供。

熱更新：在不必關閉系統的情況下對現有 Web 服務進行更改的能力。這是一個重要的特性，是測試環境中需要的一個功能。不過，在實時系統中使用熱更新并不明智，因為熱更新可能導致系統進入未知狀態。此外，還可能丟失該服務的現有服務數據。為了防止發生這種情況，Axis2 的熱更新參數缺省設置為 false。

新部署模型

Axis 之前的版本沒有處理好 Web 服務部署中涉及的用戶友好因素，因此開發了 Axis 1.x，其主要目的是為了進行 Web 服務概念證明。因此，在 Axis 1.x 中，用戶必須手動調用管理客戶機，并更新服務器類路徑，然后重新啟動服務器，以應用更改。這個有點麻煩的部署模型對新手肯定是一道障礙。Axis2 經過了精心的設計，能夠克服此缺點，并提供靈活、用戶友好、可方便進行配置的部署模型。

Axis2 部署引入了類似于 Java™ 2 Platform Enterprise Edition (J2EE) 部署機制的概念，開發人員可以在其中將所有類文件、庫文件、資源文件和配置文件一起打包為存檔文件，并將其放置在文件系統中的指定位置。

熱部署 和熱更新 的概念并不是新技術術語（對于熟悉 Web 服務平臺的人更是如此），但對于 Apache Axis 則是一個新特性。因此開發了 Axis2 來提供進行“熱”部署的空間。

熱部署：在系統啟動并運行時部署服務的功能。系統可用性在實時系統或業務環境中非常重要。如果系統停機（即使很短的時間），損失會很大，可能會影響業務的生存期。不過，會同時需要向系統添加新服務，如果可以在不關閉服務器的情況下完成，則是一個極大的進步。因此 Axis2 對此問題進行了處理，提供了 Web 服務熱部署功能，可以在不必關閉系統的情況下部署新 Web 服務。所需要進行的工作就是，將所需的 Web 服務存檔放入到存儲庫的 services 目錄中。然后，部署模型將自動部署服務，并進行提供。

熱更新：在不必關閉系統的情況下對現有 Web 服務進行更改的能力。這是一個重要的特性，是測試環境中需要的一個功能。不過，在實時系統中使用熱更新并不明智，因為熱更新可能導致系統進入未知狀態。此外，還可能丟失該服務的現有服務數據。為了防止發生這種情況，Axis2 的熱更新參數缺省設置為 false。

模塊體系結構

正如上面提到的，Axis2 也具有處理程序的概念，但與 Axis 1.x 相比，指定和部署處理程序的方式有一些變化。在 Axis 1.x 中，要添加處理程序，需要首先更改全局配置文件，然后需要重新啟動系統，并沒有在運行時更改處理程序鏈的動態方法。

為了克服這個問題和增加新特性，Axis2 引入了 Web 服務擴展或模塊的概念；其中模塊的主要工作是對核心功能進行擴展。在 Axis 1.x 中，可以通過向處理程序鏈添加處理程序來實現此目標。與 Axis 1.x 處理程序鏈相比，使用模塊的優勢在于，您可以在根本不改變全局配置文件的情況下添加新模塊。同時，模塊是一個自容器，其中可以包含處理程序、第三方庫、模塊相關資源和模塊配置文件。

模塊的狀態 模塊具有兩個狀態：available 和 engaged。將模塊放入存儲庫中，此模塊就為 available 狀態，而它的處理程序都不在處理程序鏈中。模塊可以隨時參與到系統中。參與就是將其處理程序添加到處理程序鏈（或流），因此一旦使模塊參與系統，它就處于 engaged 狀態了。

可以將模塊作為存檔文件部署，Axis2 為模塊采用了一個新擴展文件名 .mar。模塊存檔文件中最重要的文件是模塊配置文件或 module.xml。除非具有 module.xml 文件，否則該模塊就是一個錯誤模塊。模塊配置文件主要用于指定處理程序及其階段規則，因此讓模塊參與系統后，根據階段規則不同，處理程序將被放置在不同的流上——inflow 或 outflow。

這個思路非常簡單。或許您需要支持 WS-Addressing 或 WS-Security。然后您必須下載對應的模塊，并將其放置到 Axis2 存儲庫的 modules 目錄中。您可以在部署時通過向 axis2.xml（Axis2 全局配置文件）添加以下條目使模塊參與系統，或在運行時通過使用各種方法（如使用 Axis2 Web 管理控制臺或 handlerfor exsample）使模塊參與到系統中：

<module ref="ModuleName">

新客戶機 API

異步或非阻塞 Web 服務調用是目前 Web 服務中的一個主要需求。同時，還存在一些以非阻塞方式調用 Web 服務的方法。第一個是客戶機編程模型，在此模型中，客戶機能在不阻塞其應用程序的情況下以非阻塞方式調用服務。第二個方法是傳輸級非阻塞調用，其中的調用是在兩個傳輸協議之間發生的?？梢允?SMTP 之類的兩個單向傳輸協議，也可以為兩個 HTTP 之類的雙向傳輸協議。Axis2 客戶機 API 同時支持上述兩個非阻塞調用方案。

Axis2 引入了用于調用服務的非常方便的客戶機 API，此 API 包含兩個類，分別名為 ServiceClient 和 OperationClient。ServiceClient API 專門用于只需要發送和接收 XML 的普通用戶，而 OperationClient 旨在供希望處理 SOAP Header 和其他一些高級任務的高級用戶使用。通過使用 ServiceClient，您只能訪問 SOAP 主體或有效負載。當然，可以添加 SOAP Header，但無法從服務客戶機檢索 SOAP Header。為了實現此操作，您將需要使用 OperationClient。

ServiceClient 具有以下用于調用服務的 API：

• sendRobust
• fireAndForget
• sendReceive
• sendReceiveNonBlocking

sendRobust：此 API 的思路是將 XML 塊發送給 Web 服務，而不考慮其響應。不過，如果出現了錯誤，您將也需要知道此情況。因此，此 API 用于調用并不返回值但可能引發異常的服務。

fireAndForget：此 API 只用于發送 XML 塊，但并不考慮響應或異常，因此這是調用僅傳入的 MEP。

sendReceive：調用具有返回值的服務。這是最常用的 API 之一，可以用于調用傳入-傳出 MEP。

sendReceiveNonBlocking：以非阻塞方式調用服務。服務具有返回值時，可以使用此方法。為了使用此方法，您必須傳遞一個回調對象，將在調用完成后立即調用回調對象。

正如前面提到的，OperationClient 用于高級用戶，使用 OperationClient 要求您對 Axis2 有良好的了解。在 ServiceClient 中，您并不需要知道有關 SOAP 信封或消息上下文的任何信息，但對于 OperationClient，您必須在調用服務前自己創建它。使用 OperationClient 創建和調用服務涉及到以下步驟：

• 創建服務客戶機
• 然后使用創建的服務客戶機創建操作客戶機
• 創建 SOAP 信封
• 創建消息上下文
• 將 SOAP 信封添加到消息上下文
• 將操作上下文添加到操作客戶機
• 調用操作客戶機
• 如果有響應，則從操作客戶機獲取響應消息上下文

總結

Axis2 將不會對 Web 服務概念進行驗證，而將提供更好的 SOAP 處理模型，且與 Axis 1.x 及其他現有 Web 服務引擎相比，其速度和內容方面的性能都得到很大的提高。此外，它還為用戶提供了方便的 API，用于部署服務、擴展核心功能和新客戶機編程模型?，F在已經進入了 Axis2 的時代了。