通过Web services访问有态资源

日期： 2008-07-31 作者：Daniel Rubio 来源：TechTarget中国 英文

如果对开发的基于Web的应用称颂它是一个无状态的媒介，是一个归结于在它的基本协议HTTP的固有设计。然而，长期的研究表示多数在客户和服务器之间的互作用要求维护状态来正确的执行。WSRF是一个在Web环境中设计处理有状态资源的一个规范。 　　WSRF，或者称为Web服务资源框架，提出了提供持久数据的方式。

一个从WSRF观点来看的资源可以被理解为任何的具有扩展的生命周期的设备或者应用程序模块，而不只是一个简单的请求或者响应。这种设备或者应用程序模块是通过Web services来提供的。 　　通常的，处理有状态数据的经典的做法就是在应用程序中让程序自己来处理有态数据。在本质上，应用程序请求方的信息……

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

如果对开发的基于Web的应用称颂它是一个无状态的媒介，是一个归结于在它的基本协议HTTP的固有设计。然而，长期的研究表示多数在客户和服务器之间的互作用要求维护状态来正确的执行。WSRF是一个在Web环境中设计处理有状态资源的一个规范。

　　WSRF，或者称为Web服务资源框架，提出了提供持久数据的方式。一个从WSRF观点来看的资源可以被理解为任何的具有扩展的生命周期的设备或者应用程序模块，而不只是一个简单的请求或者响应。这种设备或者应用程序模块是通过Web services来提供的。

　　通常的，处理有状态数据的经典的做法就是在应用程序中让程序自己来处理有态数据。在本质上，应用程序请求方的信息的管理和状态是被提供者和visa versa隐藏起来的。

　　在大多数情况下这种方法都是可以奏效的，但当在一个请求者或者提供者要求一个对于资源状态的完全快照时，精确描述的Web services设计的局限提出了新的要求，而WSRF正是为了应对这个方面的问题而提出的。

　　WSRF作为一个框架，是由一系列的处理细节的模块组成的。他们是:

　　·WS资源:定义了Web services如何能够被用来表示多资源实例。
　　·WS-资源属性(WSRF-RP):指定了同WS资源资源中定义的属性进行交互的实际方式。
　　·WS-资源生命周期(WSRF-RL):定义了如何来管理和销毁WS-资源的生命周期。
　　·WS-服务组(WSRF-SG):指定了如何来聚合WS-资源。
　　·WS-基本错误(WSRF-BF):定义了被WSRF服务抛出的SOAP格式的错误。

　　不考虑语义，大多数的实现都支持包括前面所说到的所有的子群的WSRF.已经介绍了所有的相关背景，是时候来详细说明这对于使用WSRF来提高Web services究竟意味着什么了。

　　一个以WSDL形式表述的Web service合约可能变得非常冗长的——更不用提复杂——特别是在那些能够更具用户和消费者的输入来改变状态的资源之间代理请求的时候。一个典型的情况就是一个跟踪系统或者购物车。

　　每个交互或者往返操作要求每个交换的合约要修改成包括类似的分块形式的状态改变。但是对于WSRF，这个途径就改变了。

　　WSRF定义了一个资源属性文本(Resource Property Document)——WSRF的骨干——实际上是一个XML文档，它完全的区分开了在一个WSDL合约中提供的服务描述。

　　这个过程允许Web服务能够把他们自己同改变状态的数据直接脱离开来，以一个单独的形式来有效的封装资源，而不是用扑面而来的WSDL描述符合总是通过线路为每一个调用不断的传输类似的信息。

　　一下的列表解释了一个被客户使用WSRF发送到一个Web服务提供者的payload。

　　列表一 1.1对WSRF使能的Web Service的请求

　　<Envelope
          >
　　
　　   <Header >
　　      <wsa:To 　　mustUnderstand="1">http://dataprovider.com/wsrf/services/packagesystem</wsa:To>
　　      <wsa:Action mustUnderstand="1">http://tracking-　　system.org/resource/package/PackagesystemPortType/WsdlRequestName</wsa:Action>
　　      <ts:ResourceIdentifier mustUnderstand="1">/standard/express</ts:ResourceIdentifier>
　　   </Header>

　　   <Body>
　　     <wsrp:GetMultipleResourceProperties
　　         
　　          >
        　　<wsrp:ResourceProperty>ts:ScannedPortsOfEntry</wsrp:ResourceProperty>
　　        <wsrp:ResourceProperty>ts:Type</wsrp:ResourceProperty>
　　     </wsrp:GetMultipleResourceProperties>
　　    </Body>

　　</Envelope>

　　你应该注意到SOAP头包括WS-Addressing说明是如何同WSRF发生联系的，并且实际的体里面包含了一个对多WS-资源的属性的请求。下一个列表显示的是提供者发送的一个成功payload。

　　通知怎么肥皂头球包括W演讲指示与WSRF有关, 和实际 身体包含一要求多W资源物产。下倾听显示由这个提供者送的成功的收费载重量。

　　列表1.2从对WSRF使能的Web Service的响应

　　<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
　　         
　　         
　　          >
　　 <soapenv:Header>
　　  <wsa:Action
　　       soapenv_actor="http://schemas.xmlsoap.org/soap/actor/next"
　　       soapenv_mustUnderstand="0"
       　　>http://schema　　s.xmlsoap.org/ws/2004/03/addressing/anonymous</wsa:Action>
　　       <wsa:To soapenv_actor="http://schemas.xmlsoap.org/soap/actor/next" 　　soapenv:mustUnderstand="0"
       　　>http://schema　　s.xmlsoap.org/ws/2004/03/addressing/anonymous</wsa:To>
　　 </soapenv:Header>
　　 <soapenv:Body>
　　  <wsrf:GetMultipleResourcePropertiesResponse
　　      >
　　   <fil:ScannedPortsOfEntry >/hub</fil:ScannedPortsOfEntry>
　　   <fil:Type >vxts</fil:Type>
　　  </wsrf:GetMultipleResourcePropertiesResponse>
　　 </soapenv:Body>
　　</soapenv:Envelope>

　　这个响应包括了一系列的核WS-Addressing相关的元素，包括相应的对由提供者管理的有态构建的引用。

　　最后的一个交换只是反映了WSRF之后的一个基本操作。其他的情况可以包括错误的管理或者对资源的监控和毁灭，每一个都有他们对应的语法格式。

　　从一个发展的角度来看，使用WSRF要求你的Web services应用程序能够访问一个使用这种模型设计的实现程序。如果你正在使用Java语言，Apache WSRF为你提供了一个out-of-box WSRF实现，使得你可以自由的来评测这个Web服务规范背后的能力。

　　当Web services被部署的方法被强制的以一种无状态的方式来操作时，WSRF提供了一个种标准的和可扩展的途径来解决这些在客户和服务器之间共享资源状态的不足之处。

作者

Daniel Rubio
Daniel Rubio

相关推荐

  • SAP收购CallidusCloud 与Salesforce竞争

    一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]

  • 云计算究竟是否威胁到了硬件业？

    虚拟化和云计算是目前存储、服务器和网络行业的关键的方面。许多企业正在提供虚拟化的环境或者鼓励人们采用云计算以便 […]

  • API设计如龙生九子 各不相同

    IT咨询管理公司CA Technologies对API产业做了个问卷调查，问卷内容涉及API设计风格以及管理部署的新动向。调查结果表明，JSON与XML可谓两分天下。

  • 从头开始实现领域驱动设计

    领域描述业务；它是驱动企业的概念和逻辑的集合。如果遵循领域驱动设计（DDD）这一本质，那么领域就是应用程序中最重要的组成部分。