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

[Mark McKeown]

Hi Karl,
        My example URIs perhaps were not very good
but URIs should be opaque.

Quoting the "Architecture of the World Wide Web"
Section 2.5:

"Agents making use of URIs SHOULD NOT attempt to infer
properties of the referenced resource."


So the URI

http://thegrid/35467356754674567456770807

might identify the resource that represents all of
Ian's active jobs that have used more than one hours CPU time.


cheers
Mark


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