table 6: syntax used in job handle approach, showing for each operation
of table 2 the request message, destination address, and return message.
# message
1 “new job” carrying the job
specification
to
job-management-service
Returns on success
identifier for the newly
created job
2 “state” carrying job
identifier(s)
3 “status” carrying job
identifier(s)
4 “new lifetime” carrying
job identifier(s) and new
lifetime(s)
5 “subscription” carrying job any job service aware of the Acknowledgment*
identifier(s) and subscription job identifier(s)
information (for each)
6 “suspension” carrying job any job service aware of the Acknowledgment*
identifier(s) job identifier(s)
7 “destroy request” carrying job any job service aware of the Acknowledgment*
identifiers(s) job identifier(s)
8 “destroy request” carrying any job service aware of the Acknowledgment*
job identifier(s) and query job identifier(s)
expression
* May also silently accept the message and report on fault only. If proof of delivery is necessary,
WS-ReliableMessaging can be used.
any job service aware of the
job identifier(s)
any job service aware of the
job identifier(s)
any job service aware of the
job identifier(s)
Xml document with
job state(s)
Xml document with
job status(s)
Acknowledgment*
alphabet and specification soup
Any discussion of Web services inevitably involves a plethora of acronyms and specification
names. We list some of them here. to save space, we do not provide citations for individual
specifications. these can easily be located online.
ePR (endpoint reference)
soaP
WsDl (Web services
description language)
Ws-eventing
WsDm (Web services
distributed management)
Ws-Resourcetransfer
Ws-Rf (Web services
resource Framework)
Ws-transfer
As defined in the Ws-Addressing specification, a combination
of Web services (Ws) elements that define the address for
a resource in a soAp header.
A protocol for exchanging Xml-based messages over
networks, normally using http.
An Xml-based language that provides a model
for describing Web services.
A specification that defines a protocol for Web services to
subscribe to another Web service or to accept a subscription
from another Web service.
An oAsis-developed Web services architecture and set
of specifications for managing distributed resources.
A proposed integration of Ws-rF and Ws-transfer.
An oAsis-developed architecture and set of specifications
for describing and accessing state in a Web service.
A specification that defines a protocol for the transfer of
an Xml representation of a Ws-addressable resource, as well
as for creating and deleting such resources.
case of our job management service,
these proponents might observe the
following:
˲The creation and subsequent
management of a job can naturally
be viewed as an instance of some general patterns (creation, access, subscription, lifetime management, and
destruction of state associated with a
job); and
˲ The encoding of the job-manage-ment interface in terms of those patterns simplifies both the design of the
interface (as much of it is already provided in other specifications) and the
explanation of that interface to others.
They may also point out that programmer productivity is enhanced by
client tools and applications that are
“WS-RF and/or WS-Transfer aware.”
For example, a registry or monitoring
system can use WS-RF operations to access service state without any application-specific knowledge of that state’s
structure. 2
In contrast, proponents of the no-conventions approach argue that the
design of any particular interface (for
example, one for job management) will
typically be relatively simple, involve issues that are not captured by these conventional patterns, and not require all
features included in the specifications
that encode that pattern. Thus, one can
achieve a simpler design by proceeding
from first principles. For example, in
the case of our job management service, while WS-RF and WS-Transfer
provide us with a Destroy operation
“for free,” we still need to introduce a
separate Suspend operation. Furthermore, the semantics of Destroy may be
quite application specific. For example,
a service implementer may decide to
retain information about “destroyed”
jobs (by changing their status to “
destroyed”) so that information about
them can still be retrieved. In this case,
the state would not be destroyed. Finally, WS-RF and WS-Transfer focus on interaction with single states (for example, DestroyMultiple had to be custom
defined) and so may not provide useful
conventions in cases where operating
on multiple states is the common case;
for example, all Amazon REST and Web
services can consume multiple ASINs.
Ideally, we would like to evaluate
the relative merits of these two positions in terms of concrete metrics
such as code size. Such an evaluation,
however, requires agreement on the requirements that the interfaces should
support. Unfortunately, proponents of
the different approaches tend to differ also in their views of requirements.
For example, a proponent of common
patterns might see the ability to use
WS-ResourceLifetime operations for
soft-state lifetime management as de-
