[ogsa-wg] Modeling State: Technical Questions

[Ian Foster]

Dear All:

In an effort to move forward this debate about "OGSA plumbing", I thought 
I'd attempt to describe the different positions that I've seen expressed. 
Perhaps people can read this quickly, and provide feedback as to where I 
have not captured things correctly. I'll be happy to collate responses sent 
directly to me and forward them, if there is interest.


CONTEXT

The context is that OGSA-WG needs to develop some low-level specifications, 
such as execution management services, that require modeling interactions 
that involve server-side state. E.g., in the following pseudo-code example, 
we request the creation of a "job":

	send "create(jsdl-specification)" to job-factory-web-service
	receive "job-handle" from job-factory-web-service

I think that everyone accept that this sort of interaction is needed. (Let 
me know if not.)

Where people differ in their views is with respect to what the "job-handle" 
should be and how we should represent operations on the job. I've heard 
three views expressed, as follows.


OPTIONS

1) (WSRF)

The job handle is an EPR to a WS-Resource, in which case the case the WSRF 
operations can be used to get status and delete:

	send "GetResourceProperty(status)" to job-handle
	send "Destroy" to job-handle

In addition, one will probably also want to be able to send requests to the 
job-factory, which is straightforward as there is no strong encapsulation 
in WSRF. E.g.:

	send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service

This approach exploits the standardized syntax and semantics for the 
various operations (GetResourceProperty, Destroy, etc.) defined by the 
WSRF/WSN specifications.


2) (WS-Transfer)

The job-handle is an EPR to a WS-Transfer resource, in which case the 
appropriate WS-Transfer operations can be used to get status and delete.

	send "Get" to job-handle
	send "Delete" to job-handle

Assuming that there is no strong encapsulation in WS-Transfer either, one 
can also contact the job-factory directly when required:

	send "destroy(jobs-owned-by-ian)" to job-factory

This approach exploits the syntax and semantics for the various operations 
(GetResourceProperty, Destroy, etc.) defined by the WS-Transfer specification.

#2 is very similar to #1. One can argue the pros and cons of the two 
approaches. I'm concerned that you have to return the whole resource state, 
not just a single component (e.g., the status field). But that's a 
relatively minor issue.


3) (Job id) The job-handle is a job-factory-specific string, and we define 
job-factory-specific operations for manipulating the job, e.g.:

	send "check-job-status(job-handle)" to job-factory
	send "terminate-job(job-handle)" to job-factory

#3 is very similar to #1 and #2: the message sent over the wire in each 
case contains the same information (operation name + Web service address + 
job-id-info). What is different about #3 is that you have to manage this 
job-handle separately from the job-factory EPR. Also, you don't use the 
standardized WSRF/WSN operations.

Have I captured all of the options that people think we should be considering?


WHAT OGSA-WG SHOULD DO

Given this characterization, I'd also be interested in people's views as to 
how OGSA-WG should proceed when considering specifications that involve 
this sort of interaction pattern.

The majority of active participants OGSA-WG participants seem to favor 
option #1, but I've also heard people argue in favor of approaches #2 and #3.

Tony Hey proposed, I think, that we should define specifications like job 
management in terms of some more abstract interface that can then be mapped 
to each of the approaches above, as desired.

Frank Seibenlist observed that we can use WSRF/WSN as such an abstract 
interface: given an interface defined in terms of WSRF/WSN specifications, 
one can derive, via straightforward transformations, a concrete 
specification in the style of approach #2 or #3.

Regards -- Ian.