關於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年
