精彩的人生

摘要:

到目前為止，web service交互作用是獨立同步的，同時本質(zhì)上是應(yīng)答式的。不過，很顯然同步應(yīng)答類型在基于消息的應(yīng)用中只是一個很小的子集。消息在耦合松散系統(tǒng)中是非常重要的，因此這種限制很關(guān)鍵。Web service規(guī)范，例如WS-addressing和WSDL，已經(jīng)融入了消息的概念并且為包含一個相當大范圍的消息應(yīng)用奠定了基礎(chǔ)。Apache Axis2 架構(gòu)既不基于任一個消息交換模式，也不基于同步/異步行為。這篇文章解釋了消息概念和Axis2在幾種眾所周知的消息場合中怎樣被擴展使用。

關(guān)于Apache Axis2的Web service消息
作者：Srinath Perera, Ajith Ranabahu
07/27/2005
翻譯：doomsday
版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時請務(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交互作用是獨立同步的，同時本質(zhì)上是應(yīng)答式的。不過，很顯然同步應(yīng)答類型在基于消息的應(yīng)用中只是一個很小的子集。消息在耦合松散系統(tǒng)中是非常重要的，因此這種限制很關(guān)鍵。Web service規(guī)范，例如WS-addressing和WSDL，已經(jīng)融入了消息的概念并且為包含一個相當大范圍的消息應(yīng)用奠定了基礎(chǔ)。Apache Axis2 架構(gòu)既不基于任一個消息交換模式，也不基于同步/異步行為。這篇文章解釋了消息概念和Axis2在幾種眾所周知的消息場合中怎樣被擴展使用。

消息的簡單介紹

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

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

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

●消息完全不懂客戶端和服務(wù)器，因為一個消息框架（通常所說的面向消息的中間件，或message-oriented middleware，即MOM）集中于傳遞消息，所有接收和散發(fā)消息的節(jié)點身份平等，術(shù)語稱之為對等體。RPC始終有服務(wù)請求者 (AKA client) 和服務(wù)提供者 (AKA server)的概念。
●消息對于一個特定范疇是時間獨立的。沒有任何對等體希望實時接收消息－－當對等體可用時MOM關(guān)注于傳遞一個消息到相應(yīng)的對等體，然而，RPC在失去一方時立即失效。
●消息可被復(fù)制并且輕易的傳遞到眾多對待體。RPC本質(zhì)上是一種一對一的交流方式，而消息更靈活，并且毫不費力地傳遞同一消息的拷貝到多種對等體。

Web service消息

????Web service是在XML消息的基礎(chǔ)上定義的，下面3個因素描述了一個給定的Web service的消息交互。

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

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

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

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

消息交換模式

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

例如，我們看看兩個有名的MEPS

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

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

客戶端API同步/異步行為

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

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

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

傳輸層的行為

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

Web service尋址角色

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

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

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

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

????傳送和WS-addressing一起定義了查找相關(guān)消息的機制，消息是相關(guān)緣于它們共享了相同的傳送通道，也可能因為它們都共享把它們互相鏈接的公共信息。web service RelateTo標題正好提供了這種關(guān)系。

下面的表顯示的明確定義的消息交互活動的尋址標題的不同值



Axis2客戶端API概念

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

In-Only MEP 支持: InOnlyMEPClient

????InOnlyMEPClient類對發(fā)送不理消息提供了支持，所有的傳送類型作為單向傳送對待，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)不同，利用以下的四個參數(shù)。

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



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

舉例

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

調(diào)用單向消息

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

應(yīng)答式消息

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

????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消息經(jīng)由同一個HTTP連接傳播，地址屬性沒有指定，所以它們在服務(wù)器方缺省為匿名，客戶端API將被鎖定直到回復(fù)消息到達。

????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)由同一個HTTP連接傳輸并且不需要尋址，一旦回復(fù)消息到達客戶端API不會阻塞并且回調(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);

????在這個案例中，SOAP消息通過兩個HTTP連接傳輸，尋址是強制的，ReplyTo標題出現(xiàn)指示服務(wù)器端經(jīng)由單獨的通道發(fā)送回應(yīng)。客戶端沒有阻塞，當回應(yīng)消息到達時，喚起回調(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é)果到達第二種連接時喚起阻塞，執(zhí)行并返回結(jié)果。

總結(jié)

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

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