[ogsa-wg] RE: Modeling State: Technical Questions

[Ian Foster]

Paul:

My apologies for the slow reply: I left on vacation soon after sending my 
email.

Your notes all look good to me. I'm putting together a revised version of 
my discussion document that trys to capture these and other points.

Ian.


At 12:14 PM 3/11/2005 +0000, Paul Watson wrote:
>Dear Ian,
>
>Having faithfully promised myself that I wouldn't spend more time on
>discussions about low-level WS specs, I found myself drawn in as this is
>a very interesting comparison (it reminded me of the excellent work done
>in the DAIS WG to compare different approaches to database access
>services). In particular, it gives me a concrete example that I can use
>to ask some questions about the use of WSRF. Given that I come from a
>non-WSRF background (my experience is with services that use the
>approach in your option #3) much of what I've written below is about
>understanding the motivation for switching to the WSRF approach. But,
>I'd like to stress that this isn't intended to be hostile ... it's meant
>to improve my understanding and (hopefully) move on the technical
>debate.
>
>I was going to send it to you only, as you offered to collate feedback,
>but as Dave Berry is proposing to discuss these options next week (and I
>won't be there) and has posted on it, I thought that I'd send it to Dave
>and others too as input to these discussions.
>
> > 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
> >
>
>If there are other operations that need to be supported on jobs, e.g.
>"suspend, resume, checkpoint, change priority"... then am I right in
>thinking that these would be provided by application-specific operations
>on resources that were not defined by WSRF?
>
>e.g. send "Suspend" to job-handle,
>send "changePriority" to job-handle etc.
>
> > 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
>
>Given previous misunderstandings, it is good to see that your WSRF
>example also includes some operations on the service.
>
>I think that the motivation for introducing operations on the service is
>that these can then operate over a set of resources (e.g.
>"all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one
>interaction with the service vs. one to each resource in the set of
>"all-jobs-owned-by-ian"), and also allows the set of resources to be
>selected using information encapsulated within the service (e.g.
>"jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs
>that have run for more than 24 hours"). Therefore, for similar reasons,
>it would, I think, also be beneficial to define a "check-jobs-status"
>operation on the service. This would allow, for example:
>
>check-jobs-status("all-jobs-owned-by-ian")
>
>Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem
>reasonable to allow the consumer to specify the set of jobs by name:
>
>"destroy(job1,job27,job35)"
>"check-jobs-status(job1,job27,job35)"
>
>(I may be wrong, but I think that the current naming proposal would
>allow this by giving the consumer the abstract name for a resource as
>well as the epr).
>
>These operations on the service are the sort I'd expect to see in option
>#3 (as I'll explain below). So, I think that one could view option #1 as
>taking the operations from option #3 and then adding to them a set of
>operations on individual resources.
>
>These operations on the service allow a consumer to (I think) do
>everything without using the operations on individual resources. This is
>because these operations address the general case for a job submission
>service... they provide operations over the set of resources
>encapsulated by the service. They appear to have the advantage of
>supporting and encouraging larger-grained operations, e.g. in one
>message you can ask about a set of resources rather than just one. I
>expect that will be important for performance, given the costs of
>sending messages between web services. The operations on individual
>resources seem to be a special case of the general case, and this raises
>the question (to me) that if the job management service provides the
>general case, then when is it better to use the special case?
>
> > 3) (Job id) The job-handle is a job-factory-specific string,
>
>I'd think that it could be an "abstract name" in OGSA naming terms
>(though the naming proposal isn't fixed yet, so I may be wrong).
>
> > 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).
>
>As described in my comments on option #1 above, I'd suggest that both
>these operations should be defined to operate on a set of jobs (c.f.
>option #1's "destroy(all-jobs-owned-by-ian)).
>
>e.g. the operations on the service would allow:
>
>"check-jobs-status(job1, job14,job27)"
>"terminate-jobs(job2, job35)"
>
>Allowing multiple job names in a message is, I think, no more difficult
>to implement, and naturally scales up to larger granularity operations
>(e.g. one interaction with a service is enough to carry out actions on
>1,2 or 500 jobs).
>
>Option #3 also differs from #1 and #2 as it does not rely on
>ws-addressing (though it could use it). [A personal view is that I see
>this as an advantage for those who want to design and build services now
>or in the near future. This is because the service can use only
>currently stable specifications found in the set "blessed" by
>WS-Interoperability, and these are provided in an interoperable manner
>by a wide range of existing WS platforms.]
>
> > 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?
> >
>
>I note that Dave & Karl have now posted about the possible use of
>ResourceGroups. I based the above on your message which did not discuss
>their use, and so I wonder if it would therefore be helpful for someone
>to produce a version of option #1 that creates and uses resourcegroups.
>
>This was a very good start for discussion, and I'd be interested on your
>views on my comments above.
>
>Regards
>
>Paul.
>
> >-----Original Message-----
> >From: Ian Foster [mailto:foster at mcs.anl.gov]
> >Sent: 07 March 2005 04:47
> >To: Tony Hey; Frank Siebenlist
> >Cc: Dennis Gannon; Samuel Meder; ogsa-wg;
> >paul.watson at ncl.ac.uk; dave.pearson at oracle.com;
> >savas.parastatidis at ncl.ac.uk; gray at microsoft.com;
> >humphrey at cs.virginia.edu; grimshaw at virginia.edu;
> >aherbert at microsoft.com; gcf at indiana.edu; mark.linesch at hp.com
> >Subject: Modeling State: Technical Questions
> >
> >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.
> >
> >
> >

_______________________________________________________________
Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
         Globus Alliance, www.globus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050327/d73b1314/attachment.html