前言

結構都是它本身所能產生效率的結果。任何一個成功結構都是基于它期望的需求。我們通過期望用 Axis2 做什么來開始我們的 Axis2 之旅。

用 Axis2 做什么

在 SOAP 的術語里，一個 Web Service 交互的參與者都稱作一個 SOAP 的節點。 SOAP 消息在 SOAP 發送者和接收者之間傳遞。 SOAP 消息的傳遞是基于構建 Web Service 交互的單元之上。

???????? Web Service 封裝了 SOAP 消息處理的復雜性，允許用戶用他們所熟悉的開發語言進行開發。 Axis2 就是通過用 Java 語言開發 Web Service 的工具，在其內部處理 SOAP 消息，這一切對于用戶都是透明的。

Axis2 封裝了 SOAP 消息的處理，同時還有做了其他的大量的工作，這些都進一步簡化了 Web Sercice 的開發者的工作，主要有以下幾點：

提供了一個處理 SOAP 消息的框架，這個框架是極易擴展的，用戶可以在每個服務或操作上擴展它。用戶也可以在這個框架的基礎上對不同的消息交換模型（ Message Exchange Patterns ） MEPs 進行建模。

部署 Web Service （可以用 WSDL 或者不用）。

提供了客戶端 API 用來調用 Web Service ，可以用同步或者異步的編程方式。

通過部署來配置 Axis2 和它的組件。

在不同傳輸層發送和接收 SOAP 消息。

除了上述的這些功能，在內存和速度等性能方面也是 Axis2 的重點。 Axis2 的核心框架是構建在 WSDL ， SOAP 和 WS-Addressing 上，其他的如 JAX-RP ， SAAJ 和 WS-Policy 是在核心框架之上的層。

體系結構

在說明體系結構前，需要說明：

Axis2 的體系結構分離了邏輯和狀態，在其內部邏輯處理都是無狀態的，這樣就允許在幾個平行的進程間處理同樣的代碼。

所有的信息都被保存在一個信息模型中，允許系統阻塞和重啟。

Axis2 是模塊化的結構， Axis2 框架是構建在核心模塊上，其他的模塊則構建在核心模塊上。核心模塊包括：

信息模型， Axis2 定義了一個處理信息的模型，所有的狀態都保存在這個層次機構模型中。在這個層次結構中，系統處理對象的生命周期。

XML 處理模型，處理 SOAP 消息是最重要和復雜的任務，它的效率是影響性能的主要因素，我們通過 AXIOM 來有效的處理 SOAP 消息和 XML 文件。

SOAP 處理模型，它控制了處理過程的執行。這個模型定義了不同的處理階段，用戶可以在不同的階段擴展這個模型。

客戶端的 API ，它為用戶提供了方便的 API 來處理 Web Service 。可以用來和 IN-OUT 和 IN-only 方式的消息交換模型。

傳輸器（ Transports ）， Axis2 定義了傳輸框架，允許用戶定義不同的傳輸器。在 SOAP 消息處理模型中可以利用傳輸器，在實現中定義了幾個通用的傳輸器，當然用戶也可以在需要的時候自定義傳輸器。

非核心模塊：

代碼生成， Axis2 提供了代碼生成器，可以生成服務器端和客戶端的測試代碼。生成的代碼也就簡化了服務的部署和服務的調用，

數據綁定， Axi2 的基本的客戶 API 允許用戶在信息集合上處理 SOAP 消息，通過封裝信息層，提供編程接口，可以使用戶方便的利用數據綁定。

??
信息模型

信息模型有兩個主要的層次，上下文（ Contexts ）和描述（ Descriptions ），通過 UML 描述如下：

兩個層的連接如上圖，描述層代表靜態數據，這些數據可以在 Axis2 的生命周期中通過配置文件裝載，比如部署服務，操作。另一方面，在上下文的層中包括了不止一個實例的動態信息。

在兩個層次上可以提供了搜索值對的能力，當在一個層上搜索值時，會在這個個層的垂直體系上進行搜索，在結果模型中，低層的值重載了高層的值。比如，當在 Message Context 上找不到一個值時，就會在 Operation Context 上進行搜索，依次向上進行。同理在 Descriptions 也是一樣的。

