精彩的人生

摘要:

到目前為止，web service交互作用是獨(dú)立同步的，同時(shí)本質(zhì)上是應(yīng)答式的。不過，很顯然同步應(yīng)答類型在基于消息的應(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在幾種眾所周知的消息場合中怎樣被擴(kuò)展使用。

關(guān)于Apache Axis2的Web service消息
作者：Srinath Perera, Ajith Ranabahu
07/27/2005
翻譯：doomsday
版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時(shí)請務(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)答式的。不過，很顯然同步應(yīng)答類型在基于消息的應(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在幾種眾所周知的消息場合中怎樣被擴(kuò)展使用。

消息的簡單介紹

????貫穿計(jì)算歷史，分布式運(yùn)算是其中的一個(gè)很大的挑戰(zhàn)：當(dāng)資源是分布式時(shí)，進(jìn)程間的通信變得相當(dāng)困難，研究人員仍然在尋找更好的解決方案。有趣的是，幾乎所有關(guān)于分布式計(jì)算機(jī)計(jì)算能力問題的解決方案來源于兩種概念基礎(chǔ)： 遠(yuǎn)程過程調(diào)用(RPC) 和消息傳遞。

????毫無疑問，使用RPC在開發(fā)人員中是非常流行的技術(shù)，部分原因是是本地過程調(diào)用與它的類似之處。本地過程調(diào)用在程序員中很有人氣，所以在分布式系統(tǒng)中使用RPC是很自然的選擇，而另一方面，消息傳遞不是非常流行，當(dāng)它被提起時(shí)很少有開發(fā)人員關(guān)注它。不過，在某些場合使用消息相比RPC系統(tǒng)有更好的優(yōu)勢。

RPC和消息框架的基本差異如下所示：

●消息完全不懂客戶端和服務(wù)器，因?yàn)橐粋€(gè)消息框架（通常所說的面向消息的中間件，或message-oriented middleware，即MOM）集中于傳遞消息，所有接收和散發(fā)消息的節(jié)點(diǎn)身份平等，術(shù)語稱之為對(duì)等體。RPC始終有服務(wù)請求者 (AKA client) 和服務(wù)提供者 (AKA server)的概念。
●消息對(duì)于一個(gè)特定范疇是時(shí)間獨(dú)立的。沒有任何對(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的消息交互。

●消息交換模式
●同步和異步客戶端API
●單向和雙向傳送行為

????從最抽象的角度來講，，web service消息傳遞建立在發(fā)送和接收消息基礎(chǔ)上，一個(gè)給定的消息被一方發(fā)出，并且被另一方接收。消息可能相互關(guān)聯(lián)，識(shí)別這些相互關(guān)聯(lián)的消息群中的最常見的應(yīng)用場合是非常重要的，這些消息群被定義為消息交換模式(message exchange patterns)，簡稱MEPs.

????過渡時(shí)期下在兩種相關(guān)消息間的一個(gè)服務(wù)請求者的行為在客戶端API定義了消息同步/異步行為。同步場合下，客戶端請求將會(huì)阻塞，在相關(guān)消息到達(dá)目的地后前一直等待，在非阻塞場合下，客戶端請求不會(huì)阻塞，當(dāng)相關(guān)消息到達(dá)時(shí)，它與之前的消息相互聯(lián)系。

????傳送分類為單向或雙向，基于單方或雙方行為。類似SMTP和JMS傳送即是單向傳送的，不會(huì)阻塞，另一方面，類似HTTP和TCP即是雙向傳送，相關(guān)消息可能在回路中返回，實(shí)際上，在Web service消息中，雙向傳送可能被用作單向傳送，但是在這些場合下，它們可被有效的處理為單向方式。

消息交換模式

????根據(jù)W3C建議，消息交互模式就是一個(gè)為交流雙方構(gòu)建消息交換的一個(gè)模板，一個(gè)MEP將相關(guān)消息確定為一組。MEPs根據(jù)服務(wù)請求者和服務(wù)提供者來定義，需要注意，為了清晰，MEPs以服務(wù)提供者的消息特性來命名。為方便理解，所有的命名都可以用request代替in, 用response代替out。

例如，我們看看兩個(gè)有名的MEPS

1.In-only/"發(fā)后不理:" 服務(wù)請求者發(fā)送消息給服務(wù)提供者但是不關(guān)心任何后繼相關(guān)消息
2.In-out/"應(yīng)答式:" 服務(wù)請求者發(fā)送消息給服務(wù)提供者并希望返回結(jié)果

????MEPS概念仍在擴(kuò)展中，模式的數(shù)目是沒有限制的，所以Web service中間件應(yīng)用強(qiáng)制使用幾種選定的MEPs，"發(fā)后不理"和 "應(yīng)答式" 是被明確使用的，其它大多數(shù)的模式可由這兩種組合使用。

客戶端API同步/異步行為

????同步/異步（或阻塞/非阻塞）行為是基于在web service請求的線程，同步服務(wù)將會(huì)阻塞，等待相關(guān)消息到達(dá)。另一方面，異步請求僅僅返回，等待相關(guān)消息被后臺(tái)另一個(gè)不同線程執(zhí)行。

????這兩種途徑有典型的用例。考慮一下銀行事務(wù)，其需要一定數(shù)量的消息來來回傳遞。銀行事務(wù)本質(zhì)是連續(xù)的，當(dāng)結(jié)果到達(dá)時(shí)后執(zhí)行下一步驟，因此同步等待結(jié)果很有意義。另一方面，設(shè)想一個(gè)航班預(yù)約程序，其需要搜集多種數(shù)據(jù)來源，根據(jù)這些結(jié)果再匹配。這個(gè)案例中，異步行為發(fā)揮作用，因?yàn)槌绦蚩梢蕴峤凰薪Y(jié)果并且當(dāng)數(shù)據(jù)到達(dá)時(shí)工作。考慮到網(wǎng)絡(luò)響應(yīng)，異步方式獲得較好的結(jié)果。

????同步請求很簡單：請求在相關(guān)消息到達(dá)前等待，并且可以像本地過程調(diào)用一樣被編碼。但是異步消息的相互關(guān)系就比較復(fù)雜，客戶端必須處理這種復(fù)雜性。盡管如此，通過一些額外工作來處理這種復(fù)雜情況仍是必要的。

傳輸層的行為

????傳輸層的行為是個(gè)關(guān)鍵因素，決定了Web service消息的發(fā)生，傳輸根據(jù)依據(jù)其行為分類為單向和雙向。
????單向傳送減少web service消息的復(fù)雜性，因?yàn)橄嚓P(guān)消息必須來源于各自的通道。另一方面，如果傳送是雙向的，消息有機(jī)會(huì)選擇使用單向還是雙向，例如，傳輸是HTTP時(shí)，相關(guān)消息來自HTTP連接的返回路徑，或者這么講web service提供者可以寫HTTP 200來指出沒有來自同一連接的響應(yīng)，在這種案例下回應(yīng)經(jīng)由獨(dú)立的HTTP連接發(fā)送。

