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@univa.com