摘要
　　WS-Addressing規(guī)范定義了一種將消息尋址信息綜合到Web services消息中的標(biāo)準(zhǔn)。WS-Addressing為以同步和/或異步方式傳輸?shù)腟OAP消息提供了一種統(tǒng)一的尋址方法。此外，它還提供了尋址功能來幫助Web service開發(fā)人員在請求和響應(yīng)的典型交換之外，圍繞各種消息傳遞模式構(gòu)建應(yīng)用程序。本文介紹WS-Addressing，描述其組件，并研究其對開發(fā)人員的潛在價值。

簡介
　　Web services規(guī)范也稱為WS-*，主要是主要技術(shù)廠商（如Microsoft、Sun、BEA、IBM和SAP）協(xié)同工作的結(jié)果。其中一些規(guī)范（包括WS-Addressing）是在World Wide Web Consortium（W3C）的監(jiān)督下制定的。WS-Addressing規(guī)范（在2004年8月被W3C接受為成員）提供了一種在Web services消息和服務(wù)描述中表示消息尋址信息的標(biāo)準(zhǔn)。
　　W3C的Web Services Addressing Working Group正在修訂和最終確定WS-Addressing規(guī)范。我們可以明確地期望看到規(guī)范進(jìn)行了很多更改，因?yàn)榇罅康膯栴}仍需要解決。例如，在2005年1月，工作組一致同意去掉下面將要講述的“參考屬性”特性，但是該決議仍未公開發(fā)表。盡管更改仍在進(jìn)行之中，但是WS-Addressing的中心思想是不變的，因此現(xiàn)在非常適合開發(fā)人員先了解一下該規(guī)范。
　　WS-*的所有規(guī)范都是基于SOAP設(shè)計的。他們?yōu)樵赟OAP消息的標(biāo)頭塊（header block）中使用定義了XML schema。通過設(shè)計，WS-*規(guī)范之間的依賴性非常小了。這一點(diǎn)有助于開發(fā)人員僅使用他們所需的規(guī)范。WS-Addressing和其它WS-*規(guī)范之間是相互獨(dú)立的，但是可以一起使用。舉例來說，一種規(guī)范可以使用WS-Addressing來識別消息的來源和目的地，還可以使用WS-Security對到目的地的來源進(jìn)行身份驗(yàn)證。
　　WS-Addressing還和Web Services Description Language 1.1 (WSDL)有著微妙的聯(lián)系。它擴(kuò)展和綜合了來自WSDL的一些概念，但是這兩者之間沒有明確的依賴性。Web services開發(fā)人員可以使用其中之一，也可以使用兩者，這取決于他們的需求。WSDL提供了一份可以使用抽象（消息發(fā)送和接受）和具體兩種術(shù)語（傳輸和有線格式）描述服務(wù)的詞匯表。WS-Addressing利用WSDL的“服務(wù)”和“端口”概念，如下所述。
　　WS-Addressing目前已經(jīng)發(fā)布了三種不同的規(guī)范，WS-Addressing Core、WS-Addressing SOAP Binding和WS-Addressing WSDL Binding。核心規(guī)范描述抽象屬性，而捆綁文檔解釋了如何分別使用SOAP和WSDL來表示這些屬性。核心/捆綁文檔分析在Web services規(guī)范中很常見。在此，核心規(guī)范對應(yīng)用程序開發(fā)人員來說比捆綁文檔更為重要，因?yàn)閃eb services資料庫和開發(fā)人員工具通常封裝捆綁文檔的細(xì)節(jié)。