Web service尋址角色

????webs ervice尋址框架（也被稱為WS-addressing）是為了在同一web service交互活動(dòng)中交換不同信息部分，下面的5個(gè)因素定義了交互活動(dòng)：

????1.消息交換模式
????2.可被訪問的服務(wù)傳送
????3.相關(guān)消息傳送
????4.傳送的行為
????5.客戶端API的同步/異步行為

????服務(wù)提供者申明了頭兩個(gè)，客戶端定義了其余因素，客戶端級(jí)別的同步/異步行為對(duì)服務(wù)提供者是完全透明的，客戶端使用WS-addressing來解釋web service消息。

????在其它大多數(shù)結(jié)構(gòu)中，WS-addressing定義了四種標(biāo)題：To, ReplyTo, RelatesTo, FaultTo以及一個(gè)被稱為匿名地址的特定地址，當(dāng)一個(gè)服務(wù)提供者接收到SOAP消息時(shí)，它會(huì)查找在to地址上的目標(biāo)服務(wù)并且調(diào)用服務(wù)。如果有結(jié)果，即被發(fā)送到ReplyTo地址，錯(cuò)誤被發(fā)送到FaultTo地址，如果以上任一個(gè)的標(biāo)題沒有指定或具有匿名值，結(jié)果通過雙向傳送返回路徑返回（因?yàn)槟涿麤Q定雙向傳送返回路徑）。

????傳送和WS-addressing一起定義了查找相關(guān)消息的機(jī)制，消息是相關(guān)緣于它們共享了相同的傳送通道，也可能因?yàn)樗鼈兌脊蚕戆阉鼈兓ハ噫溄拥墓残畔ⅰeb service RelateTo標(biāo)題正好提供了這種關(guān)系。

