原帖地址：http://www.ibm.com/developerworks/cn/webservices/ws-apacheaxis2/

2007 年 2 月 26 日

討論 Apache Axis2 的各個組成部分，并了解其為何憑借模塊化和可擴展特性正逐漸成為下一代 Web 服務平臺。

引言

2006 年 5 月推出 Apache Axis2 1.0 是一個大的里程碑。Axis2 1.1 于 2006 年 11 月推出，提供了大量新功能（其中大部分都是其用戶最初提出的）以及大量錯誤修補程序（使其更加穩定）。：從最初的 Apache Axis 和 Apache SOAP 到目前的 Axis2，經歷了很大的發展。它不僅更高效、模塊化、基于 XML，而且具有靈活性和可擴展性，實現了安全性和可靠性等企業功能。Apache Axis2 的易用性和功能確實使其成為了下一代 Web 服務平臺。在本文中，您將了解目前已實現了哪些功能。您將看到一個支持新一代可互操作標準（如 WS-Security、WS-Reliable Messaging 和 WS-Addressing）的成熟產品。

Axis2 體系結構：組件視圖


圖 1. 組件視圖
圖 1. 組件視圖

AXIS 對象模型（AXIs Object Model，AXIOM）是 Apache Axis2 的 XML 對象模型。Axiom 之上的內核層包含引擎、模塊和部署框架。在 Axis2 的核心部分沒有特定于 Java™ 的概念。所有其他組件都在內核之上的層中。各種傳輸協議（如 HTTP 和 SMTP）和數據綁定（在 XML 和 Java 代碼之間進行轉換）并不在核心中，因為它們是可插入的，因此提供了很大的靈活性。所有其他相關技術（如 Java API for XML Web Services (JAX-WS)）都在 Axis2 之上的層次中。

我們現在將分析 Axis2 的以下組件：

  • AXIOM（新 XML 信息集表示形式）
  • 可擴展消息傳遞引擎
  • 可插入模塊體系結構
  • 經改進的部署模型
  • 新客戶機 API
  • 可插入數據綁定
  • 代表性狀態傳輸（Representational State Transfer，REST）支持

AXIOM

AXIs 對象模型 (AXIOM) 是一個 XML 對象模型，設計用于提高 XML 處理期間的內存使用率和性能，基于 Pull 解析。通過使用 Streaming API for XML (StAX) Pull 解析器，AXIOM（也稱為 OM）可以控制解析過程，以提供延遲構建支持。延遲構建是指 AXIOM 不完全構建對象模型，模型的其余部分基于用戶的需求構建。以下示例對此概念進行了說明：

假定某個用戶需要從 XML 輸入流中獲得第一個人的 <Location> 元素值，AXIOM 構建的對象模型將一直包含到 <Location> 元素結束的內容，而讓其他內容保留在流中：


清單 1. 對象模型的 AXIOM 部分構建
            <Persons>
            <Person>
            <Name>Dihini Himahansi</Name>
            <Sex>Female</Sex>
            <Location>Colombo, Sri Lanka</Location>
            <--- Object model is being built only up to this point
            </Person>
            <Person>
            <Name>Thushari Damayanthi</Name>
            <Sex>Female</Sex>
            <Location>Elpitiya, Sri Lanka</Location>
            </Person>
            </Persons>

這里的優勢在于，盡可能僅使用能滿足用戶的需求的內存。如果用戶希望訪問較大的文檔中前面的數個字節或數千字節，則延遲構建功能將改善該應用程序的內存需求情況。

可以從任何元素獲得 StAX 事件，而不管是否完整構建了對象模型。在有些情況下，Axis 2 中的此功能非常有用。例如，當 Axis2 作為中介傳遞時，如果需要僅讀取 SOAP 消息的 Header，AXIOM 將防止其讀取整個 SOAP 消息，使其具有很高的內存效率。另一個例子是，當 Web 服務實現能夠直接使用 StAX 事件時，由于采用了 AXIOM，Web 服務所需的內存非常小。

