table 3: syntax used in Ws-Rf job management interface, showing for each operation of table 2 the request message, destination address, and return message.

# message

1 CreateJob(job-specification)

2 GetResourcePropertyDocument()

3 GetResourceProperty(“status”)

4 setterminationtime(lifetime)

5 subscribe(condition)

6 suspend

7 Destroy

8 destroymultiple(job-description)

to Returns on success

job-factory-service Ws-resource-qualified epr to job state (job handle)

job-handle epr Xml document comprising all job state

job-handle epr Job status

job-handle epr new lifetime

job-handle epr epr to subscription

job-handle epr Acknowledgment

job-handle epr Acknowledgment

job-factory-service Acknowledgment

table 4: syntax used in Ws-transfer job management interface, showing for each operation of table 2 the request message, destination address, and return message.

to Returns on success

job-factory-service epr to job state

job-handle epr Xml document comprising all job state

job-handle epr Xml document comprising all job state, from which status can be extracted.

4 setlifetime(lifetime) job-handle epr new lifetime

5 subscribe(condition) job-handle epr epr to subscription

6 suspend job-handle epr Acknowledgment

7 Delete() job-handle epr Acknowledgment

8 deletemultiple(job-spec) job-factory-service Acknowledgment

# message

1 create(job-spec)

2 Get()

3 Get()

table 5: syntax used in Rest job management interface, showing for each operation of table 2 the request message, destination address, and return message.

Returns on success

uri(s) identifying the job(s) that have been created: e.g., http://grid.org/bloggs/ Jobs/4523

2 httP Get http://grid.org/bloggs/Jobs/4523 A representation of the state of the job, including Xlinks and semantic information

3 httP Get http://grid.org/bloggs/Jobs/4523/status A representation of the status of the job

4 httP Put exp-time http://grid.org/bloggs/Jobs/4523/lifetime Acknowledgment

5 httP Post condition http://grid.org/bloggs/Jobs/4523/subs uri identifying the new subscription

http://grid.org/bloggs/Jobs/4523/status Acknowledgment

# message

1 httP Post job-specification

to

job-factory-service (e.g., http://grid.org)

6 httP Put “suspended”

7 httP Delete

8—

http://grid.org/bloggs/Jobs/4523

—

Acknowledgment

that we can focus in this section on syntax and postpone discussion of the advantages or disadvantages of adopting specific “standards” (conventions) to later in this article.

WS-RF implementation. Table 3 describes a job management interface based on the WS-RF and WS-Notification specifications. Here, we use boldface type to indicate operation names that are defined in some specification associated with the approach in question. Those operations that are not in boldface are, by definition, not defined in any existing specification, and thus their syntax and semantics represent somewhat arbitrary choices, selected for illustrative purposes. We see that WS-RF and WS-Notification specifications provide five of the eight required functions.

The job handle returned upon success from operation 1 is represented as an EPR. A client receiving such a job handle can then use it as a destination for operations 2–7. Note that requests are directed to the Web service address contained in the job handle EPR, which may or may not be the job factory service. This distinction is important because it allows for a logical and/or physical separation between the job factory and job management functions.

Operation 8 is sent directly to the job factory service, which is assumed to have access to information about all active jobs. The argument could be, for example, a specification (such as an Xpath specification) identifying the jobs that are to be terminated (for example, all jobs created by Bloggs or all jobs that have exceeded their quota, and/or a list of EPRs denoting the jobs to be terminated).

WS- Transfer implementation. Table 4 describes a job management interface based on the use of the WS-Transfer and WS-Eventing specifications, which provide five of the eight required operations.

As in the WS-RF interface, the job handle returned upon success from operation 1 is represented as an EPR, and a client receiving such a job handle can then use it as a destination for operations 2–7. Note that requests are directed to the Web service address contained in the job-handle structure, which may or may not be the job-factory service.