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. 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 services 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 services address contained in the job handle structure, which may or may not be the job factory service.

An alternative treatment of operation 3 is possible, albeit with some extra work, avoiding the need to transfer the entire state document. A new operation (for example, GetEPRtoPart) is defined, requesting that a new state representation be exposed, through a different EPR, representing parts of the original state representation. The Get() operation is then applied to this new EPR. WS-Transfer applications (and higher-level specifications such as WS-Management) often use this approach to address the lack of support for partial state access in WS-Transfer.

Operation 8 is sent directly to the job factory service, which is assumed to have access to information about all active jobs, as in the WS-RF case.

HTTP implementation. Table 5 summarizes the syntax of an HTTP implementation. Note that operation 5 can alternatively be addressed via some custom encoding or by using a system such as SMTP, Jabber, SMS, or Atom. HTTP DELETE cannot take any content, so there is no way to specify that a set of jobs (operation 8) can be deleted by using the HTTP DELETE message, except in the case when we delete all jobs in some predefined group (for example, “HTTP DELETE http://grid.org/Bloggs/Jobs” to delete all jobs created by Bloggs).

Note that whereas HTTP defines all the verbs used, the

TABLE
6
Syntax Used in Job Handle Approach

1 “New job” carrying the job specification

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 identifier(s) and subscription information (for each)

6 “Suspension” carrying job identifier(s)

7 “Destroy request” carrying job identifiers(s)

8 “Destroy request” carrying job identifier(s) and query expression

May also silently accept the message and report on fault only. If proof of delivery is necessary, WS-ReliableMessaging can be used.

job-management-service 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) any job service aware of the job identifier(s)

Identifier for the newly created job XML document with job state(s) XML document with job status(s) Acknowledgment* Acknowledgment*

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)

Acknowledgment*

Acknowledgment*

Acknowledgment*