2002-2003年提出的OGSI的概念是開放網格體系結構 (OGSA : Open Grid Service Architecture[34]) 的基本組件，它是一項基于新興的Web service標準的網格軟件基礎結構標準化工作，用于為 OGSA 軟件組件提供最大的互操作性。其根本的出發點是通過將關鍵的網格技術與Web Services技術集成起來，形成一個分布式系統框架，通過一種Grid service來實現兩者的結合。
為了更好的將Grid service的設想與現有的Web Services技術體系結構融合起來，有必要對OGSI協議做必要的改進。WSRF就是針對這一目標而給出的對OGSI的重構和發展。根據OGSI的幾點不足，把OGSI分成幾個相互獨立的協議，同時使用一些新的Web服務協議來對OGSI的功能進行分解和擴充，它的出現就是為了取代OGSI而成為OGSA的重要組成部分。
WSRF是對OGSI的重構和擴展，它目標在于使用新的Web服務標準，特別是WS-Addressing，同時基于早期的實現和應用經驗擴展OGSI。
WSRF框架包含以下5個協議：
l WS-Resource協議：解釋WS-Resources的總體概念，并展示后續文檔中的所有概念如何成為一體。
l WS-ResourceProperties協議：解釋如何定義和操縱 WS-Resource。
l WS-ResourceLifetime協議：解釋如何銷毀 WS-Resource。
l WS-BaseFault協議：定義任何WSRF應用程序都必須實現的基本故障消息，以及如何擴展它以創建新的故障。
l WS-ServiceGroup協議：解釋如何創建 WS-Resources 的邏輯組，以及如何控制和操縱這些組。
另外與WSRF密切相關的WS-Notification系列協議使得我們可以在Web服務的無狀態環境中模擬事件驅動的應用程序。WSN協議族包含以下三個協議：
l WS-BaseNotification協議：定義了基本通知機制的角色、接口及消息交換格式。
l WS-BrokeredNotification協議：定義了代理通知機制的角色、接口及消息交換格式。
l WS-Topics協議：定義了通知主題名字空間，主題，主題表達式結構以及主題表達式查詢語言。
WS-Resource 是一個有狀態資源（比如數據庫或硬盤）和它與之交互的 Web 服務的組合。有狀態資源是一些即使您不與之交互也存在的東西。例如數據庫，即使在您不查詢它的時候，它也存在。此外，狀態概念也包含屬性的思想。當要求您把所借的東西以原狀態返還時，涉及某些屬性的值，比如清潔度、修理要求、油罐中的汽油量，等等。有狀態資源與此類似，具有定義其狀態的屬性，并且這些屬性就是我們將與資源交互的方式，如WS-Resource 的屬性中所示。
那么有狀態資源（比如數據庫或硬盤）和Web 服務的組合的真正含義是什么呢？讓我們從實際的角度來看這個問題。假設我們有一個系統，涉及到管理一組人造衛星。每個人造衛星是一個有狀態資源，因為即使在我們不與之對話時它也存在。我們還有一個 Web 服務，它提供人造衛星功能，比如更改反向、檢索信息，或者甚至調整姿勢。
通過將者二者組合起來，我們創建了一個 WS-Resource。注意，并不需要一對一的對應關系。例如，這個Web服務可以與幾個不同的人造衛星交互，從而創建幾個引用相同服務的不同WS-Resources。另一方面，一個人造衛星可以與幾個不同的服務（比如控制宇宙實驗的服務和發射激光束的服務）交互，從而創建幾個引用相同有狀態資源的不同 WS-Resources。
那么我們如何在應用程序中表示這個有狀態資源呢？答案就在它的ResouceProperties中。正如有狀態資源中提到的，對象的狀態可以由它的各種屬性的值來決定。因為我們真正感興趣的就是對象的狀態，所以我們可以把有狀態資源表示為一個展示其屬性的 XML 文檔。該文檔叫做資源屬性文檔。
在我們的人造衛星例子中，它可能是具有以下代碼行的文檔：
<satProp:GenericSatelliteProperties xmlns:satProp="http://example.com/satellite">
<satProp:latitude>30.3</satProp:latitude>
<satProp:longitude>223.2</satProp:latitude>
<satProp:altitude>47700</satProp:altitude>
<satProp:pitch>49</satProp:pitch>
<satProp:yaw>0</satProp:yaw>
<satProp:roll>32</satProp:roll>
<satProp:focalLength>21999992</satProp:focalLength>
<satProp:currentView>
http://example.com/satellite/2239992333.zip
</satProp:currentView>
</satProp:GenericSatelliteProperties>
狀態的更改需要一個或多個這些屬性的更改，反之亦然。
就像可以通過添加成員或方法來擴展類一樣，我么可以通過添加屬性來擴展 WS-Resource。例如，考慮這樣一種情形，我們具有一個人造衛星，它也充當恒星計數器。除了有狀態資源的一般屬性之外，我們可能還有一個 currentCount 屬性：
<satProp:GenericSatelliteProperties
xmlns:satProp="http://example.com/satellite"
xmlns:counterProp="http://example.com/satellite/CounterSatelliteProperties">
<satProp:latitude>30.3</satProp:latitude>
<satProp:longitude>223.2</satProp:latitude>
<satProp:altitude>47700</satProp:altitude>
<satProp:pitch>49</satProp:pitch>
<satProp:yaw>0</satProp:yaw>
<satProp:roll>32</satProp:roll>
<satProp:focalLength>21999992</satProp:focalLength>
<satProp:currentView>
http://example.com/satellite/2239992333.zip
</satProp:currentView>
<counterProp:currentCount>92828</counterProp:currentCount>
</satProp:GenericSatelliteProperties>
注意新信息是在一個獨立的名稱空間中。
至此，我們已經創建了有狀態資源（人造衛星）的表示，但是要真正地創建 WS-Resource，我們還必須使用 WSDL 文件將它綁定到服務。
首先，我們將實際的有狀態資源添加到文件，并將之與 Web 服務關聯：
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="Satellite"
targetNamespace="http://example.com/satellite"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://example.com/satellite"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsrp="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-01.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<wsdl:import namespace="http://docs.oasis-open.org/wsrf/2004/06/wsrf-
WS-ResourceProperties-1.2-draft-01.wsdl"
location="WS-ResourceProperties.wsdl" />
<types>
<xsd:schema targetNamespace="http://example.com/satellite"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace= "http://schemas.xmlsoap.org/ws/2004/03/addressing"
schemaLocation="WS-Addressing.xsd" />
<xsd:element name="latitude" type="xsd:float" />
<xsd:element name="longitude" type="xsd:float" />
<xsd:element name="altitude" type="xsd:float" />
<xsd:element name="pitch" type="xsd:float" />
<xsd:element name="yaw" type="xsd:float" />
<xsd:element name="roll" type="xsd:float" />
<xsd:element name="focalLength" type="xsd:float" />
<xsd:element name="currentView" type="xsd:string" />
<xsd:element name="GenericSatelliteProperties">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="latitude" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="longitude" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="altitude" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="pitch" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="yaw" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="roll" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="focalLength" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="currentView" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>
<portType name="SatellitePortType"
wsrp:ResourceProperties="tns:GenericSatelliteProperties">
</portType>
<binding name="SatelliteSoapBinding" type="tns:SatellitePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
</binding>
<service name="SatelliteService">
<port name="SatellitePort" binding="tns:SatelliteSoapBinding">
<soap:address location="http://example.com/satellite"/>
</port>
</service>
</definitions>
我們首先是添加 Web 服務的基礎、實際的 service 元素和將之與 portType 關聯的 binding。portType 本身還沒有任何操作，但是重要的部分是 wsrp:ResourceProperties 屬性。該屬性指定，Web 服務執行的任何操作都是在一個特定類型的有狀態資源上執行的，如 GenericSatelliteProperties 元素所定義的。GenericSatelliteProperties 元素定義在 schema 中。該有狀態資源和該 Web 服務的組合就是WS-Resource。
注意，協議中指出，在創建資源屬性文檔（比如本例中的 GenericSatelliteProperties）時，必須使用這里展示的樣式，即初始元素是定義和引用的，而不是內聯地定義的。
為了使得有狀態的資源可以被Web服務的客戶端引用，從而引入了隱含資源模式，用來描述一個Web服務和一個或多個有狀態的資源之間的關系。
術語“隱含”的使用是因為與一個給定的消息交換相關聯的有狀態的資源被當作是執行請求消息的隱含上下文。通過隱含，我們說請求者不需要把資源的標示在請求消息體內當作顯式的參數來提供。取而代之，用來指定隱含的有狀態資源的上下文被封裝在WS-Addresin端點引用里，這個引用可以用來尋找目的Web服務的地址。
術語“模式”的使用是為了指明：Web服務和有狀態資源的之間的關系已經被編成“法典”。這是通過一些現存的Web服務技術完成的，比如XML、WSDL、WS-Addressing等。
也有其他的模式可以訪問有狀態的資源。比如，一個Web服務能夠保持資源的標識符當作一個靜態的服務狀態，因此避免了在端點引用里傳遞資源標識符。然而不建議使用這種模式，因為它意味著Web服務和有狀態資源的一個一對一的映射(就是說這個Web服務和幾個有狀態資源綁定了。別人用這個Web服務時，同時就會用到這幾個資源)。取而代之，我們在WS-Resource和它的相應的Web服務之間保持一定的距離，為了把Web服務和有狀態資源嚴格分開，于是就允許Web服務端點和有狀態資源的一個一對多的映射。
以前，很容易指定 Web 服務的地址。所有真正需要的就是 URL，所有其他信息都包含在 SoapAction頭部或消息本身中。現在，Web服務應用程序變得越來越復雜，并不總是那么簡單。倘若想要讓應答發送到除最初的請求者之外的其他地方，或者需要其他信息（比如會話標識符）來定義實際的“位置”，那該怎么辦？或者只是需要附加到 Web 服務的一個特定實例，那該怎么辦？我們在 WS-Resources 的情況中將會遇到這個問題，所以我們需要一種處理它的方式。
WS-Addressing提供一種方式來指定關于位置的信息，而不只是一個統一資源標識符（Universal Resource Identifier，URI）或 URL。
實際上，在我們的例子中，它提供一種標準的方式，將大量的信息添加到 SOAP 消息。我們來構造一個 SOAP 消息，比如：
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/02/addressing"
xmlns:sat="http://example.org/satelliteSystem">
<SOAP-ENV:Header>
<wsa:To SOAP-ENV:mustUnderstand="1">http://example.com/satellite</wsa:To>
<wsa:Action>http://example.com/SetAltitude</wsa:Action>
<sat:SatelliteId>SAT9928</sat:SatelliteId>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<SetAltitudeRequest xmlns="http://example.com/satellite.xsd">
<altitude>47700</altitude>
</SetAltitudeRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
在實際的SOAP消息中具有該信息似乎并不重要，但是請記住，消息可能會傳輸通過多個系統，甚至需要多次傳輸才能到達最終目的地。
要指定該信息，我們需要創建一個 EndpointReference。EndpointReference 是一種方式，用于指定讓消息到達適當的位置并帶有適當的相關信息。
WS-Addressing標準化了端點引用結構，后者用來描繪配置在給定網絡端點的一個Web服務的地址。除了Web服務的端點地址以外，一個端點引用可能還包括：其他的與Web服務相關的元數據，比如服務描述信息和引用屬性，這些可以幫助更深的限制Web服務地址的使用。端點引用里的引用屬性在隱含資源模式里扮演很重要的角色。
一個服從隱含資源模式的端點引用可能包含引用屬性子元素，用來標示使用這個端點引用完成的所有消息交換的執行時所要用到的有狀態的資源。這類端點引用稱為具有WS-Resource資格的端點引用。被一個具有WS-Resource資格的端點引用指定的一個指向Web服務的請求消息，必須包含這個端點引用的引用屬性信息。
因此，WSRF使用具有WS-Resource資格的端點引用來扮演一個指向WS-Resource的網絡范圍內指針。具有WS-Resource資格的端點引用可能被當作成為一個結果返回，比如：一個Web服務消息請求一個工廠創建一個新的WS-Resource，或者作為一些特定應用的Web服務請求的結果。
端點引用包含兩個重要的組成：(1)wsa:Address：指出了Web服務的地址，比如是一個URL，它和該Web服務的WSDL描述的端口元素里的地址是一樣的；(2) wsa:ReferenceProperties：包含WS-Resource的標示，WS-Resource標示表現了在消息交換執行時所要用到的WS-Resource。在端點引用里用來保存這些WS-Resource標示的引用屬性稱為WS-Resource上下文。一個端點引用包含了WS-Resource上下文，那么它就是一個具有WS-Resource資格的端點引用。
表現的WS-Resource上下文信息對服務請求者來說是透明的。服務請求應用軟件不會檢測或者嘗試解釋上下文的內容。WS-Resource上下文僅僅對Web服務有意義，根據這個上下文，Web服務通過一個特殊的實現方法去識別在消息交換時需要用到的WS-Resource。
從服務請求者的角度來看，端點引用代表了一個指向Web服務的指針，而這個Web服務被進一步限制在端點引用的WS-Resource上下文里執行它的消息交換。
例如，我們在前一屏中指定的消息的 EndpointReference 應該是：
<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/02/addressing"
xmlns:sat="http://example.org/satelliteSystem">
<wsa:Address>http://example.com/satellite</wsa:Address>
<wsa:ReferenceProperties>
<sat:SatelliteId>SAT9928</sat:SatelliteId>
</wsa:ReferenceProperties>
</wsa:EndpointReference>
理解 EndpointReference和SOAP消息之間的關系很重要，因為 EndpointReference 就是我們指定特定 WS-Resource 的位置的方式。例如，當我們請求創建新的WS-Resource時，響應將包含一個指向它的EndpointReference。
WS-Resource協議解釋了WS-Resources 的總體概念，在WS-Resource協議中對資源的定義如下：
一個資源是一個具有如下特征的邏輯實體：
l 它必須是可鑒別的
l 它必須擁有零個或多個屬性，以XML形式來表示
l 它可以具有生命周期
對WS-Resource的定義如下：
一個WS-Resource是一個資源和一個Web服務的組合，通過Web服務資源可以被訪問。WS-Resource可以進一步定義如下：
l 通過一個Endpoint Reference來表示對一個WS-Resource的引用，或者正好是一個XML元素，其類型是（或派生自）EndpointReferenceType。這樣的EPRs必須正好是對一個WS-Resource的引用。
l 資源屬性的集合必須通過XML schema 中所描述的XML infoset 來表示。WS-Resource 必須支持通過在WS-Resource Properties協議中定義的消息交換形式來對資源進行訪問。
l 一個WS-Resource可能支持在WS-Resource Lifetime協議中定義的消息交換類型。
對于一個給定的WS-Resource可能會有多個引用，判斷兩個引用是否等同的方法是實現協議，在本協議中沒有定義。
另外在WS-Resource協議還定義了兩個錯誤：
A WS-Resource may respond to any message with the following fault message:
l wsrf-rw:ResourceUnknownFault
The resource identified in the message is not known to the Web service. The fault may contain additional resource- or application-specific information in it.
l wsrf-rw:ResourceUnavailableFault
The resource identified in the message is unavailable. This fault SHOULD indicate a transient condition. A requester might respond to this fault by resending the message.
此錯誤應該是指示了一個短暫的狀態。一個請求者對于此錯誤的響應應該是重新發送消息。
Author: orangelizq
email: orangelizq@163.com
posted on 2009-07-19 15:40
桔子汁 閱讀(1398)
評論(1) 編輯 收藏 所屬分類:
Web Service