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