WS-Transfer, like WS-RF, models
the projected state explicitly through
an XML document accessible via an
EPR. However, the only operations defined on that state are, as per the CRUD
(create, retrieve, update, and delete) architectural style: create a new resource
state representation by supplying a
new XML document; get an entire resource state representation; put a new
resource state representation to replace an existing one; and delete an existing state representation. Distributed, resource-oriented applications are
then built by using these operations to
exchange state representations.
The WS-Transfer specification was
developed by an industry group led
by Microsoft and has recently been
submitted to the World Wide Web
Consortium (W3C) for standardization. Other specifications, notably WS-Eventing and WS-Management, build
on WS-Transfer. As we will see later,
WS-Transfer and WS-RF differ only in
minor technical details; they arguably
owe their separate existence more to
industry politics than technical considerations. Fortunately, there seems
to be industry support for an integration of the WS-Transfer and WS-RF
approaches, based on a WS-Transfer
HTTP is an application protocol
implementing a resource-oriented approach to building distributed systems.
It has been described as an implementation of the REST architectural style.
Like WS-RF and WS-Transfer, HTTP
implements a resource-oriented approach to building distributed systems.
According to REST, a small set of verbs/
operations with uniform semantics
should be used to build hypermedia
applications, with the Web being an example of such an application. The constraints applied through the semantics
of these operations aim to allow applications to scale (for example, through
caching of state representations). State
representations are identified through
a URI. HTTP defines simple verbs—
such as POST, PUT, GET, DELETE—
and headers to enable the implementation of applications according to REST
principles. XML is just one of the many
media formats that HTTP can handle.
Finally, in the “no conventions for
managing state” approach (“no-con-
table 2: the eight operations considered in our comparison of different approaches.
1 Create new job
2 retrieve state
A client requests the creation of a new job by sending a job creation
request to a job factory service responsible for creating new jobs.
upon success, a job handle is returned that can be used to refer to
the job in subsequent operations.
retrieve all state information associated with a specified job
(e.g., execution status, resource allocation, program name).
determine the execution status (e.g., active, suspended) of
a specified job.
extend the lifetime of a specified job.
request notification of changes in the state of a specified job.
suspend a specified job.
terminate a specified job.
Apply the terminate operation to all jobs that satisfy certain criteria, such
as those belonging to a particular client, those with a particular total
execution time, those with a specific current execution status,
or those with explicitly identified job handles.
ventions” in the following), 6 there are
no such concepts as operations, interfaces, classes, state, clients, or servers.
Instead, applications are built through
the exchange of one-way messages between services. Semantics to the message exchanges (for example, whether
a message can be cached or whether a
transactional context is included) are
added through composable protocols.
State representations are not fundamental building blocks. Instead, resources should be identified through
URIs (or URNs) inside the messages,
leaving it up to the application domain-specific protocols to deal with state
management. Although any asynchronous messaging technologies could be
used in implementations following this
style, we consider here an implementation based on Web services protocols,
however, without the introduction of
We use a simple example to provide
a more concrete comparison of these
four approaches. The example is a job
management system that allows clients
both to request the creation of computational tasks (“jobs”) and to monitor
and control previously created jobs. It
provides the eight operations listed in
Table 2, which we choose to represent
as a range of typical state manipulation
operations. In each case, a client makes
the request by sending an appropriate
message to the job management system and then expects a response indi-
cating success or failure.
Operation 1 creates a new job and
returns a handle that can be used to
refer to the job in subsequent operations. Parameters specify such things
as required resources, an initial lifetime for the job, and the program to be
Operations 2–7 support some archetypal job monitoring and control functions on a single job.
Operation 8 is an example of an interaction that may relate to multiple
jobs. The set of jobs to which the operation is to be applied might be specified
either in terms of job characteristics or
by supplying a set of job handles.
In the discussion that follows, we
show how our four approaches can be
used to build a service that supports
these eight tasks. As we shall see, each
approach not only has in common that
the “job factory service” is a network
endpoint to which job creation and
certain other requests should be directed, but also is distinguished from
the other approaches in terms of:
˲ Its syntax (that is, how the job handle should be represented and how operations on the job should be expressed
˲ Its use (or not) of conventions
defined in existing specifications for the
purpose of defining its syntax.
The distinction made here between
syntax and conventions may appear
unimportant, but we emphasize it so