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

[Hiro Kishimoto]

Roger's email bounced.
----
Hiro Kishimoto

Subject: Re: [ogsa-wg] RE: Modeling State: Technical Questions
From: Roger Menday <r.menday at fz-juelich.de>
To: Karl Czajkowski <karlcz at univa.com>
Cc: ogsa-wg at gridforum.org, Mark McKeown <zzalsmm3 at nessie.mcc.ac.uk>
Date: Tue, 05 Apr 2005 12:48:07 +0200

On Tue, 2005-04-05 at 17:09 +0700, Karl Czajkowski wrote:
> On Apr 05, Mark McKeown loaded a tape reading:
> ...
> > I am not sure why people think there should only be a one-to-one 
> > mapping of a job to a resource.
> 
> I do not think anyone is saying there should ONLY be a one-to-one 
> mapping, but rather that there is a one-to-one mapping of job to 
> resource for the mythical 80% solution.  In fact, it is this mapping 
> that gives us an inutitive sense of there being a job at all!  I have 
> come to think that part of the appeal of the WSRF approach for many is 
> to be able to more clearly codify which operations are applicable to a 
> specific resource for these 80% cases.  It does not preclude the other 
> 20% solutions, but gives us more firm ground upon which to think about 
> interoperability for the straightforward scenarios.
> 
> As for the rest of your message (sorry, no pun intended), I think you 
> underestimate the difficulty: you need a consensus on how to normalize 
> the concept space around all the different job metadata that might be 
> useful to reference jobs in different usage scenarios. This 
> normalization is inherent in having the hierarchical URI space in 
> which you've framed your simple examples.  My experience leads me to 
> have a flight response when I hear "consensus", "normalization", and 
> "concept modeling" in the same paragraph...
> 
> As an example, I find it exceedingly strange that the job's transient 
> state is part of its structured name below, but its unique numeric 
> identifier is used as a reference parameter. To me, it should clearly 
> be the other way around.

So, each job has it's own URI, eg, http://thegrid/users/ian/jobs/435

Then, doing a GET on this returns some document of job metadata

(??)

Roger

> I don't think you can really avoid the
> adoption of a query language for the 20% cases, whether it is some 
> ad-hoc URI+reference parameter strategy like this, or 
> XPath/XQuery/etc. against a structured group abstraction.  I think a 
> fruitful standards activity must start with a flat per-job reference 
> model and then add (optional) grouping abstractions to handle these 
> more exotic cases.
> 
> 
> karl
> 
> 
> >... 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
> > 
> > 
>