[ogsa-wg] Modeling State: Technical Questions
foster at mcs.anl.gov
Sun Mar 6 22:47:15 CST 2005
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.
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.
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
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.
More information about the ogsa-wg