[ogsa-wg] RE: Modeling State: Technical Questions
zzalsmm3 at nessie.mcc.ac.uk
Tue Apr 5 06:26:40 CDT 2005
My example URIs perhaps were not very good
but URIs should be opaque.
Quoting the "Architecture of the World Wide Web"
"Agents making use of URIs SHOULD NOT attempt to infer
properties of the referenced resource."
So the URI
might identify the resource that represents all of
Ian's active jobs that have used more than one hours CPU time.
> 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.
> >... 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
More information about the ogsa-wg