Axis包含多個協同工作的子系統，我們在之後會一一介紹。首先介紹一下Axis的核心是如何工作的。
Axis的Handlers和Message Path
簡而言之，整個Axis就是關於處理Message的。當核心Axis處理邏輯在運行的時候，按順序激活一系列的Handlers。它們的順序由兩個因素來決定-----部署配置以及engine的類型(客戶端/服務器端)。傳遞到每個Handler調用的對象叫做MessageContext。MessageContext是一個結構體，包含很多重要的部分：請求消息、響應消息和很多屬性。事實上遠遠不止這些。
有兩種基本的方式來調用Axis：
作爲一個服務器，傳輸監聽器(Transport Listener)會創建MessageContext並調用Axis處理框架
作爲一個客戶端，應用程序代碼(使用Axis的客戶端編程模型來編寫的)創建一個MessageContext並調用Axis處理框架
在每一種情況中，Axis框架的工作就是簡單的將每個MessageContext結果傳送到配置好的Handlers集合，每個Handler都有機會來對MessageContext進行操作。
服務器Message Path
服務器端message path通過下圖表示。小圓柱體代表Handlers，大一些的，包含圓柱體的圓柱體表示Chains(有順序的Handlers集合)。
當消息以特定的傳出協議到達傳輸監聽器時，本例中，我們假設是Http servlet。Listener將特定協議的數據設置到Message對象中，然後將Message設置到MessageContext中。MessageContext同時通過Listener加載各種屬性---在本例中，"http.SOAPAction"屬性會被設置成SOAPAction HTTP 和header。傳輸監聽器同時還將transportName屬性設置到MessageContext中，在本例中爲”http”。一旦將MessageContext準備好後，Listener將其轉交給AxisEngine。
AxisEngine的要做的第一件事就是根據名字查找transport。transport是包含一個請求鏈，一個響應鏈或者兩者都有的對象。鏈(Chain)就是一個Handler，但是它還包含一個Handler序列，按順序被調用。如果transport請求鏈存在，將被調用，將MessageContext傳送到它(transport請求鏈)的invoke()方法。這將導致調用請求鏈中的所有Handlers。
transport請求Handler結束後，Axis Engine查找global請求鏈，如果配置了global請求鏈的話，那麼調用指定的Handlers。
上述過程中的一些地方，一些Handler已經設置了MessageContext的serviceHandler屬性(在HTTP傳輸中，這通常由URLMapper Handler來完成，URLMapper Handler將一個URL，例如http://localhost/axis/services/AdminService，映射到AdminService服務)。這個屬性決定了Handler，這個Handler用來執行特定服務的功能，例如對後臺對象執行RPC調用。Axis中的服務是SOAPService類(org.apache.axis.handler.soap.SOAPService)的實例,它可能包含請求鏈和響應鏈(和前面介紹的transport/global相似)，並且必須包含一個provider，也是一個Handler，負責實現服務的實際後臺邏輯。
對於RPC-style的請求，provider是org.apache.axis.providers.java.RPCProvider類。這也是一個Handler，當被調用時，它調用一個後臺的Java對象，Java對象的類由className參數在部署時設置。它使用SOAP RPC方式來決定調用哪個方法，並確保輸入的XML-encoded參數的類型與被調用方法要求的參數的類型一致。
客戶端的Message Path
除了範圍的順序相反之外，客戶端的Message Path和服務器端的相似。如下圖所示：
如果存在服務Handler的話，首先在客戶端調用它，不存在provider，因爲服務是由遠程節點提供的，但是仍然有可能存在請求鏈/響應鏈。請求鏈和響應鏈在系統外對請求消息執行任意的特定服務的處理，同樣在響應返回到調用者時，也對響應執行相同的處理。
如果存在global請求鏈，那麼在執行完服務請求鏈後，它將被調用，然後是傳輸請求鏈。然後調用Transport Sender來發送消息。Transport Sender是一個特殊的Handler，用於執行實際的特定協議的操作，操作包括從目標SOAP服務器獲取消息和向目標服務器發送消息。響應被添加到MessageContext的responseMessage屬性中，然後MessageContext被傳送回來，依次經過transport、global，最後是service。
子系統
爲了明確的分工與劃分Axis標準組件，Axis由一些子系統共同工作。子系統可以在整個系統不使用的情況下獨立使用。
下面的示意圖展示了子系統的層次部署。底層獨立於上層。層疊的方框表示互相獨立，雖然不一定必須彼此排斥。例如，HTTP，SMTP和JMS傳輸彼此獨立，但是也可以共同使用。
事實上，Axis的源代碼並沒有像上面的圖一樣區分的如此明顯。一些子系統散佈在多個packages並且一些packages包含了多個子系統。以後會對這個結構進行修改。
1.消息流子系統
Handlers和Chains---處理器和鏈
Handlers被序列調用來處理消息。在序列中的某些點，一個Handler可能發送請求並接收響應，或者處理請求和產生響應。這樣的Handler叫做pivot point(樞紐點、中心點)。如上所述，Handlers是特定協議的、特定服務的或者是全局的。
這三種不同的Handlers被組合到Chains中。所以Handlers的整個序列包含了三個Chains，transport、global和service。下圖顯示了兩個handlers序列：客戶端序列(左側)和服務器端序列：
一個Web Service不一定非要針對每個請求都發送響應，雖然大多數是發送的。但是，響應Handlers在message path中同樣很有用，即便沒有響應消息，例如停止計時器、清理資源等等。
Chain是合成的Handler。也就是說，它聚集了一個Handlers的集合，它本身也實現了Handler接口，如下面的UML圖所示：
public interface Chain extends Handler {
public void addHandler(Handler handler);
public void addHandler(Handler handler);
public boolean contains(Handler handler);
public Handler[] getHandlers();
};
Chain和設計模式的責任者模式也有相似之處，也就是說，一個Chain中的請求通過序列中的每一個Handler，直到它被處理爲止。雖然一個Axis Chain可能在很多Handlers中都對請求進行處理，但是它和責任者模式有同樣的優點：靈活性和追加新功能的方便性(易擴展性)。
回到消息處理-----一個消息通過傳遞到合適的Chains來進行處理。一個消息上下文用來將Message和關聯的環境屬性傳遞到Handlers序列。Axis Chains是通過每次增加一個Handler脫機構造的，然後它們變爲在線的，消息上下文開始被傳遞到Chains。可能多個消息上下文併發通過同一個Chain。一旦Chain是在線的狀態時，就不再添加Handlers。如果需要增加或者刪除一個Handler，必須對Chain進行”cloned”操作，對clone進行操作，然後將clone變爲在線，當舊的Chain不再被使用時，就銷燬舊的Chain。消息上下文在完成之前仍然使用舊的Chain。這意味着正在處理消息上下文的Chain不需要理會Handler的追加與移除-------非常重要的一個簡化。
部署註冊器具有Handlers和Chains的工廠。Handlers和Chains可以被定義成具有’per-access’、’per-request’或者’singleton’範圍。雖然註冊器只能通過以下的辦法來進行區別：
對於每個請求，創建Non-singleton範圍的對象。
僅創建singleton範圍的對象一次，然後持有這個對象，在之後創建的請求都使用這個對象。
Targeted Chains目標鏈
Targeted Chain是一種特速類型的chain，可能包含下面的一些或者全部：
請求Handler
pivot Handler 支點Handler
響應Handler
下面的類圖表示了Targeted Chain和Chains的關係。注意由於Targeted Chain實現了Chain接口，所以Targeted Chain是Handlers的聚集。(Chain是Handlers的聚集)
服務是一種特殊的Targeted Chain，它的pivot Handler就是provider。
A service is a special kind of Targeted Chain in which the pivot Handler is known as a provider.
Fault Process錯誤處理
現在考慮一下發生了錯誤的時候怎麼處理。拋出異常的Handler的外層的Handler被驅動onFault方法，按照相反的順序。這個向後掃描的範圍很有意思：所有當前Message Context之前被調用的Handlers被驅動。
Message Context消息上下文
現在的Message Context的結構如下圖所示，每個消息上下文都和一個請求消息and/or響應消息相關聯。每個Message都有一個SOAPPart和Attachments對象，SOAPPart和Attachments都實現了Part接口。
消息上下文要結合Axis框架仔細考慮。既然消息上下文是在Handler接口上出現的，它就不應該綁定到或者偏重於SOAP。現在的實現是偏重於SOAP，因爲setServiceHandler方法將指定的Handler侷限於SOAPService。
Engine 引擎
Axis有一個AxisEngine抽象類，並且有兩個具體的子類：Axis驅動客戶端handler chains，AxisServer驅動服務器端handler chains。這幾個類之間的關係如下：
Engine Configuration引擎配置
EngineConfiguration接口是engine接口配置Handler工廠和全局屬性的途徑。EngineConfiguration的實現類的一個實例被創建後，必須傳送給engine，並且一旦EngineConfiguration的內容被修改了，必須要通知engine。engine持有EngineConfiguration的一個引用，並使用它來獲取Handler工廠和全局屬性。
EngineConfiguration接口屬於消息流子系統，也就是說，消息流子系統不依賴於管理子系統。
2.管理子系統
管理子系統提供了配置Axis引擎的方法。引擎需要的配置信息是運行時實例的集合(eg.Chains和SOAPServices)和引擎的全局配置選項。
消息流子系統的EngineConfiguration接口由Administration子系統實現。FileProvider可以使engine通過一個包含部署描述符的本地文件被靜態的配置。部署描述符可以被WSDDDeployment類來使用。SimpleProvider可以使engine被動態的配置。
WSDD-Based Administration 基於WSDD的管理
WSDD是一個基於XML語法的部署描述符，部署描述符用於靜態配置Axis引擎。每個Handler需要根據Handler工廠的具體類的名字、handler的一系列選項以及一個生命週期範圍來進行配置。
WSDD語法的結構映像到一個工廠類層次。下面的圖顯示了運行時它們(工廠類)生成的的類和類型。
