用Axis2進行SOA開發:瞭解Axis2基礎
引言
Web 服務的歷史非常悠久,在其發展期間經歷了多次迭代。第一代 Web 服務是受到高度控制的互動,可以視為僅是對可行性的測試。Apache SOAP 是第一代中值得注意的 SOAP 引擎之一,主要用作“概念驗證”,而根本沒有考慮效能。第一代 SOAP 引擎的整個目的是為了讓人們認識到 Web 服務是一個理想的選項。
不久,第一代 SOAP 引擎獲得了回報。越來越多的公司開始對此產生興趣,SOA 的概念逐漸成形。可以將此階段稱為第二代 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 的易用性,並同時保留通過各種方式擴充套件功能的空間。大部分新功能所新增到的主要領域如下所示:
- 新 XML 物件模型 (AXIOM)
- 基於訊息傳遞的核心
- 經過改進的部署模型
- 可插入資料繫結
- 新客戶機 API
- 資訊處理模型
新 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 也具有用於擴充套件其主要功能的處理程式概念。
Axis 1.x 並沒有非同步 Web 服務呼叫的概念,它完全繫結到請求-響應呼叫,但在 Axis2 中卻是另一番景象。Axis2 體系結構能夠支援在客戶端和伺服器端同時支援非同步呼叫。同時,Axis2 也支援請求-響應樣式的呼叫,但這會以兩個非同步呼叫的方式進行。在 Axis2 中,進入系統的訊息可能有也可能沒有響應,應該注意,Aixs2 支援 WSDL 2.0 中定義的所有八種訊息交換模式(Message Exchange Patterns,MEP)。
Axis2 具有流的概念,流是階段的集合,而階段是處理程式的集合。根據給定方法呼叫的 MEP,與其關聯的流的數量可能會有所變化。如果僅傳入的 MEP 對應方法只具有一個流,則稱為 inflow;而對於傳入-傳出,則具有兩個流——inflow 和 outflow。在大多數情況下,inflow 從傳輸偵聽器開始,到訊息接收方處結束,而 outflow 能以不同的方式開始,大多數情況下都在傳輸傳送方處結束。
圖 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。
模組體系結構
正如上面提到的,Axis2 也具有處理程式的概念,但與 Axis 1.x 相比,指定和部署處理程式的方式有一些變化。在 Axis 1.x 中,要新增處理程式,需要首先更改全域性配置檔案,然後需要重新啟動系統,並沒有在執行時更改處理程式鏈的動態方法。
為了克服這個問題和增加新特性,Axis2 引入了 Web 服務擴充套件或模組的概念;其中模組的主要工作是對核心功能進行擴充套件。在 Axis 1.x 中,可以通過向處理程式鏈新增處理程式來實現此目標。與 Axis 1.x 處理程式鏈相比,使用模組的優勢在於,您可以在根本不改變全域性配置檔案的情況下新增新模組。同時,模組是一個自容器,其中可以包含處理程式、第三方庫、模組相關資源和模組配置檔案。
可以將模組作為存檔檔案部署,Axis2 為模組採用了一個新擴充套件檔名 .mar。模組存檔檔案中最重要的檔案是模組配置檔案或 module.xml。除非具有 module.xml 檔案,否則該模組就是一個錯誤模組。模組配置檔案主要用於指定處理程式及其階段規則,因此讓模組參與系統後,根據階段規則不同,處理程式將被放置在不同的流上——inflow 或 outflow。
這個思路非常簡單。或許您需要支援 WS-Addressing 或 WS-Security。然後您必須下載對應的模組,並將其放置到 Axis2 儲存庫的 modules 目錄中。您可以在部署時通過向 axis2.xml(Axis2 全域性配置檔案)新增以下條目使模組參與系統,或在執行時通過使用各種方法(如使用 Axis2 Web 管理控制檯或 handlerfor exsample)使模組參與到系統中:
新客戶機 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,用於部署服務、擴充套件核心功能和新客戶機程式設計模型。現在已經進入了 Axis2 的時代了。