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 substrate—the WS-ResourceTransfer specifications.

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.

# operation

1 Create new job

2 retrieve state

3 status

4 lifetime

5 subscribe

6 suspend

7 terminate

8 terminate multiple

Description

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), ⁶ 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 state-related conventions.

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

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 in messages).

˲ 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