WS-Addressing的目的
　　SOAP不提供標(biāo)準(zhǔn)的方法，來指定消息的目的地、如何返回響應(yīng)或者在哪里報告錯誤。這些細(xì)節(jié)以前留在傳輸層中。舉例來說，在標(biāo)準(zhǔn)SOAP請求通過HTTP發(fā)送的時候，HTTP請求的URI就作為消息的目的地。消息的響應(yīng)保存在HTTP響應(yīng)中，客戶端通過HTTP連接來接收。通過JMS異步發(fā)送SOAP請求消息時，則可以在JMS消息標(biāo)頭中指定響應(yīng)的目的地，將其合并在消息主體中，或者保留在服務(wù)實(shí)現(xiàn)中。
　　在傳輸層上的尋址對很多現(xiàn)有的服務(wù)來說已經(jīng)夠用了，但是在其他服務(wù)的開發(fā)中它卻成了一種限制因素。WS-Addressing定義了通過多種傳輸路由消息或者將響應(yīng)直接傳遞到第三方的標(biāo)準(zhǔn)方式。舉例來說，客戶端應(yīng)用程序可以通過JMS發(fā)送請求，并要求通過電子郵件或者SMS接收響應(yīng)。為了支持這些規(guī)范，WS-Addressing在SOAP信封中綜合了交付、答復(fù)和錯誤處理程序的尋址信息。下面的示例說明了使用WS-Addressing的典型SOAP消息：

<S:Envelope xmlns:S="http://www./2003/05/soap-envelope"
                xmlns:wsa="http://www./2004/12/addressing">
    <S:Header>
        <wsa:MessageID>
            http:///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還定義了一種標(biāo)準(zhǔn)，用于在一個地址中包含服務(wù)特定的屬性，該地址可以用于將消息路由到服務(wù)中或者由目的地服務(wù)自身使用。這些屬性對創(chuàng)建有狀態(tài)的Web services特別有用，這些服務(wù)可以從特殊的客戶端接收一系列的請求，并記住這些請求之間的一些狀態(tài)信息。

核心構(gòu)造
　　WS-Addressing為Web services詞匯表引入了兩種新的構(gòu)造：端點(diǎn)參考和消息尋址屬性。“Endpoint”是一個用于訪問Web services的目的地的確定術(shù)語。端點(diǎn)參考是描述這些目的地的一種新模型。消息尋址屬性（可能會包含一個或者多個端點(diǎn)參考）提供了該目的地信息的上下文。
　　郵遞信封提供了一種優(yōu)秀的非技術(shù)性類比：目的地地址的書寫位置在信封的中央，而回信地址的書寫位置在背面。單個地址的具體格式（姓名、街道、美國城市/州/郵政編碼）可以與端點(diǎn)參考進(jìn)行類比。信封上的地址布局可以與WS-Addressing的消息尋址屬性進(jìn)行類比。

分析端點(diǎn)參考
　　在WS-Addressing schema中，端點(diǎn)參考被定義為一種復(fù)雜類型。端點(diǎn)參考類型包含地址（URI）、參考屬性、參考參數(shù)、端口類型、服務(wù)名稱、策略元素（由WS-Policy規(guī)范定義）。端點(diǎn)參考唯一必需的元素是地址，因此可能的最簡單端點(diǎn)參考就是一個URI：

<wsa:Address>http://ws./myservice</wsa:Address>

