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

[Karl Czajkowski]

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. 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
> 
> 

-- 
Karl Czajkowski
karlcz at univa.com