摘要
WS-Addressing規范定義了一種將消息尋址信息綜合到Web services消息中的標準。WS-Addressing為以同步和/或異步方式傳輸的SOAP消息提供了一種統一的尋址方法。此外,它還提供了尋址功能來(lái)幫助Web service開(kāi)發(fā)人員在請求和響應的典型交換之外,圍繞各種消息傳遞模式構建應用程序。本文介紹WS-Addressing,描述其組件,并研究其對開(kāi)發(fā)人員的潛在價(jià)值。
簡(jiǎn)介 Web services規范也稱(chēng)為WS-*,主要是主要技術(shù)廠(chǎng)商(如Microsoft、Sun、BEA、IBM和SAP)協(xié)同工作的結果。其中一些規范(包括WS-Addressing)是在World Wide Web Consortium(W3C)的監督下制定的。WS-Addressing規范(在2004年8月被W3C接受為成員)提供了一種在Web services消息和服務(wù)描述中表示消息尋址信息的標準。
W3C的
Web Services Addressing Working Group正在修訂和最終確定WS-Addressing規范。我們可以明確地期望看到規范進(jìn)行了很多更改,因為大量的問(wèn)題仍需要解決。例如,在2005年1月,工作組一致同意去掉下面將要講述的“參考屬性”特性,但是該決議仍未公開(kāi)發(fā)表。盡管更改仍在進(jìn)行之中,但是WS-Addressing的中心思想是不變的,因此現在非常適合開(kāi)發(fā)人員先了解一下該規范。
WS-*的所有規范都是基于SOAP設計的。他們?yōu)樵赟OAP消息的標頭塊(header block)中使用定義了XML schema。通過(guò)設計,WS-*規范之間的依賴(lài)性非常小了。這一點(diǎn)有助于開(kāi)發(fā)人員僅使用他們所需的規范。WS-Addressing和其它WS-*規范之間是相互獨立的,但是可以一起使用。舉例來(lái)說(shuō),一種規范可以使用WS-Addressing來(lái)識別消息的來(lái)源和目的地,還可以使用WS-Security對到目的地的來(lái)源進(jìn)行身份驗證。
WS-Addressing還和
Web Services Description Language 1.1 (WSDL)有著(zhù)微妙的聯(lián)系。它擴展和綜合了來(lái)自WSDL的一些概念,但是這兩者之間沒(méi)有明確的依賴(lài)性。Web services開(kāi)發(fā)人員可以使用其中之一,也可以使用兩者,這取決于他們的需求。WSDL提供了一份可以使用抽象(消息發(fā)送和接受)和具體兩種術(shù)語(yǔ)(傳輸和有線(xiàn)格式)描述服務(wù)的詞匯表。WS-Addressing利用WSDL的“服務(wù)”和“端口”概念,如下所述。
WS-Addressing目前已經(jīng)發(fā)布了三種不同的規范,
WS-Addressing Core、
WS-Addressing SOAP Binding和
WS-Addressing WSDL Binding。核心規范描述抽象屬性,而捆綁文檔解釋了如何分別使用SOAP和WSDL來(lái)表示這些屬性。核心/捆綁文檔分析在Web services規范中很常見(jiàn)。在此,核心規范對應用程序開(kāi)發(fā)人員來(lái)說(shuō)比捆綁文檔更為重要,因為Web services資料庫和開(kāi)發(fā)人員工具通常封裝捆綁文檔的細節。
WS-Addressing的目的 SOAP不提供標準的方法,來(lái)指定消息的目的地、如何返回響應或者在哪里報告錯誤。這些細節以前留在傳輸層中。舉例來(lái)說(shuō),在標準SOAP請求通過(guò)HTTP發(fā)送的時(shí)候,HTTP請求的URI就作為消息的目的地。消息的響應保存在HTTP響應中,客戶(hù)端通過(guò)HTTP連接來(lái)接收。通過(guò)JMS異步發(fā)送SOAP請求消息時(shí),則可以在JMS消息標頭中指定響應的目的地,將其合并在消息主體中,或者保留在服務(wù)實(shí)現中。
在傳輸層上的尋址對很多現有的服務(wù)來(lái)說(shuō)已經(jīng)夠用了,但是在其他服務(wù)的開(kāi)發(fā)中它卻成了一種限制因素。WS-Addressing定義了通過(guò)多種傳輸路由消息或者將響應直接傳遞到第三方的標準方式。舉例來(lái)說(shuō),客戶(hù)端應用程序可以通過(guò)JMS發(fā)送請求,并要求通過(guò)電子郵件或者SMS接收響應。為了支持這些規范,WS-Addressing在SOAP信封中綜合了交付、答復和錯誤處理程序的尋址信息。下面的示例說(shuō)明了使用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還定義了一種標準,用于在一個(gè)地址中包含服務(wù)特定的屬性,該地址可以用于將消息路由到服務(wù)中或者由目的地服務(wù)自身使用。這些屬性對創(chuàng )建有狀態(tài)的Web services特別有用,這些服務(wù)可以從特殊的客戶(hù)端接收一系列的請求,并記住這些請求之間的一些狀態(tài)信息。
核心構造
WS-Addressing為Web services詞匯表引入了兩種新的構造:端點(diǎn)參考和消息尋址屬性。“Endpoint”是一個(gè)用于訪(fǎng)問(wèn)Web services的目的地的確定術(shù)語(yǔ)。端點(diǎn)參考是描述這些目的地的一種新模型。消息尋址屬性(可能會(huì )包含一個(gè)或者多個(gè)端點(diǎn)參考)提供了該目的地信息的上下文。
郵遞信封提供了一種優(yōu)秀的非技術(shù)性類(lèi)比:目的地地址的書(shū)寫(xiě)位置在信封的中央,而回信地址的書(shū)寫(xiě)位置在背面。單個(gè)地址的具體格式(姓名、街道、美國城市/州/郵政編碼)可以與端點(diǎn)參考進(jìn)行類(lèi)比。信封上的地址布局可以與WS-Addressing的消息尋址屬性進(jìn)行類(lèi)比。
分析端點(diǎn)參考
在WS-Addressing schema中,端點(diǎn)參考被定義為一種復雜類(lèi)型。端點(diǎn)參考類(lèi)型包含地址(URI)、參考屬性、參考參數、端口類(lèi)型、服務(wù)名稱(chēng)、策略元素(由WS-Policy規范定義)。端點(diǎn)參考唯一必需的元素是地址,因此可能的最簡(jiǎn)單端點(diǎn)參考就是一個(gè)URI:
<wsa:Address>http://ws.example.com/myservice</wsa:Address>
端點(diǎn)參考的其他元素全部是可選的,這一點(diǎn)可以使您選用所需的元素更加方便。端口類(lèi)型和服務(wù)名稱(chēng)元素非常類(lèi)似于它們的WSDL對等物。WSDL將端口類(lèi)型定義為一種附加到操作的抽象集合中的標識名稱(chēng)。捆綁文檔指定了端口類(lèi)型的具體輸入和輸出。該類(lèi)型的端口表示捆綁文檔在特定地址上的部署。服務(wù)是端口的指定集合。與在WSDL中一樣,在WS-Addressing中,端口類(lèi)型和服務(wù)名稱(chēng)是QNames(合格名稱(chēng))。WS-Addressing端點(diǎn)參考中的端口類(lèi)型和服務(wù)名稱(chēng)必須具備與WSDL的兼容性,而不是完全將其替代。
端點(diǎn)參考的一個(gè)重要方面是通過(guò)參考屬性或者參考參數在自己的XML名稱(chēng)空間中附加數據的能力。這兩種元素都是屬性和值的集合,您可以使用這些屬性和值將元素從自己的XML名稱(chēng)空間(或者任意XML名稱(chēng)空間)綜合到端點(diǎn)參考中。參考屬性和參考參數之間的主要區別不在于格式,而是既定的用途不同。
參考屬性可以用于識別服務(wù)部署的端點(diǎn)。共享同一個(gè)URI,但是指定了不同參考屬性值的兩個(gè)端點(diǎn)參考表示兩種不同的服務(wù)。參考屬性用于將請求發(fā)送到恰當的服務(wù)中。舉例來(lái)說(shuō),您可以部署兩種不同版本的服務(wù),并讓請求在其參考參數中指定目標版本。如果一個(gè)服務(wù)接收到一個(gè)請求并執行該請求,則其行為應當等同于參考屬性中的響應。
對比來(lái)說(shuō),參考參數必須識別特定服務(wù)托管的資源。參考參數向服務(wù)說(shuō)明要處理的資源。他們無(wú)法識別服務(wù)。具有不同參考參數的兩個(gè)端點(diǎn)參考參考相同的服務(wù)。
以下示例說(shuō)明了向大眾提供天氣預報信息服務(wù)的端點(diǎn)參考,同時(shí)還可以向高級用戶(hù)提供更加詳細的信息。服務(wù)的URI在A(yíng)ddress元素中指定。參考屬性指出,請求適用于基礎版本的服務(wù)。參考參數指定需要天氣預報的城市:
<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>
消息尋址屬性
如上所述,端點(diǎn)參考在消息尋址屬性中使用。消息尋址屬性定義了可以附加到SOAP消息中的尋址信息的完整集合。大多數字段是可選的;唯有To和Action兩個(gè)字段是必需的,每個(gè)字段指定一個(gè)URI。在HTTP請求中,它們將是同一個(gè)URI。
在非HTTP請求中,To URI可能不同于A(yíng)ction URI。To URI是請求提交到的位置,而Action URI指出需要采取的操作。Action URI應當表示一種符合WSDL端口類(lèi)型的服務(wù)(參看上文)。舉例來(lái)說(shuō),通過(guò)電子郵件或者SMS發(fā)送的請求可以到達WSDL端口類(lèi)型不表示的目的地中。將To URI和Action URI分開(kāi)為配置Web services目的地提供了很多靈活性。舉例來(lái)說(shuō),電子郵件地址可以接收不同服務(wù)的請求,全部通過(guò)其Action URI值進(jìn)行識別。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端點(diǎn)必須僅在發(fā)送方期望進(jìn)行響應的時(shí)候才能指定,但是它可以將響應路由到任何有效的端點(diǎn)中。FaultTo始終是可選的,它可以將SOAP錯誤消息路由到指定的端點(diǎn)參考中。此外,服務(wù)的消費者可以使用From端點(diǎn)參考元素來(lái)向服務(wù)標識他們自身。明確地區分消息源端點(diǎn)、預期的回復端點(diǎn)和錯誤處理端點(diǎn)可以幫助WS-Addressing支持我們通常與Web services關(guān)聯(lián)的簡(jiǎn)單請求/回復交互之外的多種消息模型。
需要回復時(shí),無(wú)論是發(fā)送方期望該回復還是由第三方端點(diǎn)在ReplyTo標頭中指定,都必須表示MessageId元素。消息的ID是一個(gè)獨特的URI。由于Web services可以通過(guò)不可靠的傳輸使用,因此端點(diǎn)就很可能會(huì )接收到重復的消息復本。消息ID可以用于避免重復處理同一消息。
當服務(wù)接收到使用WS-Addressing尋址的消息時(shí),它還會(huì )在回復消息中包含WS-Addressing標頭。原始消息的消息ID成為了回復地址中的RelatesTo元素。目前,唯一受支持的關(guān)系類(lèi)型是“Reply”。如果客戶(hù)端正在發(fā)送多個(gè)Web services請求和接收異步響應(可能通過(guò)不同的傳輸),那么RelatesTo元素就會(huì )提供一種標準方法,以關(guān)聯(lián)接收到的回復和相應的請求。
用于開(kāi)發(fā)人員的WS-Addressing 使用WS-Addressing的開(kāi)發(fā)人員工具正在推廣過(guò)程中,但是仍沒(méi)有得到廣泛應用。如果您現有的Web services應用程序依靠WebLogic Workshop、Apache Axis或者其他可以生成Java API Web services接口的工具,那么您需要等待這些環(huán)境的擴展才能包括WS-Addressing。因為WS-Addressing是由主要的大型企業(yè)廠(chǎng)商推動(dòng)開(kāi)發(fā)的,新的適用于開(kāi)發(fā)人員的WS-Addressing工具應當會(huì )在2005年推出。
對于使用Web services通過(guò)HTTP直接遠程訪(fǎng)問(wèn)對象的應用程序來(lái)說(shuō),WS-Addressing不是一款解決方案。因為HTTP請求和響應通過(guò)單個(gè)HTTP連接同步發(fā)生,尋址意義不大。BEA的Dave Orchard(WS-Addressing合著(zhù)人員)最近發(fā)表了一篇
blog entry來(lái)探討WS-Addressing和HTTP的可能性。即使對于WS-Addressing的編寫(xiě)人員來(lái)說(shuō),在這一點(diǎn)上通過(guò)HTTP體現出來(lái)的WS-Addressing的價(jià)值也不是顯而易見(jiàn)的。如果Web services僅僅是為HTTP客戶(hù)端提供的,則WS-*規范的“按需使用”本質(zhì)會(huì )更容易地忽略WS-Addressing(直到其變得相關(guān))。
WS-Addressing為通過(guò)異步傳輸使用Web services的開(kāi)發(fā)人員提供了更多優(yōu)勢??缍喾N傳輸使用一致的尋址模式可以簡(jiǎn)化一些集成問(wèn)題和幫助開(kāi)發(fā)人員實(shí)現系統,在該系統中,調度程序使用端點(diǎn)參考將請求路由到幾個(gè)相關(guān)服務(wù)中的一個(gè)中。隨著(zhù)移動(dòng)計算變得日益重要,異步Web services對支持具有有限網(wǎng)絡(luò )訪(fǎng)問(wèn)權限的移動(dòng)客戶(hù)端來(lái)說(shuō)非常有用。尋址的一般模型可以幫助最大程度減少將Web services暴露給多個(gè)異步客戶(hù)端所需的工作。如上所述,我們之中關(guān)注應用程序開(kāi)發(fā)的人需要等待廠(chǎng)商推出適當的工具后才能充分利用這些機遇。
與其他新推出的Web services規范一樣,WS-Addressing的值價(jià)仍然有待在實(shí)踐中驗證。如果它產(chǎn)生了一個(gè)錯誤,那么當然不能說(shuō)明首次推出它的主要廠(chǎng)商不具有繼續支撐它的能力。無(wú)論WS-Addressing會(huì )成為下一個(gè)重要規范,還是曇花一現,本文都希望您深入地了解一下規范的內容和可能需要對它進(jìn)行的一些變更。