　　端點(diǎn)參考的其他元素全部是可選的，這一點(diǎn)可以使您選用所需的元素更加方便。端口類型和服務(wù)名稱元素非常類似于它們的WSDL對等物。WSDL將端口類型定義為一種附加到操作的抽象集合中的標(biāo)識名稱。捆綁文檔指定了端口類型的具體輸入和輸出。該類型的端口表示捆綁文檔在特定地址上的部署。服務(wù)是端口的指定集合。與在WSDL中一樣，在WS-Addressing中，端口類型和服務(wù)名稱是QNames（合格名稱）。WS-Addressing端點(diǎn)參考中的端口類型和服務(wù)名稱必須具備與WSDL的兼容性，而不是完全將其替代。
　　端點(diǎn)參考的一個重要方面是通過參考屬性或者參考參數(shù)在自己的XML名稱空間中附加數(shù)據(jù)的能力。這兩種元素都是屬性和值的集合，您可以使用這些屬性和值將元素從自己的XML名稱空間（或者任意XML名稱空間）綜合到端點(diǎn)參考中。參考屬性和參考參數(shù)之間的主要區(qū)別不在于格式，而是既定的用途不同。
　　參考屬性可以用于識別服務(wù)部署的端點(diǎn)。共享同一個URI，但是指定了不同參考屬性值的兩個端點(diǎn)參考表示兩種不同的服務(wù)。參考屬性用于將請求發(fā)送到恰當(dāng)?shù)姆?wù)中。舉例來說，您可以部署兩種不同版本的服務(wù)，并讓請求在其參考參數(shù)中指定目標(biāo)版本。如果一個服務(wù)接收到一個請求并執(zhí)行該請求，則其行為應(yīng)當(dāng)?shù)韧趨⒖紝傩灾械捻憫?yīng)。
　　對比來說，參考參數(shù)必須識別特定服務(wù)托管的資源。參考參數(shù)向服務(wù)說明要處理的資源。他們無法識別服務(wù)。具有不同參考參數(shù)的兩個端點(diǎn)參考參考相同的服務(wù)。
　　以下示例說明了向大眾提供天氣預(yù)報信息服務(wù)的端點(diǎn)參考，同時還可以向高級用戶提供更加詳細(xì)的信息。服務(wù)的URI在Address元素中指定。參考屬性指出，請求適用于基礎(chǔ)版本的服務(wù)。參考參數(shù)指定需要天氣預(yù)報的城市：

<wsa:EndpointReference xmlns:wsa="..." xmlns:example="...">
<wsa:Address>http:///weather</wsa:Address>
<wsa:ReferenceProperties>
<example:ServiceLevel>Basic</example:ServiceLevel>
</wsa:ReferenceProperties>
<wsa:ReferenceParameters>
<example:CityCode>NYC</example:CityCode>
</wsa:ReferenceParameters>
</wsa:EndpointReference>

消息尋址屬性
　　如上所述，端點(diǎn)參考在消息尋址屬性中使用。消息尋址屬性定義了可以附加到SOAP消息中的尋址信息的完整集合。大多數(shù)字段是可選的；唯有To和Action兩個字段是必需的，每個字段指定一個URI。在HTTP請求中，它們將是同一個URI。
　　在非HTTP請求中，To URI可能不同于Action URI。To URI是請求提交到的位置，而Action URI指出需要采取的操作。Action URI應(yīng)當(dāng)表示一種符合WSDL端口類型的服務(wù)（參看上文）。舉例來說，通過電子郵件或者SMS發(fā)送的請求可以到達(dá)WSDL端口類型不表示的目的地中。將To URI和Action URI分開為配置Web services目的地提供了很多靈活性。舉例來說，電子郵件地址可以接收不同服務(wù)的請求，全部通過其Action URI值進(jìn)行識別。To URI指定“where”，而Action URI指定“what”：

<!-- Message 1 -->
<wsa:To>mailto:ws@</wsa:To>
<wsa:Action>http:///aservice</wsa:Action>
// ...
<!-- Message 2 -->
<wsa:To>mailto:ws@</wsa:To>
<wsa:Action>http:///anotherservice</wsa:Action>
// ...