下面的表顯示的明確定義的消息交互活動(dòng)的尋址標(biāo)題的不同值



Axis2客戶端API概念

????Axis2客戶端API處理了In-Only和In-OutMEPs，所有的消息結(jié)合在下面的章節(jié)討論。MEPs的空間是無限的，因此，Axis2強(qiáng)制提供了支持任意消息交換模式的核心，并且提供了兩種常被使用的模式In-Only和In-Out的API，有兩種方法實(shí)現(xiàn)更多的復(fù)雜模式：組合In-Only和In-Out來完成希望的模式，或者對(duì)希望的模式寫新的擴(kuò)展。因?yàn)锳xis2為任意MEP提供核心級(jí)別的支持，實(shí)現(xiàn)是顯而易見的。In-Only和In-OutMEPS被InOnlyMEPClient和InOutMEPClient類支持，下兩節(jié)即做具體描述。

In-Only MEP 支持: InOnlyMEPClient

????InOnlyMEPClient類對(duì)發(fā)送不理消息提供了支持，所有的傳送類型作為單向傳送對(duì)待，InOnlyMEPClient和InOutMEPClient真正的差別是尋址參數(shù)起先沒有鎖定，并且尋址參數(shù)隨后被Axis2控制。作為可被控制的尋址參數(shù)，InOnlyMEPClient可被用作消息API，并且在此基礎(chǔ)上構(gòu)建更復(fù)雜的消息交互。

In-Out MEP 支持: InOutMEPClient

????InOutMEPClient和繼承了InOutMEPClient的調(diào)用類為應(yīng)答式消息提供了支持，Axis2關(guān)注完整的操作，除了To地址外的所有的尋址屬性都在Axis2的控制下

????用戶可以配置InOutMEPClient 來表現(xiàn)不同，利用以下的四個(gè)參數(shù)。

1.發(fā)送者傳輸
2.監(jiān)聽者傳輸
3.是用單獨(dú)監(jiān)聽
4.使用阻塞



????客戶端API當(dāng)前提供了針對(duì)HTTP和SMTP傳輸?shù)闹С郑旅娴谋砀耧@示了這些參數(shù)可能的組合以及它們怎樣結(jié)合來提供不同特效。

舉例

????下面的代碼實(shí)例顯示了怎樣使用Apache Axis2做幾個(gè)定義明確的交互作用,用戶可以在客戶端API簡單的轉(zhuǎn)換屬性從而轉(zhuǎn)換不同的交互作用，客戶端Axis2 API僅僅支持XML級(jí)別的消息和代表大塊XML的OME元素。

調(diào)用單向消息

????單向MEP簡單之處在于在僅有一個(gè)消息來回傳送時(shí)它能表現(xiàn)正確的單向，這些消息被異步對(duì)待并且傳送是單向的。

應(yīng)答式消息

????可以表現(xiàn)四種方式的應(yīng)答式消息

????1.雙向In-Out 同步
????2.雙向In-Out 異步
????3.單向In-Out 同步
????4.單向In-Out 異步

????下面的代碼實(shí)例說明這些案例怎樣被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消息經(jīng)由同一個(gè)HTTP連接傳播，地址屬性沒有指定，所以它們在服務(wù)器方缺省為匿名，客戶端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á)客戶端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消息通過兩個(gè)HTTP連接傳輸，尋址是強(qiáng)制的，ReplyTo標(biāo)題出現(xiàn)指示服務(wù)器端經(jīng)由單獨(dú)的通道發(fā)送回應(yīng)。客戶端沒有阻塞，當(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);

????在這種場合下使用"In-Out,異步HTTP作為單向傳送"類型，在結(jié)果到達(dá)第二種連接時(shí)喚起阻塞，執(zhí)行并返回結(jié)果。

總結(jié)

????總而言之，web wervice消息行為建立在三種因素上：消息交互模式，客戶端同步異步模式和傳送行為。Asis2建立核心在不一定要任何MEP類型，不過為MEPs的廣泛支持：單向和應(yīng)答提供了客戶端API支持，這篇文章解釋Axis2消息支持概念和客戶端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開發(fā)者文集, 2002年6月1日

Srinath Perera是Apache Axis2的主要架構(gòu)師
Ajith Ranabahu是Apache Axis2項(xiàng)目的成員并且在基于Web service的項(xiàng)目里工作了3年