這樣用戶就可以聲明和重載值，是一個非常易配置的模型，這也給系統帶來了弱點，就是搜索的代價。特別是對于一些不存在的值，當然分析后，開發者認為它還是可以很好的工作。

?

XML 處理模型

參考 OM Tutorial

SOAP 消息處理模型

體系機構定義了 SOAP 處理器兩個基本動作，發送和接收 SOAP 消息。提供了兩個管道（ Pipes ），或者 Flows 來執行這兩個動作。 Axis 引擎或者 Axis2 驅動定義了 send() 和 receive() 兩個方法來實現 Pipes 。兩個管道為 In Pipe 和 Out Pipe ，通過合并這兩個 Pipes 來構建 MEPs 。

通過處理器（ handler ）來實現 SOAP 消息處理的易擴張性。當一個 SOAP 消息被處理時，被注冊的處理器就會執行，處理器可以注冊在全局變量，服務，或操作范圍內，最后處理器鏈從所有的范圍內計算合并所有的處理器。

處理器也扮演了攔截器（ Intercepter ）的作用，他們處理部分 SOAP 消息，提供附加的服務，通常處理器工作在 SOAP 頭上，也可以訪問和改變 SOAP 體。

當一個 SOAP 消息通過客戶端 API 發送， Out Pipe 就開始操作， Out Pipe 觸發處理器，被一個將 SOAP 消息送到端點（ endpoint ）的發送傳輸器結束，在目標端的接收傳輸器接收。在接收端 In Pipe 開始讀 SOAP 消息。 In Pipe 由處理器和消息接收者組成。

上述發生的消息處理過程發生在所有的消息交換中。在 Axis2 中處理一消息后就會創建另一消息，在新的消息中，更復雜的模型可能出現。

兩種類型 Pipe 和服務器 / 客戶端模型類似， SOAP 處理模型簡化了復雜性，為用戶提供了抽象的接口。 Pipe 的不同階段 phases 都已命名。處理器通常運行在一個階段中，階段提供了一種預定處理器的機制。兩種 Pipe 都內建了 phases ，也都為用戶提供了 User Phases ，可以由用戶自定義。

下圖中可以看到 User Phases

Axis2 默認處理模型

Axis2 有很多內建在 Phases 中的處理器，它們可以為 Axis2 創建默認配置。在下節中，我們會仔細研究如何擴展 Axis2 的默認處理模型。

Axis2 中有四種特殊的處理器：

分發器（ Dispatchers ）查找服務和 SOAP 消息的操作。通常運行在 In-Pipe 的 dispatch 階段。根據不同的條件，如 WS-Addressing ， URI 信息， SOAP Action 信息來分配特殊的操作。

消息接收器（ Message Receiver ） 讀 SOAP 消息，運行在 In-Pipe 的 Message Processing 階段。

發送傳輸器（ ???? Transport Sender ）發送 SOAP 消息，永遠運行在 Out-Pipe 中。

處理收到的 SOAP 消息

由接收傳輸器收到消息，一旦消息到達，傳輸頭就會被解析，消息上下文（ Message Context ）就會創建，然后通過消息上下文 In-Pipe 就會被執行。

讓我們看下在執行過程中每個階段都發生了什么，處理過程在服務端和客戶端都會發生，這里說明一個特殊的雙向傳輸，在 In-Pipe 開始的四個階段可能不會發生。

傳輸階段，在這個階段處理器從傳輸配置中抽出，根據規則執行。

預分發階段，由于服務還未存在，處理器會在全局使用。

分發階段，如果服務還為發行，分發器就會在此階段查找服務。

用戶階段，運行用戶自定義處理器。

消息驗證階段，在這個階段驗證 SOAP 消息處理是否正常執行。

消息處理階段，在這里執行 SOAP 消息的商業邏輯，每個操作都注冊了一個消息接收器，消息接收器（關聯到特定操作）就會作為這個階段的最后一個處理器執行。

可能還有其他的處理器，用戶也可以自定義處理器來重載每個階段的處理機制。