此外，AXIOM 內置了消息傳輸優化機制（Message Transfer Optimization Mechanism，MTOM）支持。對于 AXIOM 體系結構，可以通過實現 AXIOM 接口并將其插入到 Axis2 中來執行自己的對象模型。

由于 AXIOM 最初是作為 Axis2 的對象模型而開發的，因此 AXIOM 提供了構建于基礎 AXIOM API 之上的 SOAP 接口。這允許您使用 envelope.getHeaders 和 envelope.getBody 之類的便利方法查看 SOAP。

與其他廣泛使用的對象模型相比，AXIOM 已被證明更快速高效。有關對 AXIOM 進行的一些性能測試的信息，請參見參考資料。


回頁首


可擴展消息傳遞引擎

正如前面提到的，Axis2 是一個純 SOAP 處理器，并不依賴于任何 Java 特定的規范。例如，JAX-WS 將作為 Axis2 上的一個層實現，而不會進入核心部分中。


圖 2. 可擴展消息傳遞引擎
圖 2. 可擴展消息傳遞引擎

引擎通過傳輸協議接收到消息后，將調用之前注冊的一系列攔截器（稱為處理程序）。處理程序通常處理 SOAP Header 內的信息，不過并不限制同時對消息的其他部分進行處理。隨后會將消息傳遞給消息接收者——消息的最終接收方。消息接收者同時也負責對消息進行相應的處理，大部分時候都會將此消息傳遞給服務實現類進行處理。

Axis2 的管道模型

可以使用一組關系對 Axis2 的核心消息處理部分進行建模。Axis2 引擎的傳入消息會通過“In”管道。所有傳出消息都會通過“Out”管道。


圖 3. Axis2 的管道模型
圖 3. Axis2 的管道模型

消息交換模式（Message Exchange Pattern，MEP）
讓我們看一下客戶機和服務器之間的消息交換。如果客戶機需要從服務器獲得股票報價，則將向服務器發送請求消息，服務器將隨后向客戶機發送一條響應消息。從服務器的角度而言，它將接收一個“In”消息，發送一個“Out”消息。這是用于請求-響應方案的模式，名為 In-Out MEP。與此類似，客戶機可以向服務器發送 In-Only 消息來發出請求，例如訂閱郵件列表。

有關消息交換模式的更多信息，請參見 W3C 網站。

通過組合使用不同數量的 In 和 Out 管道，Axis2 可以處理任何 MEP。例如，可以使用一個 In 管道和一個 Out 管道來支持進行 In-out 交互。可以使用一個 In 管道來支持 In-Only 交互。這些管道之間的連接由消息接受者進行。

Axis2 可以處理 Web 服務描述語言（Web Services Description Language，WSDL）2.0 規范中定義的大部分 MEP，且可以擴展為支持任何自定義 MEP。

階段

每個 Axis2 管道內部被邏輯劃分為名為階段 (Phase) 的區域。（階段是管道中的處理程序邏輯集。）將按特定的方式對這些階段進行命名，以表示在該階段對消息的處理方式。例如，管道中的第一個階段是 TransportIn 階段，所有進行傳輸信息處理的處理程序都可能位于此處。Dispatch 階段中的處理程序將標識此消息的目標服務和操作。

這些階段都會有用處，特別是嘗試部署新處理程序時，因為我們可以指定處理程序需要在哪個階段中執行。

上下文層次結構

Axis2 環境需要在不同的級別保存信息。例如，整個引擎公用的信息應該在系統級別進行維護，而消息級別的信息應該保存在消息級別。有些信息是動態的，而有些信息是靜態的。為了處理這些不同的需求，Axis2 提供了上下文層次結構來在不同級別維護信息。


圖 4. 上下文層次結構
圖 4. 上下文層次結構

層次結構的左側包含所有動態信息，而右側則包含靜態信息（大部分都是從文件中讀取的）。

