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. ²

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-