簡介
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-Addressing的目的
SOAP不提供標準的方法，來指定訊息的目的地、如何返迴響應或者在哪裡報告錯誤。這些細節以前留在傳輸層中。舉例來說，在標準SOAP請求通過 HTTP傳送的時候，HTTP請求的URI就作為訊息的目的地。訊息的回響保存在HTTP回響中，客戶端通過HTTP連線來接收。通過JMS異步傳送 SOAP請求訊息時，則可以在JMS訊息標頭中指定回響的目的地，將其合併在訊息主體中，或者保留在服務實現中。
在傳輸層上的定址對很多現有的服務來說已經夠用了，但是在其他服務的開發中它卻成了一種限制因素。WS-Addressing定義了通過多種傳輸路由訊息或者將回響直接傳遞到第三方的標準方式。舉例來說，客戶端應用程式可以通過JMS傳送請求，並要求通過電子郵件或者SMS接收回響。為了支持這些規範，WS-Addressing在SOAP信封中綜合了交付、答覆和錯誤處理程式的定址信息。下面的示例說明了使用WS-Addressing的典型SOAP訊息：
WS-Addressing還定義了一種標準，用於在一個地址中包含服務特定的屬性，該地址可以用於將訊息路由到服務中或者由目的地服務自身使用。這些屬性對創建有狀態的Web services特別有用，這些服務可以從特殊的客戶端接收一系列的請求，並記住這些請求之間的一些狀態信息。
核心構造
WS-Addressing為Web services辭彙表引入了兩種新的構造：端點參考和訊息定址屬性。“Endpoint”是一個用於訪問Web services的目的地的確定術語。端點參考是描述這些目的地的一種新模型。訊息定址屬性（可能會包含一個或者多個端點參考）提供了該目的地信息的上下文。
郵遞信封提供了一種優秀的非技術性類比：目的地地址的書寫位置在信封的中央，而回信地址的書寫位置在背面。單個地址的具體格式（姓名、街道、美國城市/州/郵政編碼）可以與端點參考進行類比。信封上的地址布局可以與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元素中指定。參考屬性指出，請求適用於基礎版本的服務。參考參數指定需要天氣預報的城市：
訊息定址屬性
如上所述，端點參考在訊息定址屬性中使用。訊息定址屬性定義了可以附加到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”：
除了必需的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元素就會提供一種標準方法，以關聯接收到的回覆和相應的請求。
用於開發人員的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暴露給多個異步客戶端所需的工作。如上所述，我們之中關注應用程式開發的人需要等待廠商推出適當的工具後才能充分利用這些機遇。
與其他新推出的Web services規範一樣，WS-Addressing的值價仍然有待在實踐中驗證。如果它產生了一個錯誤，那么當然不能說明首次推出它的主要廠商不具有繼續支撐它的能力。無論WS-Addressing會成為下一個重要規範，還是曇花一現，本文都希望您深入地了解一下規範的內容和可能需要對它進行的一些變更。