MessageContext 包含與所處理的消息相關的信息，而 OperationContext 包含此消息所屬的特定 MEP 相關的信息。ConfigurationContext 包含系統級的動態信息，而 AxisConfiguration 包含系統級的靜態信息（大部分都是從 axis2.xml 讀取的）。

調度

傳入 Axis2 引擎的每條消息都以特定服務和操作為目標。標識此服務/操作組合的過程稱為調度，Axis2 引擎提供了進行此工作的四種基本方法：

  1. 基于請求 URI 進行調度：有時候可以通過查看請求 URI 確定消息的目標服務。例如，通過請求 URI“http://myip/axis2/service/StockQuoteService/getQuote”可以確定，該消息的目的地是 StockQuoteService 的 getQuote 操作。
  2. 傳輸信息：可以將 SOAPAction HTTP Header 用于確定服務和操作。
  3. WS-Addressing Header：如果傳入消息包含 WS-Addressing Header，也可以將其用于進行調度。
  4. 如果 SOAP 主體的第一個子項的 QName 是使用 RPC 規則定義的，則也可以使用此名稱。

這些是 Axis2 引擎的一些基本功能。我們現在將了解模塊如何為 Axis2 提供擴展機制。


回頁首


可插入模塊體系結構

模塊為服務器提供了一個擴展機制。Axis2 中的每個模塊都包含一組相關的處理程序。例如，WS-Addressing 模塊將包含一組為 Axis2 引擎提供 WS-Addressing 支持的處理程序。Axis2 管理員可以下載 WS-Addressing 模塊，并將其部署到 Axis2 引擎中，從而為 Axis2 引擎添加 WS-Addressing 支持。module.xml 文件包含指定處理程序應屬于哪個管道和階段的規則。


圖 5. 可插入模塊體系結構
圖 5. 可插入模塊體系結構

模塊非常有用，因為在需要支持某個 WS-* 規范的情況下，可以下載并部署相應的模塊，而不必擔心處理程序應該歸入何處。模塊的擴展名為 .mar，指示其為模塊存檔 (module archive)。以下是支持已經構建的 WS-* 規范的幾個模塊：

  • Sandesha2 模塊：提供 WS-Reliable Messaging 支持
  • WS-Addressing 模塊：為 Axis2 提供 WS-Addressing 支持
  • Rampart 和 Rahas 模塊：提供 WS-SX（安全相關規范）支持
  • Kandula 模塊：提供 WS-AT 支持
  • Savan 模塊：提供 WS-Eventing 支持

模塊可用性和參與

模塊部署到 Axis2 引擎中后，它就“可用”，并能夠參與到系統中。模塊的參與可以在以下級別進行，具體取決于特定要求：

  • 系統級別：模塊將影響整個系統，此模塊中的處理程序將應用于傳入系統的所有消息。
  • 服務級別：此模塊中的處理程序將應用于以特定服務為目標的消息。這些處理程序應該始終部署在調度階段后。
  • 操作級別：此模塊中的處理程序將應用于以特定操作為目標的消息。這些處理程序應該始終部署在調度階段后。

部署服務后，可以通過在描述符中加入一個較小的條目來使模塊參與到服務中。


回頁首


經改進的部署模型

Axis2 現在支持將服務熱部署到 Axis2 引擎中。這就允許用戶在不用重新啟動服務器的情況下部署服務。服務應該存檔為 ZIP 文件，且在文件名中使用 .aar（Axis2 存檔，Axis2 archive）作為擴展名。服務存檔包含以下信息：

  • 服務實現類
  • Services.xml 文件描述其使用的消息接收者、所需的任何模塊和可用的操作
  • 可選依賴庫打包在 lib 文件夾內

可以將這些服務存檔文件復制到 Axis2 存儲庫中（其中包含所有服務和模塊），或通過 Axis2 所屬的管理控制臺進行更新。


回頁首


新客戶機 API

Axis2 可以采用兩種方式調用 Web 服務。ServiceClient API 是最簡單的方法，但為用戶提供的控制較少。OperationClient API 在調用期間提供了大量的控制。這兩個 API 都內置了基本 In-Out 和 In-Only MEP。

