-
WS-Addressing
鎖定
Web服務尋址（WS-Addressing）是一個W3C推薦標準，為Web服務提供一種與傳輸層無關的，傳送尋址信息的機制。規範主要由兩部分組成：傳送Web服務端點的引用的數據結構，以及一套能夠在特定的消息上關聯尋址信息的消息尋址屬性。
- 中文名
- WS-Addressing
- 外文名
- WS-Addressing
- 類 型
- 消息中的標準
- 簡 稱
- WS-*
- 主要技術廠商
- Microsoft、Sun、BEA、IBM和SAP
目錄
WS-Addressing簡介
Web services規範也稱為WS-*，主要是主要技術廠商（如Microsoft、Sun、BEA、IBM和SAP）協同工作的結果。其中一些規範（包括WS-Addressing）是在World Wide Web Consortium（W3C）的監督下制定的。WS-Addressing規範（在2004年8月被W3C接受為成員）提供了一種在Web services消息和服務描述中表示消息尋址信息的標準。
W3C的Web Services Addressing Working Group正在修訂和最終確定WS-Addressing規範。我們可以明確地期望看到規範進行了很多更改，因為大量的問題仍需要解決。例如，在2005年1月，工作組一致同意去掉下面將要講述的“參考屬性”特性，但是該決議仍未公開發表。儘管更改仍在進行之中，但是WS-Addressing的中心思想是不變的，因此現在非常適合開發人員先了解一下該規範。
WS-*的所有規範都是基於SOAP設計的。他們為在SOAP消息的標頭塊（header block）中使用定義了XML schema。通過設計，WS-*規範之間的依賴性非常小了。這一點有助於開發人員僅使用他們所需的規範。WS-Addressing和其它WS-*規範之間是相互獨立的，但是可以一起使用。舉例來説，一種規範可以使用WS-Addressing來識別消息的來源和目的地，還可以使用WS- Security對到目的地的來源進行身份驗證。
WS-Addressing還和Web Services Description Language 1.1 (WSDL)有着微妙的聯繫。它擴展和綜合了來自WSDL的一些概念，但是這兩者之間沒有明確的依賴性。Web services開發人員可以使用其中之一，也可以使用兩者，這取決於他們的需求。WSDL提供了一份可以使用抽象（消息發送和接受）和具體兩種術語（傳輸和有線格式）描述服務的詞彙表。WS-Addressing利用WSDL的“服務”和“端口”概念，如下所述。
WS-Addressing目前已經發布了三種不同的規範，WS-Addressing Core、WS-Addressing SOAP Binding和WS-Addressing WSDL Binding。核心規範描述抽象屬性，而捆綁文檔解釋瞭如何分別使用SOAP和WSDL來表示這些屬性。核心/捆綁文檔分析在Web services規範中很常見。在此，核心規範對應用程序開發人員來説比捆綁文檔更為重要，因為Web services資料庫和開發人員工具通常封裝捆綁文檔的細節。
WS-AddressingWS-Addressing的目的
SOAP不提供標準的方法，來指定消息的目的地、如何返回響應或者在哪裏報告錯誤。這些細節以前留在傳輸層中。舉例來説，在標準SOAP請求通過 HTTP發送的時候，HTTP請求的URI就作為消息的目的地。消息的響應保存在HTTP響應中，客户端通過HTTP連接來接收。通過JMS異步發送 SOAP請求消息時，則可以在JMS消息標頭中指定響應的目的地，將其合併在消息主體中，或者保留在服務實現中。
在傳輸層上的尋址對很多現有的服務來説已經夠用了，但是在其他服務的開發中它卻成了一種限制因素。WS-Addressing定義了通過多種傳輸路由消息或者將響應直接傳遞到第三方的標準方式。舉例來説，客户端應用程序可以通過JMS發送請求，並要求通過電子郵件或者SMS接收響應。為了支持這些規範，WS-Addressing在SOAP信封中綜合了交付、答覆和錯誤處理程序的尋址信息。下面的示例説明了使用WS-Addressing的典型SOAP消息：
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2004/12/addressing"> <S:Header> <wsa:MessageID> http://example.com/SomeUniqueMessageIdString </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://myClient.example/someClientUser</wsa:Address> </wsa:ReplyTo> <wsa:FaultTo> <wsa:Address>http://myserver.example/DemoErrorHandler</wsa:Address> </wsa:FaultTo> <wsa:To>http://myserver.example/DemoServiceURI</wsa:To> <wsa:Action>http://myserver.example/DoSomething</wsa:Action> </S:Header> <S:Body> <!-- The message body of the SOAP request appears here --> </S:Body> </S:Envelope>
WS-Addressing還定義了一種標準，用於在一個地址中包含服務特定的屬性，該地址可以用於將消息路由到服務中或者由目的地服務自身使用。這些屬性對創建有狀態的Web services特別有用，這些服務可以從特殊的客户端接收一系列的請求，並記住這些請求之間的一些狀態信息。
WS-Addressing核心構造
WS-Addressing為Web services詞彙表引入了兩種新的構造：端點參考和消息尋址屬性。“Endpoint”是一個用於訪問Web services的目的地的確定術語。端點參考是描述這些目的地的一種新模型。消息尋址屬性（可能會包含一個或者多個端點參考）提供了該目的地信息的上下文。
郵遞信封提供了一種優秀的非技術性類比：目的地地址的書寫位置在信封的中央，而回信地址的書寫位置在背面。單個地址的具體格式（姓名、街道、美國城市/州/郵政編碼）可以與端點參考進行類比。信封上的地址佈局可以與WS-Addressing的消息尋址屬性進行類比。
WS-Addressing分析端點參考
在WS-Addressing schema中，端點參考被定義為一種複雜類型。端點參考類型包含地址（URI）、參考屬性、參考參數、端口類型、服務名稱、策略元素（由WS- Policy規範定義）。端點參考唯一必需的元素是地址，因此可能的最簡單端點參考就是一個URI：
<wsa:Address>http://ws.example.com/myservice</wsa:Address>
端點參考的其他元素全部是可選的，這一點可以使您選用所需的元素更加方便。端口類型和服務名稱元素非常類似於它們的WSDL對等物。WSDL將端口類型定義為一種附加到操作的抽象集合中的標識名稱。捆綁文檔指定了端口類型的具體輸入和輸出。該類型的端口表示捆綁文檔在特定地址上的部署。服務是端口的指定集合。與在WSDL中一樣，在WS-Addressing中，端口類型和服務名稱是QNames（合格名稱）。WS-Addressing端點參考中的端口類型和服務名稱必須具備與WSDL的兼容性，而不是完全將其替代。
端點參考的一個重要方面是通過參考屬性或者參考參數在自己的XML名稱空間中附加數據的能力。這兩種元素都是屬性和值的集合，您可以使用這些屬性和值將元素從自己的XML名稱空間（或者任意XML名稱空間）綜合到端點參考中。參考屬性和參考參數之間的主要區別不在於格式，而是既定的用途不同。
參考屬性可以用於識別服務部署的端點。共享同一個URI，但是指定了不同參考屬性值的兩個端點參考表示兩種不同的服務。參考屬性用於將請求發送到恰當的服務中。舉例來説，您可以部署兩種不同版本的服務，並讓請求在其參考參數中指定目標版本。如果一個服務接收到一個請求並執行該請求，則其行為應當等同於參考屬性中的響應。
對比來説，參考參數必須識別特定服務託管的資源。參考參數向服務説明要處理的資源。他們無法識別服務。具有不同參考參數的兩個端點參考參考相同的服務。
以下示例説明了向大眾提供天氣預報信息服務的端點參考，同時還可以向高級用户提供更加詳細的信息。服務的URI在Address元素中指定。參考屬性指出，請求適用於基礎版本的服務。參考參數指定需要天氣預報的城市：
<wsa:EndpointReference xmlns:wsa="..." xmlns:example="..."> <wsa:Address>http://example.com/weather</wsa:Address> <wsa:ReferenceProperties> <example:ServiceLevel>Basic</example:ServiceLevel> </wsa:ReferenceProperties> <wsa:ReferenceParameters> <example:CityCode>NYC</example:CityCode> </wsa:ReferenceParameters> </wsa:EndpointReference>
WS-Addressing消息尋址屬性
如上所述，端點參考在消息尋址屬性中使用。消息尋址屬性定義了可以附加到SOAP消息中的尋址信息的完整集合。大多數字段是可選的；唯有To和Action兩個字段是必需的，每個字段指定一個URI。在HTTP請求中，它們將是同一個URI。
在非HTTP請求中，To URI可能不同於Action URI。To URI是請求提交到的位置，而Action URI指出需要採取的操作。Action URI應當表示一種符合WSDL端口類型的服務（參看上文）。舉例來説，通過電子郵件或者SMS發送的請求可以到達WSDL端口類型不表示的目的地中。將To URI和Action URI分開為配置Web services目的地提供了很多靈活性。舉例來説，電子郵件地址可以接收不同服務的請求，全部通過其Action URI值進行識別。To URI指定“where”，而Action URI指定“what”：
<!-- Message 1 --> <wsa:To>mailto:ws@example.com</wsa:To> <wsa:Action>http://example.com/aservice</wsa:Action> // ... <!-- Message 2 --> <wsa:To>mailto:ws@example.com</wsa:To> <wsa:Action>http://example.com/anotherservice</wsa:Action> // ...
除了必需的To和Action URI，消息尋址屬性還包含幾種可選的元素。ReplyTo和FaultTo元素的作用是不解自明的。ReplyTo端點必須僅在發送方期望進行響應的時候才能指定，但是它可以將響應路由到任何有效的端點中。FaultTo始終是可選的，它可以將SOAP錯誤消息路由到指定的端點參考中。此外，服務的消費者可以使用From端點參考元素來向服務標識他們自身。明確地區分消息源端點、預期的回覆端點和錯誤處理端點可以幫助WS-Addressing支持我們通常與Web services關聯的簡單請求/回覆交互之外的多種消息模型。
需要回復時，無論是發送方期望該回復還是由第三方端點在ReplyTo標頭中指定，都必須表示MessageId元素。消息的ID是一個獨特的URI。由於Web services可以通過不可靠的傳輸使用，因此端點就很可能會接收到重複的消息複本。消息ID可以用於避免重複處理同一消息。
當服務接收到使用WS-Addressing尋址的消息時，它還會在回覆消息中包含WS-Addressing標頭。原始消息的消息ID成為了回覆地址中的RelatesTo元素。目前，唯一受支持的關係類型是“Reply”。如果客户端正在發送多個Web services請求和接收異步響應（可能通過不同的傳輸），那麼RelatesTo元素就會提供一種標準方法，以關聯接收到的回覆和相應的請求。
[1]
WS-Addressing用於開發人員的WS-Addressing
使用WS-Addressing的開發人員工具正在推廣過程中，但是仍沒有得到廣泛應用。如果您現有的Web services應用程序依靠WebLogic Workshop、Apache Axis或者其他可以生成Java API Web services接口的工具，那麼您需要等待這些環境的擴展才能包括WS-Addressing。因為WS-Addressing是由主要的大型企業廠商推動開發的，新的適用於開發人員的WS-Addressing工具應當會在2005年推出。
對於使用Web services通過HTTP直接遠程訪問對象的應用程序來説，WS-Addressing不是一款解決方案。因為HTTP請求和響應通過單個HTTP連接同步發生，尋址意義不大。BEA的Dave Orchard（WS-Addressing合著人員）最近發表了一篇blog entry來探討WS-Addressing和HTTP的可能性。即使對於WS-Addressing的編寫人員來説，在這一點上通過HTTP體現出來的WS-Addressing的價值也不是顯而易見的。如果Web services僅僅是為HTTP客户端提供的，則WS-*規範的“按需使用”本質會更容易地忽略WS-Addressing（直到其變得相關）。
WS-Addressing為通過異步傳輸使用Web services的開發人員提供了更多優勢。跨多種傳輸使用一致的尋址模式可以簡化一些集成問題和幫助開發人員實現系統，在該系統中，調度程序使用端點參考將請求路由到幾個相關服務中的一箇中。隨着移動計算變得日益重要，異步Web services對支持具有有限網絡訪問權限的移動客户端來説非常有用。尋址的一般模型可以幫助最大程度減少將Web services暴露給多個異步客户端所需的工作。如上所述，我們之中關注應用程序開發的人需要等待廠商推出適當的工具後才能充分利用這些機遇。
- 詞條統計
-
- 瀏覽次數：次
- 編輯次數：8次歷史版本
- 最近更新： 王斯坦王