Axis2分析報告

1、axis2分析報告,第一部分：需求分析,背景,網(wǎng)絡服務”（web services），是指一些在網(wǎng)絡上運行的、面向服務的、基于分布式程序的軟件模塊，網(wǎng)絡服務采用http和xml等互聯(lián)網(wǎng)通用標準，使人們可以在不同的地方通過不同的終端設備訪問web上的數(shù)據(jù)，如網(wǎng)上訂票，查看訂座情況。網(wǎng)絡服務在電子商務、電子政務、公司業(yè)務流程電子化等應用領域有廣泛的應用，被業(yè)內人士奉為互聯(lián)網(wǎng)的下一個重點。 隨著互聯(lián)網(wǎng)使用人群越來越多，互聯(lián)網(wǎng)本身和其相關技術都發(fā)展的越來越快，網(wǎng)絡服務已經(jīng)成為現(xiàn)代互聯(lián)網(wǎng)中信息交流和信息共享中不可缺少的一部分,axis2背景,axis2是下一代 apache axis。axis2 雖然由

2、 axis 1.x 處理程序模型提供支持，但它具有更強的靈活性并可擴展到新的體系結構。axis2 基于新的體系結構進行了全新編寫，而且沒有采用 axis 1.x 的常用代碼。支持開發(fā) axis2 的動力是探尋模塊化更強、靈活性更高和更有效的體系結構，這種體系結構可以很容易地插入到其他相關 web 服務標準和協(xié)議（如 ws-security、ws-reliablemessaging 等）的實現(xiàn)中。 apache axis2 是axis的后續(xù)版本，是新一代的soap引擎,目的,我們的編寫目的是通過探索axis2的設計架構和開發(fā)模式來更好地理解軟件體系結構在系統(tǒng)設計中的重要性，尤其在互聯(lián)網(wǎng)時代，信息

3、交流大、數(shù)據(jù)通信頻繁的特點下，對網(wǎng)絡服務框架的研究將有助于我們更好地理解和體驗現(xiàn)代互聯(lián)網(wǎng)應用框架的意義和內部原理,需求分析 網(wǎng)絡服務支持,支持廣泛使用的基于http的soap協(xié)議，包括soap 1.1和soap 1.2。 同時支持rest樣式的網(wǎng)絡服務模型。 支持spring框架,需求分析 傳輸協(xié)議支持,在soap發(fā)送方和接收方中支持多種協(xié)議比如smtp、ftp和消息導向性中間件。 支持wsdl 2.0中的mep（消息交換模式,需求分析 客戶端支持,引言：大多數(shù)網(wǎng)絡服務框架都支持阻塞的網(wǎng)絡服務調用，但是現(xiàn)在越來越多的網(wǎng)絡服務框架開始支持非阻塞網(wǎng)絡服務調用。其實不僅僅是網(wǎng)絡服務，網(wǎng)絡應用程序都開

4、始傾向于非阻塞調用，比如ajax。 因此框架客戶端調用需支持阻塞和非阻塞態(tài)調用,需求分析 擴展性支持,不管是服務器端還是客戶端，整個soap消息處理流程（也就是消息的接收與處理，和構建與發(fā)送）都必須支持可擴展性，所有流程可以改變，并且支持用戶自定義的處理模塊,需求分析 性能要求,框架需提供專有的xml解析器來最大化得優(yōu)化soap中xml的處理性能。 對于客戶端api提供xml構造器來快速創(chuàng)建xml數(shù)據(jù)并封裝到soap中傳輸。 整個網(wǎng)絡服務調用流程，不管是阻塞還是非阻塞，都必須可適應高頻率的并發(fā)調用，并始終保持系統(tǒng)的有效有序運行。 擴展性支持不會對整個處理流程造成過多性能損耗,第二部分：系統(tǒng)設計

5、分析和管道過濾器模型,系統(tǒng)設計 axis2的模塊,系統(tǒng)設計 - 管道過濾器模式,管道過濾器模式：pipeline and filters pattern，從名稱上可以看出來，它形象得描述了一種消息處理的模式，即以一種類似管道和過濾器的處理方式逐步對數(shù)據(jù)進行處理。 管道：需要處理的數(shù)據(jù)。 過濾器：處理的執(zhí)行,系統(tǒng)設計 - 管道過濾器模式,前一個過濾器的輸出是后一個過濾器的輸入。 執(zhí)行過程環(huán)環(huán)相扣，如果一個過濾器沒有輸出，后續(xù)過濾器就沒有了輸入，因此無法進行。 每一個執(zhí)行點都可以有反饋機制，這樣整個執(zhí)行過程是可控制的。 例如一些腳本執(zhí)行器就是采用類似管道過濾器模式，如下圖,系統(tǒng)設計 管道過濾器處理

6、方式,為了滿足需求分析中：分段、高效、支持擴展的處理方式。axis2使用了管道過濾器模式的處理方式,系統(tǒng)設計 第一層：邏輯處理流,axis2會根據(jù)mep（消息交換模式）的不同來決定最外層的邏輯處理流,系統(tǒng)設計 第二層：引擎執(zhí)行單元,axis2的執(zhí)行引擎是在第二層之上的，在第一層邏輯層之下，引擎處理層則把輸入流和輸出流的各個步驟具體刻畫出來,系統(tǒng)設計 第三層原子執(zhí)行,到達第三層，執(zhí)行的模塊就不可再分了。axis2會使用原子執(zhí)行模塊代表管道過濾器中的節(jié)點,系統(tǒng)設計 多層管道過濾器的連接,多層管道過濾器采用類似面對對象編程中對象的繼承和多態(tài)特性，一層管道過濾器看起來是線性的，但是一個過濾器類型的執(zhí)行