　　除了必需的To和Action URI，消息尋址屬性還包含幾種可選的元素。ReplyTo和FaultTo元素的作用是不解自明的。ReplyTo端點(diǎn)必須僅在發(fā)送方期望進(jìn)行響應(yīng)的時候才能指定，但是它可以將響應(yīng)路由到任何有效的端點(diǎn)中。FaultTo始終是可選的，它可以將SOAP錯誤消息路由到指定的端點(diǎn)參考中。此外，服務(wù)的消費(fèi)者可以使用From端點(diǎn)參考元素來向服務(wù)標(biāo)識他們自身。明確地區(qū)分消息源端點(diǎn)、預(yù)期的回復(fù)端點(diǎn)和錯誤處理端點(diǎn)可以幫助WS-Addressing支持我們通常與Web services關(guān)聯(lián)的簡單請求/回復(fù)交互之外的多種消息模型。
　　需要回復(fù)時，無論是發(fā)送方期望該回復(fù)還是由第三方端點(diǎn)在ReplyTo標(biāo)頭中指定，都必須表示MessageId元素。消息的ID是一個獨(dú)特的URI。由于Web services可以通過不可靠的傳輸使用，因此端點(diǎn)就很可能會接收到重復(fù)的消息復(fù)本。消息ID可以用于避免重復(fù)處理同一消息。
　　當(dāng)服務(wù)接收到使用WS-Addressing尋址的消息時，它還會在回復(fù)消息中包含WS-Addressing標(biāo)頭。原始消息的消息ID成為了回復(fù)地址中的RelatesTo元素。目前，唯一受支持的關(guān)系類型是“Reply”。如果客戶端正在發(fā)送多個Web services請求和接收異步響應(yīng)（可能通過不同的傳輸），那么RelatesTo元素就會提供一種標(biāo)準(zhǔn)方法，以關(guān)聯(lián)接收到的回復(fù)和相應(yīng)的請求。

用于開發(fā)人員的WS-Addressing
　　使用WS-Addressing的開發(fā)人員工具正在推廣過程中，但是仍沒有得到廣泛應(yīng)用。如果您現(xiàn)有的Web services應(yīng)用程序依靠WebLogic Workshop、Apache Axis或者其他可以生成Java API Web services接口的工具，那么您需要等待這些環(huán)境的擴(kuò)展才能包括WS-Addressing。因?yàn)閃S-Addressing是由主要的大型企業(yè)廠商推動開發(fā)的，新的適用于開發(fā)人員的WS-Addressing工具應(yīng)當(dāng)會在2005年推出。
　　對于使用Web services通過HTTP直接遠(yuǎn)程訪問對象的應(yīng)用程序來說，WS-Addressing不是一款解決方案。因?yàn)镠TTP請求和響應(yīng)通過單個HTTP連接同步發(fā)生，尋址意義不大。BEA的Dave Orchard（WS-Addressing合著人員）最近發(fā)表了一篇blog entry來探討WS-Addressing和HTTP的可能性。即使對于WS-Addressing的編寫人員來說，在這一點(diǎn)上通過HTTP體現(xiàn)出來的WS-Addressing的價值也不是顯而易見的。如果Web services僅僅是為HTTP客戶端提供的，則WS-*規(guī)范的“按需使用”本質(zhì)會更容易地忽略WS-Addressing（直到其變得相關(guān)）。
　　WS-Addressing為通過異步傳輸使用Web services的開發(fā)人員提供了更多優(yōu)勢?？缍喾N傳輸使用一致的尋址模式可以簡化一些集成問題和幫助開發(fā)人員實(shí)現(xiàn)系統(tǒng)，在該系統(tǒng)中，調(diào)度程序使用端點(diǎn)參考將請求路由到幾個相關(guān)服務(wù)中的一個中。隨著移動計算變得日益重要，異步Web services對支持具有有限網(wǎng)絡(luò)訪問權(quán)限的移動客戶端來說非常有用。尋址的一般模型可以幫助最大程度減少將Web services暴露給多個異步客戶端所需的工作。如上所述，我們之中關(guān)注應(yīng)用程序開發(fā)的人需要等待廠商推出適當(dāng)?shù)墓ぞ吆蟛拍艹浞掷眠@些機(jī)遇。
　　與其他新推出的Web services規(guī)范一樣，WS-Addressing的值價仍然有待在實(shí)踐中驗(yàn)證。如果它產(chǎn)生了一個錯誤，那么當(dāng)然不能說明首次推出它的主要廠商不具有繼續(xù)支撐它的能力。無論WS-Addressing會成為下一個重要規(guī)范，還是曇花一現(xiàn)，本文都希望您深入地了解一下規(guī)范的內(nèi)容和可能需要對它進(jìn)行的一些變更。

 

original website: http://dev2dev./techdoc/2005050904.html