[ogsa-wg] RE: Modeling State: Technical Questions
Mark McKeown
zzalsmm3 at nessie.mcc.ac.uk
Tue Apr 5 04:24:11 CDT 2005
Hi Paul,
I have inlined some comments...
> >
> > > 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).
I am not sure why people think there should only be a
one-to-one mapping of a job to a resource. Applying REST:
GET http://thegrid/user/Ian/jobs
returns a representation of all of Ian's jobs
(or maybe just Xlinks to resources that represent those
jobs).
To suspend all the active jobs send a suspend message to the
resource that represents all the Active jobs:
POST http://thegrid/user/Ian/jobs/Active 'Suspend'
Suspending specific jobs of Ian's, send a suspend message to
the resource that represents the specific jobs:
POST http://thegrid/user/Ian/jobs/Active?job=27&job=35 'Suspend'
or
DELETE http://thegrid/user/Ian/jobs/Active?job=27&job=35
Suspend all jobs that have used over 1 hours of CPU time owned
by Ian:
POST http://thegrid/user/Ian/jobs/Active?MinCPUTimeUsed=3600 'Suspend'
Using conventional SOAP operation this looks like:
suspend('All-jobs-owned-by-Ian + CPUtime > 36000' )
Doing it this way requires coming up with a suitable query
language. Access control could be more difficult, in the
REST case only Ian should be able to access resources starting
with http://thegrid/user/Ian/.
In theory the above could be done with WS-Resources using WSRF
- I suspect it would be more difficult/complex though.
Perhaps I am very wrong though...
cheers
Mark
> >
> >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
>
More information about the ogsa-wg
mailing list