關於Apache Axis2的Web service消息
日期:2008-06-18 作者:喜騰小二 來源:PHPChina
版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
英文原文地址:
http://www.onjava.com/pub/a/onjava/2005/07/27/axis2.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43723_Apache_Axis2.html
關鍵詞： Apache Axis2 Web service
到目前為止，web service交互作用是獨立同步的，同時本質上是應答式的。不過，很顯然同步應答類型在基於消息的應用中隻是一個很小的子集。消息在耦合鬆散繫統中是非常重要的，因此這種限制很關鍵。Web service規範，例如WS-addressing和WSDL，已經融入了消息的概念並且為包含一個相當大範圍的消息應用奠定了基礎。Apache Axis2 架構既不基於任一個消息交換模式，也不基於同步/異步行為。這篇文章解釋了消息概念和Axis2在幾種眾所周知的消息場合中怎樣被擴展使用。
消息的簡單介紹
貫穿計算歷史，分佈式運算是其中的一個很大的挑戰：當資源是分佈式時，進程間的通信變得相當困難，研究人員仍然在尋找更好的解決方案。有趣的是，幾乎所有關於分佈式計算機計算能力問題的解決方案來源於兩種概念基礎： 遠程過程調用(RPC) 和消息傳遞。
毫無疑問，使用RPC在開發人員中是非常流行的技術，部分原因是是本地過程調用與它的類似之處。本地過程調用在程序員中很有人氣，所以在分佈式繫統中使用RPC是很自然的選擇，而另一方麵，消息傳遞不是非常流行，當它被提起時很少有開發人員關注它。不過，在某些場合使用消息相比RPC繫統有更好的優勢。
RPC和消息框架的基本差異如下所示：
●消息完全不懂客戶端和服務器，因為一個消息框架（通常所說的麵嚮消息的中間件，或message-oriented middleware，即MOM）集中於傳遞消息，所有接收和散發消息的節點身份平等，術語稱之為對等體。RPC始終有服務請求者 (AKA client) 和服務提供者 (AKA server)的概念。
●消息對於一個特定範疇是時間獨立的。沒有任何對等體希望實時接收消息－－當對等體可用時MOM關注於傳遞一個消息到相應的對等體，然而，RPC在失去一方時立即失效。
●消息可被復制並且輕易的傳遞到眾多對待體。RPC本質上是一種一對一的交流方式，而消息更靈活，並且毫不費力地傳遞同一消息的拷貝到多種對等體。
Web service消息
Web service是在XML消息的基礎上定義的，下麵3個因素描述了一個給定的Web service的消息交互。
●消息交換模式
●同步和異步客戶端API
●單嚮和雙嚮傳送行為
從最抽象的角度來講，，web service消息傳遞建立在發送和接收消息基礎上，一個給定的消息被一方發出，並且被另一方接收。消息可能相互關聯，識別這些相互關聯的消息群中的最常見的應用場合是非常重要的，這些消息群被定義為消息交換模式(message exchange patterns)，簡稱MEPs.
過渡時期下在兩種相關消息間的一個服務請求者的行為在客戶端API定義了消息同步/異步行為。同步場合下，客戶端請求將會阻塞，在相關消息到達目的地後前一直等待，在非阻塞場合下，客戶端請求不會阻塞，當相關消息到達時，它與之前的消息相互聯繫。
傳送分類為單嚮或雙嚮，基於單方或雙方行為。類似SMTP和JMS傳送即是單嚮傳送的，不會阻塞，另一方麵，類似HTTP和TCP即是雙嚮傳送，相關消息可能在回路中返回，實際上，在Web service消息中，雙嚮傳送可能被用作單嚮傳送，但是在這些場合下，它們可被有效的處理為單嚮方式。
消息交換模式
根據W3C建議，消息交互模式就是一個為交流雙方構建消息交換的一個模闆，一個MEP將相關消息確定為一組。MEPs根據服務請求者和服務提供者來定義，需要注意，為了清晰，MEPs以服務提供者的消息特性來命名。為方便理解，所有的命名都可以用request代替in, 用response代替out。
例如，我們看看兩個有名的MEPS
1.In-only/"發後不理:" 服務請求者發送消息給服務提供者但是不關心任何後繼相關消息
2.In-out/"應答式:" 服務請求者發送消息給服務提供者並希望返回結果
MEPS概念仍在擴展中，模式的數目是沒有限制的，所以Web service中間件應用強制使用幾種選定的MEPs，"發後不理"和 "應答式" 是被明確使用的，其它大多數的模式可由這兩種組合使用。
客戶端API同步/異步行為
同步/異步（或阻塞/非阻塞）行為是基於在web service請求的線程，同步服務將會阻塞，等待相關消息到達。另一方麵，異步請求僅僅返回，等待相關消息被後臺另一個不同線程執行。
這兩種途徑有典型的用例。考慮一下銀行事務，其需要一定數量的消息來來回傳遞。銀行事務本質是連續的，當結果到達時後執行下一步驟，因此同步等待結果很有意義。另一方麵，設想一個航班預約程序，其需要搜集多種數據來源，根據這些結果再匹配。這個案例中，異步行為發揮作用，因為程序可以提交所有結果並且當數據到達時工作。考慮到網絡響應，異步方式獲得較好的結果。
同步請求很簡單：請求在相關消息到達前等待，並且可以像本地過程調用一樣被編碼。但是異步消息的相互關繫就比較復雜，客戶端必須處理這種復雜性。盡管如此，通過一些額外工作來處理這種復雜情況仍是必要的。
傳輸層的行為
傳輸層的行為是個關鍵因素，決定了Web service消息的發生，傳輸根據依據其行為分類為單嚮和雙嚮。
單嚮傳送減少web service消息的復雜性，因為相關消息必須來源於各自的通道。另一方麵，如果傳送是雙嚮的，消息有機會選擇使用單嚮還是雙嚮，例如，傳輸是HTTP時，相關消息來自HTTP連接的返回路徑，或者這麼講web service提供者可以寫HTTP 200來指出沒有來自同一連接的響應，在這種案例下回應經由獨立的HTTP連接發送。
Web service尋址角色
webs ervice尋址框架（也被稱為WS-addressing）是為了在同一web service交互活動中交換不同信息部分，下麵的5個因素定義了交互活動：
1.消息交換模式
2.可被訪問的服務傳送
3.相關消息傳送
4.傳送的行為
5.客戶端API的同步/異步行為
服務提供者申明了頭兩個，客戶端定義了其餘因素，客戶端級別的同步/異步行為對服務提供者是完全透明的，客戶端使用WS-addressing來解釋web service消息。
在其它大多數結構中，WS-addressing定義了四種標題：To, ReplyTo, RelatesTo, FaultTo以及一個被稱為匿名地址的特定地址，當一個服務提供者接收到SOAP消息時，它會查找在to地址上的目標服務並且調用服務。如果有結果，即被發送到ReplyTo地址，錯誤被發送到FaultTo地址，如果以上任一個的標題沒有指定或俱有匿名值，結果通過雙嚮傳送返回路徑返回（因為匿名決定雙嚮傳送返回路徑）。
傳送和WS-addressing一起定義了查找相關消息的機制，消息是相關緣於它們共享了相同的傳送通道，也可能因為它們都共享把它們互相鏈接的公共信息。web service RelateTo標題正好提供了這種關繫。
Axis2客戶端API概念
Axis2客戶端API處理了In-Only和In-OutMEPs，所有的消息結合在下麵的章節討論。MEPs的空間是無限的，因此，Axis2強制提供了支持任意消息交換模式的核心，並且提供了兩種常被使用的模式In-Only和In-Out的API，有兩種方法實現更多的復雜模式：組合In-Only和In-Out來完成希望的模式，或者對希望的模式寫新的擴展。因為Axis2為任意MEP提供核心級別的支持，實現是顯而易見的。In-Only和In-OutMEPS被InOnlyMEPClient和InOutMEPClient類支持，下兩節即做俱體描述。
In-Only MEP 支持: InOnlyMEPClient
InOnlyMEPClient類對發送不理消息提供了支持，所有的傳送類型作為單嚮傳送對待，InOnlyMEPClient和InOutMEPClient真正的差別是尋址參數起先沒有鎖定，並且尋址參數隨後被Axis2控制。作為可被控制的尋址參數，InOnlyMEPClient可被用作消息API，並且在此基礎上構建更復雜的消息交互。
In-Out MEP 支持: InOutMEPClient
InOutMEPClient和繼承了InOutMEPClient的調用類為應答式消息提供了支持，Axis2關注完整的操作，除了To地址外的所有的尋址屬性都在Axis2的控制下
用戶可以配置InOutMEPClient 來表現不同，利用以下的四個參數。
1.發送者傳輸
2.監聽者傳輸
3.是用單獨監聽
4.使用阻塞
客戶端API當前提供了針對HTTP和SMTP傳輸的支持，下麵的表格顯示了這些參數可能的組合以及它們怎樣結合來提供不同特效。
舉例
下麵的代碼實例顯示了怎樣使用Apache Axis2做幾個定義明確的交互作用,用戶可以在客戶端API簡單的轉換屬性從而轉換不同的交互作用，客戶端Axis2 API僅僅支持XML級別的消息和代表大塊XML的OME元素。
調用單嚮消息
單嚮MEP簡單之處在於在僅有一個消息來回傳送時它能表現正確的單嚮，這些消息被異步對待並且傳送是單嚮的。
應答式消息
可以表現四種方式的應答式消息
1.雙嚮In-Out 同步
2.雙嚮In-Out 異步
3.單嚮In-Out 同步
4.單嚮In-Out 異步
下麵的代碼實例說明這些案例怎樣被Axis2尋址，注意客戶端API的四種屬性怎樣被使用。
1.In-Out同步，HTTP作為雙嚮傳輸方式
OMElement payload = ....
Call call = new Call();
call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
"HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
Constants.TRANSPORT_HTTP, false);
OMElement result =
(OMElement) call.invokeBlocking(
operationName.getLocalPart(), payload);
這裡，SOAP消息經由同一個HTTP連接傳播，地址屬性沒有指定，所以它們在服務器方缺省為匿名，客戶端API將被鎖定直到回復消息到達。
2.In-Out異步，HTTP使用HTTP作為雙嚮傳送
//this is the payload goes on the body of SOAP message
OMElement payload = ....
Call call = new Call();
call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
"HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
Constants.TRANSPORT_HTTP, false);
Callback callback = new Callback() {
public void onComplete(AsyncResult result) {
//what user can do to result
}
public void reportError(Exception e) {
//on error
}
};
call.invokeNonBlocking(operationName.getLocalPart(),
payload, callback);
和前麵相同，SOAP消息經由同一個HTTP連接傳輸並且不需要尋址，一旦回復消息到達客戶端API不會阻塞並且回調將被執行。
3.In-Out, 異步HTTP 作為單嚮傳輸
OMElement payload = ....
Call call = new Call();
call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
"HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
Constants.TRANSPORT_HTTP, true);
Callback callback = new Callback() {
public void onComplete(AsyncResult result) {
....
}
public void reportError(Exception e) {
...
}
};
call.engageModule(new Qname("addressing"));
call.invokeNonBlocking(operationName.getLocalPart(), method, callback);
在這個案例中，SOAP消息通過兩個HTTP連接傳輸，尋址是強制的，ReplyTo標題出現指示服務器端經由單獨的通道發送回應。客戶端沒有阻塞，當回應消息到達時，喚起回調。
4.In-Out, 同步 HTTP 作為單嚮傳送
OMElement payload = ....
Call call = new Call();
call.setTo(
new EndpointReference(AddressingConstants.WSA_TO,
"HTTP://...));
call.setTransportInfo(Constants.TRANSPORT_HTTP,
Constants.TRANSPORT_HTTP, true);
OMElement result =
(OMElement) call.invokeBlocking(
operationName.getLocalPart(), payload);
在這種場合下使用"In-Out,異步HTTP作為單嚮傳送"類型，在結果到達第二種連接時喚起阻塞，執行並返回結果。
總結
總而言之，web wervice消息行為建立在三種因素上：消息交互模式，客戶端同步異步模式和傳送行為。Asis2建立核心在不一定要任何MEP類型，不過為MEPs的廣泛支持：單嚮和應答提供了客戶端API支持，這篇文章解釋Axis2消息支持概念和客戶端API的使用。
資源
●Apache Axis2的官方站點
●W3C討論稿, "WSDL Version 2.0 Part 2: Message Exchange Patterns"
●"Why Messaging? The Mountain of Worthless Information," Ted Neward的博客, 星期三，2003年5月9日
●"Introduction to WS-Addressing," 作者Beth Linker, dev2dev, 2005年1月31日
●"Async," Dave Orchard的博客, 2005年5月5日
●"Programming Patterns to Build Asynchronous Web Services," Holt Adams, IBM開發者文集, 2002年6月1日
Srinath Perera是Apache Axis2的主要架構師
Ajith Ranabahu是Apache Axis2項目的成員並且在基於Web service的項目裡工作了3年
