 | This articlemay contain excessive or inappropriate references toself-published sources. Please helpimprove it by removing references to unreliablesources where they are used inappropriately.(September 2011) (Learn how and when to remove this message) |
Web Services Resource Framework (WSRF) is a family ofOASIS-published specifications forweb services. Major contributors include the Globus Alliance andIBM.
Aweb service by itself is nominallystateless, i.e., it retains no data between invocations. This limits the things that can be done with web services,
Before WSRF, no standard in theWeb Services family of specifications explicitly defined how to deal with stateful interactions with remote resources. This does not mean that web services could not be stateful. Where required a web service could read from adatabase, or use session state by way of cookies or WS-Session.
WSRF provides a set of operations that web services can use to implement stateful interaction; web service clients communicate withresource services which allow data to be stored and retrieved. When clients talk to the web service they include the identifier of the specific resource that should be used inside the request, encapsulated within theWS-Addressing endpoint reference. This may be a simpleURI address, or it may be complex XML content that helps identify or even fully describe the specific resource in question.
Alongside the notion of an explicit resource reference comes a standardized set of web service operations to get/set resource properties. These can be used to read and perhaps write resource state, in a manner somewhat similar to having member variables of an object alongside its methods. The primary beneficiary of such a model are management tools, which can enumerate and view resources, even if they have no other knowledge of them. This is the basis forWSDM.
WSRF is not without controversy. Most fundamental is architectural: are distributed objects with state and operations the best way to represent remote resources? It is almost a port into XML of thedistributed objects pattern, of whichCORBA andDCOM are examples. A WSRF resource may be a stateful entity to which multiple clients have resource references and the WSRF specification itself does not deal with concerns such as isolation and availability, deferring to the composable nature of web service specifications to deal with these. Many WSRF stacks appear to avoid these concerns by being low-availability, mapping 1:1 from a WSRF resource reference to a local object instance, which in C++ and Java is usually not at all persistent (with the exception of those bound to a database through some persistence mechanism). There are, however, implementations of WSRF that support persistence, clustering and high-availability of resources (for example, inWebSphere Application Server).
With a distributed objects view of the network, WSRF is also at loggerheads with theREST model of the network, in which everything is a resource, but in which all actions are enabled through a limited and standardized set of operations. In some ways, the two models are closer than pureSOAP andREST, because they both have stateful resources at the far end. However, REST, as implemented onHTTP, assumes that theURL is all that is needed to address the resource – there is no need for the complexity of theWS-Addressing ReferenceParameters. The idea of managing the lifetime of remote content through renewable leasing comes in for particular criticism. The other issue with the architecture from the REST community is that callbacks/notifications, as described inWS-Notification, do not go through firewalls. This is why REST designs prefer polling, such as in RSS andAtom (standard) feeds. WSRF has done nothing to make SOAP more acceptable to the REST community.
The introduction of WSRF also caused splits in the WS-* world. It was first announced to the World at aGlobal Grid Forum event in February 2004, as a successor to theOpen Grid Services Infrastructure. Its limited compatibility with the mainstreamWS-I architecture created dissent from the UK grid community.[1] The Global Grid Forum ultimately isolated their dependencies on WSRF in aWSRF profile for theirOpen Grid Services Architecture. WSRF protocols were also used byWSDM as the means to interacts withmanageable resources described in WSDM. The WS-* world, however, was not united on a single standard for Web services management with Microsoft, Sun and others choosing to pursueWS-Management, with its dependency onWS-Transfer as the means to describe manageable resources.
Also of relevance isWS-Notification which says how to push information to other web-services about what is going on.
Implementing the basic property get/set semantics of WSRF resources is relatively simple. The hardest problem is probably returning faults as WSRF Base Faults where the specification requires it, because SOAP stacks themselves prefer to raiseSOAPFault faults. Managing resource lifetimes is harder, but this is optional, as isWS-Notification, which is the hardest to test.