發送消息的處理過程

Out-Pipe 是相對簡單，因為此時服務都已被所知， Out-Pipe 由消息接收器或客戶 API 實現。

消息初始化階段， Out-Pipe 的第一個階段，作為自定義處理器的存放文件夾。

用戶階段，執行用戶階段的處理器

傳輸階段，執行從傳輸配置層的傳輸處理器，作為傳輸處理器的最后處理器發送 SOAP 消息到目的端。

擴展消息處理模型

以上我們討論了 Axis2 默認處理模型，現在我們討論下 SOAP 消息處理的擴展機制，很多 SOAP 引擎研究也集中在其擴展性。

根據處理器和階段使在 SOAP 處理中更容易的修改處理過程，階段概念使在處理器之間加入新的處理器，也就更容易擴展默認的處理過程。

用處理器擴展 SOAP 處理模型

通過階段規則（ Phase rule ）將處理器放在不同位置定制階段來擴展 SOAP 處理模型。

作為一個階段的第一個處理器

作為一個階段最后一個處理器

在一個給定處理器之前

在一個給定處理器之后

通過模塊擴展 SOAP 處理模型

Axis2 定義了一個叫模塊（ Module ）的實體，由模塊來引入處理器和 Web Service 操作，在 Axis2 中的模塊作為一個包，包中包括了一些處理器和相關的關于規則的描述，模塊是有可用性和被用時，可用性表示模塊存在于系統中，但仍沒被激活，就是被包括在模塊中的處理器沒有在處理機制中，當一個模塊被用時，它就會被激活，然后在階段中找到合適的位置，這些處理器就會按照上面的方法執行。通常模塊被用來實現在 WS-Addressing 時的 WS-* 功能。

除了上面基于 handlers 實現擴展外， WS-* 參考建議另一種增加操作（ Operations ）的方法，比如，用戶在服務中增加創建序列（ Create Sequence ）的操作，需要在服務端可以用，就可以通過在模塊中定義操作來實現，一旦模塊被服務所用，需要的操作就會被增加到服務中。

服務，操作或系統都可以利用模塊，一旦模塊被用到，在其中定義的處理器，操作就會添加到這個實體中。

當 Axis2 正在運行時，模塊就不能被添加，除非系統重啟。

部署

部署模型提供了詳細配置 Axis2 的機制，主要有三個部分來配置 Axis2

Axis2.xml 文件

這個文件為客戶端和服務器端提供了全局的配置，主要包括下面的信息。

全局參數

注冊的發送傳輸器（ Transport In ）和接收傳輸器（ Transport Out ）

用戶定義的階段名

全局被用到的模塊

全局的消息接收器

服務包（ Service Archive ）

服務包必須包含 META-INF/services.xml 文件和一些相關的類， services.xml 包含以下信息

服務級的參數

服務級的模塊

服務中特定消息接收器

服務內部的操作

模塊包（ Module Archive ）

模塊包必須包含 META-INF/module.xml 文件和一些相關的類， module.xml 包含了模塊參數和在其中定義的操作。

當系統啟動時， Axis2 就會創建 Axis 的配置，首先會找 axis2.xml ，構建全局配置，接下來就會檢查模塊包和服務包，這樣相關的服務和模塊就會被添加到配置中，然后在配置基礎上，構建上下文， Axis2 就準備接收和發送 SOAP 消息，服務也可以熱部署，有一個線程循環的檢測容器，看是否有新的服務被部署。

客戶端 API （ Client API ）

有三個參數決定了 Web Service 的交互

消息交換模型（ MEP ）

傳輸器的行為，是 One-way 或者 Two-way

客戶端 API 是同步或者異步

由于這三個參數的變化導致了很多語義的不確定性，盡管 Axis2 是構建在運行多種消息交互的核心上，但開發者一般都用兩種主要的 MEP 。

在 Client API 中，兩種支持的傳輸器是單向（ One-Way ）和雙向（ Request-Response ）。是基于 ServiceClient 類來實現的， Axis2 中有每種 MEP 的擴展支持。

單向消息傳輸

