WSRF: Accessing stateful resources with Web services

Tech Ads

Back to Article List

Originally published December 2005 [ Publisher Link ]

WSRF: Accessing stateful resources with Web services

If there is mantra to developing applications on the Web it's that of being a stateless medium, something that is due to the inherent design behind its base protocol: HTTP. However, conventional wisdom has shown that most interactions between client and server require maintaining some form of state in order to execute appropriately, WSRF is a specification designed to deal with stateful resources in the context of Web services.

WSRF, or Web Services Resource Framework, establishes the means by which to expose persistent resources. A resource from the vantage point of WSRF can be interpreted as any device or application component that has an extended lifecycle -- not just a simple request/response -- which has to be addressed via Web services.

Generally, the classical mechanism for dealing with stateful data is done in the application itself. In essence, the management and state of information for the application requester is hidden from the provider and visa versa.

While this approach is workable under most scenarios, the needs brought about by elaborate Web services designs in which a requester or provider might require a complete snapshot regarding the state of a resource is often a limitation, an aspect which is tackled by WSRF.

WSRF being a framework, is composed by a series of pieces that deal with its finer details, which are:

WS Resource: Defines how web services can be used to represent multiple resource instances.
WS-ResourceProperties (WSRF-RP): Specifies the actual means for interacting with the properties declared in a WS-Resource.
WS-ResourceLifetime (WSRF-RL): Defines how to monitor and destroy the lifecycle of a WS-Resource.
WS-ServiceGroup (WSRF-SG): Specifies how to aggregate WS-Resources.
WS-BaseFaults (WSRF-BF): Defines a format for SOAP faults thrown by WSRF services.

Semantics aside, most implementation support for WSRF includes provisions for all of the aforementioned subgroups. Having covered this basic background, it's time to elaborate on what it actually means to have Web services enabled with WSRF.

A Web service contract in the form of WSDL can become extremely verbose -- not to mention complex -- when brokering requests between resources that can change their state based on user and consumer input. A typical scenario could be that of a tracking system or shopping cart.

Every interaction or round trip requires that each contract exchange be modified to include such state changes in a piecemeal fashion, but with WSRF this approach changes.

WSRF defines a Resource Property Document -- the backbone to WSRF -- which is actually an XML document completely separate from the service description provided in a WSDL contract. The only relation this document has to the WSDL descriptor is a pointer in the form of an Endpoint Reference as defined by WS-Addressing.

This process allows Web services to shed themselves directly from data that changes state and effectively encapsulate resources in a separate form instead of overwhelming a WSDL descriptor and constantly transferring such information over the wire on each call.

The following listing illustrates the payload that would be sent by a client to a web service provider using WSRF.

Listing 1.1 Request to Web Service enabled with WSRF

<Envelope 
    xmlns="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ts="http://tracking-system.org/resource/package">

 <Header 
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
   <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 
   xmlns:wsrp="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-01.xsd"
   xmlns:ts="http://tracking-system.org/resource/package">
    <wsrp:ResourceProperty>
      ts:ScannedPortsOfEntry
    </wsrp:ResourceProperty>

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

</Envelope>

Notice how the SOAP header includes the WS-Addressing instructions related to WSRF, and the actual body contains a request for multiple WS-Resource Properties. The next listing shows the successful payload that would be sent by the provider.

Listing 1.2 Response from Web Service enabled with WSRF

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope 
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Header>
 <wsa:Action 
   soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" 
   soapenv:mustUnderstand="0" 
   xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    http://schemas.xmlsoap.org/ws/2004/03/addressing/anonymous
 </wsa:Action>
 <wsa:To 
   soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" 
   soapenv:mustUnderstand="0" 
   xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
   http://schemas.xmlsoap.org/ws/2004/03/addressing/anonymous
 </wsa:To>

 </soapenv:Header>
 <soapenv:Body>
  <wsrf:GetMultipleResourcePropertiesResponse 
      xmlns:wsrf="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-01.xsd">
   <fil:ScannedPortsOfEntry 
      xmlns:fil="http://tracking-system.org/resource/package">
     /hub
   </fil:ScannedPortsOfEntry>
   <fil:Type 
      xmlns:fil="http://tracking-system.org/resource/package">
      vxts
   </fil:Type>

  </wsrf:GetMultipleResourcePropertiesResponse>
 </soapenv:Body>
</soapenv:Envelope>

The response contains a series of elements related to WS-Addressing, including the corresponding reference to the stateful component administered by the provider.

This last exchange only reflects a basic operation behind WSRF. Other scenarios could include the management of errors or monitoring and destruction of resources, all of which have their corresponding syntax.

From a development point of view, using WSRF requires that your Web services applications have access to an implementation designed around this model. If you are using the Java language, Apache WSRF provides you with an out-of-box WSRF implementation that you can freely use for evaluating the capabilities behind this Web services spec.

While the medium in which Web services are deployed is constrained to operate in a stateless fashion, WSRF offers a standard and scalable approach to dealing with these shortcomings of sharing information state across client and server.