關于Apache Axis2的Web service消息

2019-11-18 12:26:43

字體：大中小

來源：轉載

供稿：網友

　　到目前為止，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標題正好提供了這種關系。
　　
　　下面的表顯示的明確定義的消息交互活動的尋址標題的不同值
　　　關于Apache Axis2的Web service消息（圖一）

　　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.使用阻塞
　　關于Apache Axis2的Web service消息（圖二）

　　客戶端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.setTranspo

上一篇：回眸Java10周年：J2EE從起源到目的二

下一篇：網絡應用程序支持中文的簡單試驗