摘要:
到目前為止，web service交互作用是獨立同步的，同時(shí)本質(zhì)上是應答式的。不過(guò)，很顯然同步應答類(lèi)型在基于消息的應用中只是一個(gè)很小的子集。消息在耦合松散系統中是非常重要的，因此這種限制很關(guān)鍵。Web service規范，例如WS-addressing和WSDL，已經(jīng)融入了消息的概念并且為包含一個(gè)相當大范圍的消息應用奠定了基礎。Apache Axis2 架構既不基于任一個(gè)消息交換模式，也不基于同步/異步行為。這篇文章解釋了消息概念和Axis2在幾種眾所周知的消息場(chǎng)合中怎樣被擴展使用。
關(guān)于A(yíng)pache Axis2的Web service消息作者：Srinath Perera, Ajith Ranabahu07/27/2005 翻譯：doomsday版權聲明：可以任意轉載，轉載時(shí)請務(wù)必以超鏈接形式標明文章原始出處和作者信息及本聲明
英文原文地址:
http://www.onjava.com/pub/a/onjava/2005/07/27/axis2.html中文地址:
http://www.matrix.org.cn/resource/article/43/43723_Apache_Axis2.html關(guān)鍵詞： Apache Axis2 Web service
到目前為止，web service交互作用是獨立同步的，同時(shí)本質(zhì)上是應答式的。不過(guò)，很顯然同步應答類(lèi)型在基于消息的應用中只是一個(gè)很小的子集。消息在耦合松散系統中是非常重要的，因此這種限制很關(guān)鍵。Web service規范，例如WS-addressing和WSDL，已經(jīng)融入了消息的概念并且為包含一個(gè)相當大范圍的消息應用奠定了基礎。Apache Axis2 架構既不基于任一個(gè)消息交換模式，也不基于同步/異步行為。這篇文章解釋了消息概念和Axis2在幾種眾所周知的消息場(chǎng)合中怎樣被擴展使用。
消息的簡(jiǎn)單介紹 貫穿計算歷史，分布式運算是其中的一個(gè)很大的挑戰：當資源是分布式時(shí)，進(jìn)程間的通信變得相當困難，研究人員仍然在尋找更好的解決方案。有趣的是，幾乎所有關(guān)于分布式計算機計算能力問(wèn)題的解決方案來(lái)源于兩種概念基礎： 遠程過(guò)程調用(RPC) 和消息傳遞。
毫無(wú)疑問(wèn)，使用RPC在開(kāi)發(fā)人員中是非常流行的技術(shù)，部分原因是是本地過(guò)程調用與它的類(lèi)似之處。本地過(guò)程調用在程序員中很有人氣，所以在分布式系統中使用RPC是很自然的選擇，而另一方面，消息傳遞不是非常流行，當它被提起時(shí)很少有開(kāi)發(fā)人員關(guān)注它。不過(guò)，在某些場(chǎng)合使用消息相比RPC系統有更好的優(yōu)勢。
RPC和消息框架的基本差異如下所示：
●消息完全不懂客戶(hù)端和服務(wù)器，因為一個(gè)消息框架（通常所說(shuō)的面向消息的中間件，或message-oriented middleware，即MOM）集中于傳遞消息，所有接收和散發(fā)消息的節點(diǎn)身份平等，術(shù)語(yǔ)稱(chēng)之為對等體。RPC始終有服務(wù)請求者 (AKA client) 和服務(wù)提供者 (AKA server)的概念。
●消息對于一個(gè)特定范疇是時(shí)間獨立的。沒(méi)有任何對等體希望實(shí)時(shí)接收消息－－當對等體可用時(shí)MOM關(guān)注于傳遞一個(gè)消息到相應的對等體，然而，RPC在失去一方時(shí)立即失效。
●消息可被復制并且輕易的傳遞到眾多對待體。RPC本質(zhì)上是一種一對一的交流方式，而消息更靈活，并且毫不費力地傳遞同一消息的拷貝到多種對等體。
Web service消息 Web service是在XML消息的基礎上定義的，下面3個(gè)因素描述了一個(gè)給定的Web service的消息交互。
●消息交換模式
●同步和異步客戶(hù)端API
●單向和雙向傳送行為
從最抽象的角度來(lái)講，，web service消息傳遞建立在發(fā)送和接收消息基礎上，一個(gè)給定的消息被一方發(fā)出，并且被另一方接收。消息可能相互關(guān)聯(lián)，識別這些相互關(guān)聯(lián)的消息群中的最常見(jiàn)的應用場(chǎng)合是非常重要的，這些消息群被定義為消息交換模式(message exchange patterns)，簡(jiǎn)稱(chēng)MEPs.
過(guò)渡時(shí)期下在兩種相關(guān)消息間的一個(gè)服務(wù)請求者的行為在客戶(hù)端API定義了消息同步/異步行為。同步場(chǎng)合下，客戶(hù)端請求將會(huì )阻塞，在相關(guān)消息到達目的地后前一直等待，在非阻塞場(chǎng)合下，客戶(hù)端請求不會(huì )阻塞，當相關(guān)消息到達時(shí)，它與之前的消息相互聯(lián)系。
傳送分類(lèi)為單向或雙向，基于單方或雙方行為。類(lèi)似SMTP和JMS傳送即是單向傳送的，不會(huì )阻塞，另一方面，類(lèi)似HTTP和TCP即是雙向傳送，相關(guān)消息可能在回路中返回，實(shí)際上，在Web service消息中，雙向傳送可能被用作單向傳送，但是在這些場(chǎng)合下，它們可被有效的處理為單向方式。
消息交換模式 根據W3C建議，消息交互模式就是一個(gè)為交流雙方構建消息交換的一個(gè)模板，一個(gè)MEP將相關(guān)消息確定為一組。MEPs根據服務(wù)請求者和服務(wù)提供者來(lái)定義，需要注意，為了清晰，MEPs以服務(wù)提供者的消息特性來(lái)命名。為方便理解，所有的命名都可以用request代替in, 用response代替out。
例如，我們看看兩個(gè)有名的MEPS
1.In-only/"發(fā)后不理:" 服務(wù)請求者發(fā)送消息給服務(wù)提供者但是不關(guān)心任何后繼相關(guān)消息
2.In-out/"應答式:" 服務(wù)請求者發(fā)送消息給服務(wù)提供者并希望返回結果
MEPS概念仍在擴展中，模式的數目是沒(méi)有限制的，所以Web service中間件應用強制使用幾種選定的MEPs，"發(fā)后不理"和 "應答式" 是被明確使用的，其它大多數的模式可由這兩種組合使用。
客戶(hù)端API同步/異步行為 同步/異步（或阻塞/非阻塞）行為是基于在web service請求的線(xiàn)程，同步服務(wù)將會(huì )阻塞，等待相關(guān)消息到達。另一方面，異步請求僅僅返回，等待相關(guān)消息被后臺另一個(gè)不同線(xiàn)程執行。
這兩種途徑有典型的用例?？紤]一下銀行事務(wù)，其需要一定數量的消息來(lái)來(lái)回傳遞。銀行事務(wù)本質(zhì)是連續的，當結果到達時(shí)后執行下一步驟，因此同步等待結果很有意義。另一方面，設想一個(gè)航班預約程序，其需要搜集多種數據來(lái)源，根據這些結果再匹配。這個(gè)案例中，異步行為發(fā)揮作用，因為程序可以提交所有結果并且當數據到達時(shí)工作?？紤]到網(wǎng)絡(luò )響應，異步方式獲得較好的結果。
同步請求很簡(jiǎn)單：請求在相關(guān)消息到達前等待，并且可以像本地過(guò)程調用一樣被編碼。但是異步消息的相互關(guān)系就比較復雜，客戶(hù)端必須處理這種復雜性。盡管如此，通過(guò)一些額外工作來(lái)處理這種復雜情況仍是必要的。
傳輸層的行為 傳輸層的行為是個(gè)關(guān)鍵因素，決定了Web service消息的發(fā)生，傳輸根據依據其行為分類(lèi)為單向和雙向。
單向傳送減少web service消息的復雜性，因為相關(guān)消息必須來(lái)源于各自的通道。另一方面，如果傳送是雙向的，消息有機會(huì )選擇使用單向還是雙向，例如，傳輸是HTTP時(shí)，相關(guān)消息來(lái)自HTTP連接的返回路徑，或者這么講web service提供者可以寫(xiě)HTTP 200來(lái)指出沒(méi)有來(lái)自同一連接的響應，在這種案例下回應經(jīng)由獨立的HTTP連接發(fā)送。
Web service尋址角色 webs ervice尋址框架（也被稱(chēng)為WS-addressing）是為了在同一web service交互活動(dòng)中交換不同信息部分，下面的5個(gè)因素定義了交互活動(dòng)：
1.消息交換模式
2.可被訪(fǎng)問(wèn)的服務(wù)傳送
3.相關(guān)消息傳送
4.傳送的行為
5.客戶(hù)端API的同步/異步行為
服務(wù)提供者申明了頭兩個(gè)，客戶(hù)端定義了其余因素，客戶(hù)端級別的同步/異步行為對服務(wù)提供者是完全透明的，客戶(hù)端使用WS-addressing來(lái)解釋web service消息。
在其它大多數結構中，WS-addressing定義了四種標題：To, ReplyTo, RelatesTo, FaultTo以及一個(gè)被稱(chēng)為匿名地址的特定地址，當一個(gè)服務(wù)提供者接收到SOAP消息時(shí)，它會(huì )查找在to地址上的目標服務(wù)并且調用服務(wù)。如果有結果，即被發(fā)送到ReplyTo地址，錯誤被發(fā)送到FaultTo地址，如果以上任一個(gè)的標題沒(méi)有指定或具有匿名值，結果通過(guò)雙向傳送返回路徑返回（因為匿名決定雙向傳送返回路徑）。
傳送和WS-addressing一起定義了查找相關(guān)消息的機制，消息是相關(guān)緣于它們共享了相同的傳送通道，也可能因為它們都共享把它們互相鏈接的公共信息。web service RelateTo標題正好提供了這種關(guān)系。
下面的表顯示的明確定義的消息交互活動(dòng)的尋址標題的不同值
Axis2客戶(hù)端API概念 Axis2客戶(hù)端API處理了In-Only和In-OutMEPs，所有的消息結合在下面的章節討論。MEPs的空間是無(wú)限的，因此，Axis2強制提供了支持任意消息交換模式的核心，并且提供了兩種常被使用的模式In-Only和In-Out的API，有兩種方法實(shí)現更多的復雜模式：組合In-Only和In-Out來(lái)完成希望的模式，或者對希望的模式寫(xiě)新的擴展。因為Axis2為任意MEP提供核心級別的支持，實(shí)現是顯而易見(jiàn)的。In-Only和In-OutMEPS被InOnlyMEPClient和InOutMEPClient類(lèi)支持，下兩節即做具體描述。
In-Only MEP 支持: InOnlyMEPClient InOnlyMEPClient類(lèi)對發(fā)送不理消息提供了支持，所有的傳送類(lèi)型作為單向傳送對待，InOnlyMEPClient和InOutMEPClient真正的差別是尋址參數起先沒(méi)有鎖定，并且尋址參數隨后被Axis2控制。作為可被控制的尋址參數，InOnlyMEPClient可被用作消息API，并且在此基礎上構建更復雜的消息交互。
In-Out MEP 支持: InOutMEPClient InOutMEPClient和繼承了InOutMEPClient的調用類(lèi)為應答式消息提供了支持，Axis2關(guān)注完整的操作，除了To地址外的所有的尋址屬性都在A(yíng)xis2的控制下
用戶(hù)可以配置InOutMEPClient 來(lái)表現不同，利用以下的四個(gè)參數。
1.發(fā)送者傳輸
2.監聽(tīng)者傳輸
3.是用單獨監聽(tīng)
4.使用阻塞
客戶(hù)端API當前提供了針對HTTP和SMTP傳輸的支持，下面的表格顯示了這些參數可能的組合以及它們怎樣結合來(lái)提供不同特效。
舉例 下面的代碼實(shí)例顯示了怎樣使用Apache Axis2做幾個(gè)定義明確的交互作用,用戶(hù)可以在客戶(hù)端API簡(jiǎn)單的轉換屬性從而轉換不同的交互作用，客戶(hù)端Axis2 API僅僅支持XML級別的消息和代表大塊XML的OME元素。
調用單向消息 單向MEP簡(jiǎn)單之處在于在僅有一個(gè)消息來(lái)回傳送時(shí)它能表現正確的單向，這些消息被異步對待并且傳送是單向的。
應答式消息 可以表現四種方式的應答式消息
1.雙向In-Out 同步
2.雙向In-Out 異步
3.單向In-Out 同步
4.單向In-Out 異步
下面的代碼實(shí)例說(shuō)明這些案例怎樣被Axis2尋址，注意客戶(hù)端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消息經(jīng)由同一個(gè)HTTP連接傳播，地址屬性沒(méi)有指定，所以它們在服務(wù)器方缺省為匿名，客戶(hù)端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消息經(jīng)由同一個(gè)HTTP連接傳輸并且不需要尋址，一旦回復消息到達客戶(hù)端API不會(huì )阻塞并且回調將被執行。
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);
在這個(gè)案例中，SOAP消息通過(guò)兩個(gè)HTTP連接傳輸，尋址是強制的，ReplyTo標題出現指示服務(wù)器端經(jīng)由單獨的通道發(fā)送回應?？蛻?hù)端沒(méi)有阻塞，當回應消息到達時(shí)，喚起回調。
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);
在這種場(chǎng)合下使用"In-Out,異步HTTP作為單向傳送"類(lèi)型，在結果到達第二種連接時(shí)喚起阻塞，執行并返回結果。
總結 總而言之，web wervice消息行為建立在三種因素上：消息交互模式，客戶(hù)端同步異步模式和傳送行為。Asis2建立核心在不一定要任何MEP類(lèi)型，不過(guò)為MEPs的廣泛支持：?jiǎn)蜗蚝蛻鹛峁┝丝蛻?hù)端API支持，這篇文章解釋Axis2消息支持概念和客戶(hù)端API的使用。
資源 ●
Apache Axis2的官方站點(diǎn)●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開(kāi)發(fā)者文集, 2002年6月1日
Srinath Perera是Apache Axis2的主要架構師
Ajith Ranabahu是Apache Axis2項目的成員并且在基于Web service的項目里工作了3年