Axis2 現在同時支持阻塞和非阻塞調用模型。非阻塞調用在設計用戶界面時以及服務調用非常費時的情況下很有用。

用戶現在可以為調用的不同路徑選擇不同的傳輸方法。例如，對于 In-Out 調用，用戶可以按照以下方式進行處理：

  • 使用 HTTP 發送消息，并使用相同的 HTTP 通道接收響應（使用一個雙向通道傳輸方法）
  • 使用 HTTP 發送消息，但使用不同的 HTTP 通道接收響應（使用兩個雙向通道傳輸方法）
  • 使用 SMTP 發送消息，并使用 SMTP 接收響應（兩個不同的傳輸方法）

這個功能可在選擇交互的恰當傳輸時為用戶提供最大的控制。


回頁首


可插入數據綁定

在純 SOAP 級別上工作有時候比較麻煩，因此大部分用戶更喜歡使用 Java 代碼，而讓框架處理 XML 和 Java 代碼間的轉換。這稱為數據綁定。有很多數據綁定框架可用，用戶會因為各種不同的原因而偏好使用某個框架。Axis2 支持目前可用的大部分數據綁定框架，而且沒有任何限制。例如，Axis2 內置了對 XMLBeans、JAXB 和 JiBX 的支持，用戶可以選擇使用其中任何一個。任何其他數據綁定框架都可以方便地插入。

Axis2 還提供自己的簡單數據綁定框架，稱為 Axis2 Data Binding (ADB)。這就允許用戶下載 Axis2 并使用它，而不用太多考慮數據綁定框架。由于 ADB 和 Axis2 內部元素之間實現了緊密的集成，可以預見，與其他框架相比，此框架的性能和生成代碼維護方面都更具優勢。最近的 WS 互操作性研討會中對 ADB 進行了大量的測試（請參見參考資料）。





回頁首


REST 支持

隨著 Web 2.0 的推出，代表性狀態傳輸（REpresentational State Transfer，REST）得到了認可。一段時間以來，REST 陣營和 SOAP 陣營一直在就使用哪個規范進行激烈的爭論。我們嘗試在 Axis2 中同時支持二者，采用了 WSDL 2.0 中將 REST 與 Web 服務結合的工作成果。

在 Axis2 中，用戶可以調用 Axis2 引擎中采用 REST 方式部署的所有 Web 服務，但受到 WSDL 2.0 HTTP Bindings 規范中定義的約束的限制。





回頁首


Axis2 中其他值得注意的改進

  • WSDL 2.0 支持：Axis2 現在支持 WSDL 2.0。我們在最近進行的互操作性研討會中成功地進行了初始互操作性測試。
  • 工具支持：復雜操作始終需要使用工具來簡化工作。Axis2 隨附了 WSDL2Java 和 Java2WSDL 工具，同時提供了與 Axis2 協同工作的 Eclipse 插件。通過在 Web 容器中部署管理控制臺，可以更方便地對 Axis2 引擎進行遠程管理。
  • 各種傳輸協議支持： Axis2 支持 HTTP、SMTP、TCP 和 JMS。
  • Spring 支持：Axis2 內置了 Spring 服務支持。您可以編寫 Spring Bean，然后方便地使用 Axis2 將其作為 Web 服務公開。
  • WS-Policy 集成：Axis2 完全支持 WS-Policy，該規范已集成到了引擎的核心中。


參考資料

學習

獲得產品和技術

討論


關于作者

Eran Chinthaka 是首創 Apache Axis 2 項目的架構師，專職是 Lanka Software Foundation 的軟件工程師。他曾經為 Axis 2 實現了 AXIOM、WS-Addressing、SOAP 1.1 和 1.2，以及 BPEL4WS 的可視化建模工具。此外，他還做過 Web 服務、業務過程自動化、移動開發和電信網絡管理項目的架構師。