7、可能會誘發(fā)另一個子管道過濾器，這樣這個過濾器的執(zhí)行就是其包含的子管道過濾器先得執(zhí)行。那么此時邏輯上這個管道過濾器執(zhí)行就具有多層的意義了。如下圖,axis執(zhí)行引擎概括 第一層,axis2執(zhí)行引擎 第二層，第三層,下圖中的phase代表第二層單元，handler代表第三層概念。具體代碼實現(xiàn)在后面會詳解,第三部分：系統(tǒng)實現(xiàn)分析,axis2最底層管道過濾器 - handler和context,剛才講過，axis2中的最底層管道過濾器執(zhí)行是原子的，不可再分的，因此管道過濾器直接對應handler和messagecontext對象,axis2最底層管道過濾器 - handler和context,handl

8、er是一個接口。命名空間：org.apache.axis2.engine handler是沒有狀態(tài)存儲的：stateless。因此可以理解成是一種靜態(tài)的支持并發(fā)操作的對象，當然實際上它還是非靜態(tài)的。 管道過濾器的具體執(zhí)行類型都是可擴展的：handler和messagecontext都是可擴展類型，僅定義必要執(zhí)行和操作接口。 整個過程是可控制的： 通過invocationresponse類型,handler類型,handler類型定義如下常用方法,handler類型,handler定義一個nested class：invocationresponse，后者定義三個靜態(tài)字段：continue、su

9、spend、abort 控制當一個過濾器完成后，是否繼續(xù)或者暫停還是停止后續(xù)的操作,abstractcontext類型,介紹完管道過濾器中的過濾器類型：handler，我們來看管道對應的類型：abstractcontext。 axis2的abstractcontext類型在命名空間：org.apache.axis2.context內。 該類型是用來存儲任何過濾器操作中的抽象數(shù)據(jù)類型核心定義,abstractcontext類型,類型定義如下字段（全部是派生類可見的）： 定于如下函數(shù),自定義一個handler類型,了解了上述信息我們可以自定義一個handler類型,axis2第二層管道過濾器 ph

10、ase,這是系統(tǒng)設計中第二層：引擎執(zhí)行單元的具體執(zhí)行，在axis2中，這層的類型名稱是phase類型。 命名空間：org.apache.axis2.engine 它具備如下特點： 定義一系列有序的handler。是axis2中新加的概念。 phase類型執(zhí)行handler接口，因此phase就是一種handler，只不過是一個特殊的可以包含子handler的handler,axis2第二層管道過濾器 phase,phase類型的函數(shù),axis2第二層管道過濾器 phase,axis引擎在運行時是以phase為執(zhí)行單位的，axis2引擎只會調用phase的invoke函數(shù)，而phase類型的in

11、voke函數(shù)會調用背后包含的handler的所有invoke函數(shù)。如下圖,axis2第三層管道過濾器：flow,flow和phase的關系就如同phase和handler的關系：flow包含一個或多個phase。 區(qū)別：flow在axis2中比較偏向邏輯方面，具體沒有直接的對應執(zhí)行類型，而且axis2引擎直接執(zhí)行的元素是phase。 axis2中包含下面4中flow,axis2執(zhí)行模型,再次回顧一下axis2執(zhí)行模型： 從最外層將，axis2處理整個soap消息是在phase層,axis2執(zhí)行模型,在往下細分就是phase和handler的管道過濾器執(zhí)行,第四部分：非核心部分實現(xiàn)分析,信息處理

12、模型,最下是stax：streaming api for xml (stax)，xml解析框架，來自java，相比sax模式的xml解析更具動態(tài)性，相比dom形式xml解析更具性能優(yōu)勢，可以理解為介于sax解析和dom解析之間。 之上是axiom：apache axiom是xml信息集模型，可供用來動態(tài)創(chuàng)建信息對象數(shù)。 然后在原始xml解析和xml信息模型的基礎上，建立了整個核心框架，執(zhí)行引擎，部署。因為axis2使用soap傳輸，用到wsdl定義服務描述，而soap和wsdl都是基于xml的。 核心框架定義好后，axis還定義一些上層應用運行在核心框架之上。如數(shù)據(jù)傳輸模塊和數(shù)據(jù)綁定模塊,信息

13、處理模型,上述過程可以用這個圖來表示,客戶端api分析,axis2客戶端api支持異步核同步的調用方式。 對于同步的調用方式，應用程序的當前執(zhí)行線程會阻塞，直到收到服務器回應，如下圖,客戶端api分析,對于異步的調用方式，應用程序的當前執(zhí)行線程不會阻塞，服務器回應會通過異步事件調用通知應用程序。 如下圖：rn代表服務器傳來的回應通知,代碼測試實現(xiàn),使用java創(chuàng)建一個簡單的網(wǎng)絡服務執(zhí)行。 來模擬查詢商品價格和添加商品價格： 首先創(chuàng)建一個hashmap來存儲string和double。 首先判斷hashmap中否包含指定字符串。 如果有的話，返回字符串對應的double值。 如果沒有返回42,代碼測試實現(xiàn),上述功能代碼,代碼測試實現(xiàn),使用w3c推薦的標準來定義這個網(wǎng)絡服務，是網(wǎng)絡服務規(guī)格化： 定義xml根節(jié)點為service（代表一個網(wǎng)絡服務），然后通過description、operation和parameter三個節(jié)點規(guī)格化定義網(wǎng)絡服務的描述、操作和參數(shù)的數(shù)據(jù),代碼測試實現(xiàn),上述功能的代碼（保存在xml文件中,代碼測試實現(xiàn),接下來需要重新改寫網(wǎng)絡服務類型的執(zhí)行（按照axis2的模式）。具體則需要使用axiom中的xml對象數(shù)