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.
NO-CONVEN TIONS APPROACH
Finally, in the “no conventions for managing state” approach (shortened to “no conventions” in table 1), 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, but without the introduction of state-related conventions.
#
1
Create new job
2
3
4
5
6
7
8
Retrieve state Status Lifetime Subscribe Suspend Terminate Terminate multiple
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 indicating 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. Each approach not only has in com-
mon 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 that we can focus in this section on syntax and postpone discussion of the advantages or disadvantages of
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.
References:
Archives