ServiceClient 為用戶提供了簡單的接口，由 ServiceClient 提供的 fireAndForge 支持 One-Way 方式， Axis2 支持 HTTP/SMTP 和 TCP 傳輸， HTTP 的情況，如果返回通道（ Channel ）不可用，就會返回 HTTP 202 OK 。

雙向（ Request Response ）消息傳輸

由在 ServiceClient 中的 sendReceive() 提供，為用戶提供了簡單的接口，在客戶 API 中有四種方法配置消息交換。

阻塞或非阻塞方式，由 sendReceive() 和 sendReceiveNonBlocking() 來決定。

發送傳輸器，傳輸器被用來發送 SOAP 消息

監聽傳輸器，傳輸響應收到信息。

利用分離通道，決定是否響應是通過分離的傳輸連接或者非分離的來發送。如果發送和監聽器是相同的機會失敗，這樣就是雙向傳輸。

上面四個參數的不同就會使 Axis2 進行不同的操作。

傳輸器

Axis2 有兩種不同傳輸結構， transport in 配置和 transport out 配置，通過消息上下文來訪問他們。

服務器利用 transport in 來收到消息， outgoing transport 是由尋址信息（ Addressing Information ） (ReplyTo 或 FaultTo) 決定的，如果尋址信息不可用，則 outgoing transport 和 incoming transport 相同。

在客戶端，用戶可以自由使用 transport 。

transport in 配置和 transport out 配置包含以下信息

對外的傳輸發送器

對內的傳輸監聽器

傳輸的參數

傳輸的處理器

每個對外的傳輸配置都定義了一個傳輸代理，傳輸發送器通過自己的傳輸發送消息。

傳輸接收器等待 SOAP 消息，一旦 SOAP 消息到，就會用 In Pipe 來處理消息。

Axis2 目前支持以下的傳輸

HTTP ，在 HTTP 的傳輸中，傳輸監聽器是一個 Servlet 或者是由 Axis2 提供的 org.apache.axis2.transport.http.SimpleHTTPServer ，傳輸發送器用 commons-httpclient 來連接和發送 SOAP 消息。

TCP ，這是最簡單的傳輸，但需要 WS-Adressing 支持

SMTP ，需要 Email 帳號，傳輸接收者在確定的時間間隔內檢測郵件的到來。

代碼生成

盡管代碼生成的目標沒有改變，但在 Axis2 中采用了一種不同的代碼生成方法，主要變化是采用了模版，命名為 XSL 來以各種語言生產代碼，提供了很好的靈活性。

主要思想，設置生成器來生成 XML ，利用模版解析 XML 來生成代碼文件，下圖描述了生成工具的結構

不管代碼是如何生成的，關鍵是和從 WSDL 生成信息相同，代碼生成器利用 WOM （ WSDL Object Model ）操作 WSDL 文件，傳輸信息到 Emitter ， Emitter 生成 XML ，然后 XML 由相應的 XSL 解析生成代碼。除非用到的模版不同，不管編程如何，處理過程都是相同的。

數據綁定

集成代碼生成引擎

Axis2 M2 支持代碼生成，但不支持數據綁定， version0.9 有完整的方案來支持數據綁定，因為有數據綁定工具 Xml-bean ，所以這個方法是可行的，最初的代碼生成框架沒有明顯的變化，數據綁定作為一個擴展插件加入到代碼生成引擎中， version0.91 不支持 SOAP 解碼，它僅支持 RPC 文本型消息。

序列化和發序列化

AXIOM 是基于 StAX （ Streaming API for XML ） API ， Xml-beans 支持 StAX 的數據綁定，通過 AXIOM 用 Xml-bean 來實現，在代碼生成階段，對于每個 WSDL 的操作都有些支持的類， WSDL 的操作中有很多有用的方法，可以從 AXIOM 反序列化到數據綁定對象，也可以從數據綁定對象序列化到 AXIOM 。比如在 WSDL 文件中有一個叫 echoString 的方法，一旦代碼生成， echoStringDatabindingSupporter.java 類就會生成，其中包括類似于以下的代碼，

?