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