be easier to use when applying a particular set of principles. For example, pure HTTP is particularly well suited for implementing distributed applications according to REST principles, while Web services technologies such as SOAP are better suited for interface-driven applications. There is no reason, however, why one could not build a RES T-oriented application using Web services technologies or a distributed object-based application using HTTP— although we doubt anyone would want to go through such an exercise.

 

four approaches to modeling state Table 1 summarizes the key properties of the four approaches presented here. The following provides a brief description of each approach.

The Web Services Resource Frame-

work (WS-RF) defines conventions on how state is modeled and managed using Web services technologies. WS-RF implements an architectural style similar to that of distributed objects or resources. Projected state is explicitly modeled as an XML document (the state representation) and is address-able via a WS-Addressing endpoint reference (EPR), a conventional representation of the information that a client needs to access a network service.

As in traditional object-based systems, any number of operations can be defined that access, or result in the change of, the projected state. The WS-RF specifications, however, define a set of common operations for the following: accessing that projected state (the XML document) in its entirety or in part; requesting notification of changes

on it (using WS-Notification); updating it in its entirety or in part; and deleting it. The structure of the XML document (that is, the schema), together with all the operations that can be applied to the projected state, known as the resource, are included in the Web Services Description Language (WSDL) document associated with the state’s EPR, thus allowing clients to discover, using standard operations, what state a particular service makes available.

The WS-RF and WS-Notification specifications were developed within the OASIS standards organization. They are implemented within various open source and proprietary systems. Other specifications, notably WS-Notification and Web Services Distributed Management (WSDM), build on WS-RF.

table 1: Key characteristics of the four approaches. in each box, we list conventional encodings of a function in terms of operation name(s) and (in brackets) the defining specification. the absence of an entry simply means that no conventional encoding has been defined; a custom, application-specific encoding can still be provided.

state representation schema

address state representation

create new state

access entire state

Get part of state

update entire state

update, or add, part of state

Request notification

lease-based lifetime management

Destroy state

fault modeling

RPc-based

open standards process

Ws-Rf

Wsdl extensions

epr (Ws-Addressing)

Getresourcepropertydocument (Ws-resourceproperties)

Getresourceproperty, Getmultipleresourceproperties, Queryresourceproperties (Ws-resourceproperties)

setresourceproperties (Ws-resourceproperties)

setresourceproperties, insertresourceproperties, updateresourceproperties, deleteresourceproperties (Ws-resourceproperties)

subscribe (Ws-notification)

setterminationtime (Ws-resourcelifetime)

destroy (Ws-resourcelifetime)

Well-defined error codes ( Ws-baseFaults + other specs)

Yes

Yes (oAsis)

Ws-transfer

epr (Ws- Addressing)

Create (Ws-transfer)

Get (Ws-transfer)

put (Ws-transfer)

subscribe (Ws-eventing)

delete (Ws-transfer)

soAp faults

Yes

Yes (W3C)

httP

uri

http post

http Get

not defined unless part of a state representation is exposed through a different uri (no semantics about the relationship are defined)

http put

http delete

http fault codes

no

Already a standard

no conventions

urn

subscribe (Ws-eventing)

soAp faults

no

no need for new standards