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
桔子汁 阅读(1375)
评论(1) 编辑 收藏 所属分类:
Web Service