RE: Modeling State: Technical Questions
Paul: My apologies for the slow reply: I left on vacation soon after sending my email. Your notes all look good to me. I'm putting together a revised version of my discussion document that trys to capture these and other points. Ian. At 12:14 PM 3/11/2005 +0000, Paul Watson wrote:
Dear Ian,
Having faithfully promised myself that I wouldn't spend more time on discussions about low-level WS specs, I found myself drawn in as this is a very interesting comparison (it reminded me of the excellent work done in the DAIS WG to compare different approaches to database access services). In particular, it gives me a concrete example that I can use to ask some questions about the use of WSRF. Given that I come from a non-WSRF background (my experience is with services that use the approach in your option #3) much of what I've written below is about understanding the motivation for switching to the WSRF approach. But, I'd like to stress that this isn't intended to be hostile ... it's meant to improve my understanding and (hopefully) move on the technical debate.
I was going to send it to you only, as you offered to collate feedback, but as Dave Berry is proposing to discuss these options next week (and I won't be there) and has posted on it, I thought that I'd send it to Dave and others too as input to these discussions.
OPTIONS
1) (WSRF)
The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete:
send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle
If there are other operations that need to be supported on jobs, e.g. "suspend, resume, checkpoint, change priority"... then am I right in thinking that these would be provided by application-specific operations on resources that were not defined by WSRF?
e.g. send "Suspend" to job-handle, send "changePriority" to job-handle etc.
In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.:
send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service
Given previous misunderstandings, it is good to see that your WSRF example also includes some operations on the service.
I think that the motivation for introducing operations on the service is that these can then operate over a set of resources (e.g. "all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one interaction with the service vs. one to each resource in the set of "all-jobs-owned-by-ian"), and also allows the set of resources to be selected using information encapsulated within the service (e.g. "jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs that have run for more than 24 hours"). Therefore, for similar reasons, it would, I think, also be beneficial to define a "check-jobs-status" operation on the service. This would allow, for example:
check-jobs-status("all-jobs-owned-by-ian")
Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem reasonable to allow the consumer to specify the set of jobs by name:
"destroy(job1,job27,job35)" "check-jobs-status(job1,job27,job35)"
(I may be wrong, but I think that the current naming proposal would allow this by giving the consumer the abstract name for a resource as well as the epr).
These operations on the service are the sort I'd expect to see in option #3 (as I'll explain below). So, I think that one could view option #1 as taking the operations from option #3 and then adding to them a set of operations on individual resources.
These operations on the service allow a consumer to (I think) do everything without using the operations on individual resources. This is because these operations address the general case for a job submission service... they provide operations over the set of resources encapsulated by the service. They appear to have the advantage of supporting and encouraging larger-grained operations, e.g. in one message you can ask about a set of resources rather than just one. I expect that will be important for performance, given the costs of sending messages between web services. The operations on individual resources seem to be a special case of the general case, and this raises the question (to me) that if the job management service provides the general case, then when is it better to use the special case?
3) (Job id) The job-handle is a job-factory-specific string,
I'd think that it could be an "abstract name" in OGSA naming terms (though the naming proposal isn't fixed yet, so I may be wrong).
and we define job-factory-specific operations for manipulating the job, e.g.:
send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory
#3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info).
As described in my comments on option #1 above, I'd suggest that both these operations should be defined to operate on a set of jobs (c.f. option #1's "destroy(all-jobs-owned-by-ian)).
e.g. the operations on the service would allow:
"check-jobs-status(job1, job14,job27)" "terminate-jobs(job2, job35)"
Allowing multiple job names in a message is, I think, no more difficult to implement, and naturally scales up to larger granularity operations (e.g. one interaction with a service is enough to carry out actions on 1,2 or 500 jobs).
Option #3 also differs from #1 and #2 as it does not rely on ws-addressing (though it could use it). [A personal view is that I see this as an advantage for those who want to design and build services now or in the near future. This is because the service can use only currently stable specifications found in the set "blessed" by WS-Interoperability, and these are provided in an interoperable manner by a wide range of existing WS platforms.]
What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations.
Have I captured all of the options that people think we should be considering?
I note that Dave & Karl have now posted about the possible use of ResourceGroups. I based the above on your message which did not discuss their use, and so I wonder if it would therefore be helpful for someone to produce a version of option #1 that creates and uses resourcegroups.
This was a very good start for discussion, and I'd be interested on your views on my comments above.
Regards
Paul.
-----Original Message----- From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 07 March 2005 04:47 To: Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson@ncl.ac.uk; dave.pearson@oracle.com; savas.parastatidis@ncl.ac.uk; gray@microsoft.com; humphrey@cs.virginia.edu; grimshaw@virginia.edu; aherbert@microsoft.com; gcf@indiana.edu; mark.linesch@hp.com Subject: Modeling State: Technical Questions
Dear All:
In an effort to move forward this debate about "OGSA plumbing", I thought I'd attempt to describe the different positions that I've seen expressed. Perhaps people can read this quickly, and provide feedback as to where I have not captured things correctly. I'll be happy to collate responses sent directly to me and forward them, if there is interest.
CONTEXT
The context is that OGSA-WG needs to develop some low-level specifications, such as execution management services, that require modeling interactions that involve server-side state. E.g., in the following pseudo-code example, we request the creation of a "job":
send "create(jsdl-specification)" to job-factory-web-service receive "job-handle" from job-factory-web-service
I think that everyone accept that this sort of interaction is needed. (Let me know if not.)
Where people differ in their views is with respect to what the "job-handle" should be and how we should represent operations on the job. I've heard three views expressed, as follows.
OPTIONS
1) (WSRF)
The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete:
send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle
In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.:
send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service
This approach exploits the standardized syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WSRF/WSN specifications.
2) (WS-Transfer)
The job-handle is an EPR to a WS-Transfer resource, in which case the appropriate WS-Transfer operations can be used to get status and delete.
send "Get" to job-handle send "Delete" to job-handle
Assuming that there is no strong encapsulation in WS-Transfer either, one can also contact the job-factory directly when required:
send "destroy(jobs-owned-by-ian)" to job-factory
This approach exploits the syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WS-Transfer specification.
#2 is very similar to #1. One can argue the pros and cons of the two approaches. I'm concerned that you have to return the whole resource state, not just a single component (e.g., the status field). But that's a relatively minor issue.
3) (Job id) The job-handle is a job-factory-specific string, and we define job-factory-specific operations for manipulating the job, e.g.:
send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory
#3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info). What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations.
Have I captured all of the options that people think we should be considering?
WHAT OGSA-WG SHOULD DO
Given this characterization, I'd also be interested in people's views as to how OGSA-WG should proceed when considering specifications that involve this sort of interaction pattern.
The majority of active participants OGSA-WG participants seem to favor option #1, but I've also heard people argue in favor of approaches #2 and #3.
Tony Hey proposed, I think, that we should define specifications like job management in terms of some more abstract interface that can then be mapped to each of the approaches above, as desired.
Frank Seibenlist observed that we can use WSRF/WSN as such an abstract interface: given an interface defined in terms of WSRF/WSN specifications, one can derive, via straightforward transformations, a concrete specification in the style of approach #2 or #3.
Regards -- Ian.
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org
Hi Paul, I have inlined some comments...
OPTIONS
1) (WSRF)
The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete:
send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle
If there are other operations that need to be supported on jobs, e.g. "suspend, resume, checkpoint, change priority"... then am I right in thinking that these would be provided by application-specific operations on resources that were not defined by WSRF?
e.g. send "Suspend" to job-handle, send "changePriority" to job-handle etc.
In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.:
send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service
Given previous misunderstandings, it is good to see that your WSRF example also includes some operations on the service.
I think that the motivation for introducing operations on the service is that these can then operate over a set of resources (e.g. "all-jobs-owned-by-ian"). This reduces the number of messages (e.g. one interaction with the service vs. one to each resource in the set of "all-jobs-owned-by-ian"), and also allows the set of resources to be selected using information encapsulated within the service (e.g. "jobs-owned-by-ian", "jobs that have nearly reached their quota", "jobs that have run for more than 24 hours"). Therefore, for similar reasons, it would, I think, also be beneficial to define a "check-jobs-status" operation on the service. This would allow, for example:
check-jobs-status("all-jobs-owned-by-ian")
Also, as, "all-jobs-owned-by-ian" defines a set of jobs, it would seem reasonable to allow the consumer to specify the set of jobs by name:
"destroy(job1,job27,job35)" "check-jobs-status(job1,job27,job35)"
(I may be wrong, but I think that the current naming proposal would allow this by giving the consumer the abstract name for a resource as well as the epr).
I am not sure why people think there should only be a one-to-one mapping of a job to a resource. 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
These operations on the service are the sort I'd expect to see in option #3 (as I'll explain below). So, I think that one could view option #1 as taking the operations from option #3 and then adding to them a set of operations on individual resources.
These operations on the service allow a consumer to (I think) do everything without using the operations on individual resources. This is because these operations address the general case for a job submission service... they provide operations over the set of resources encapsulated by the service. They appear to have the advantage of supporting and encouraging larger-grained operations, e.g. in one message you can ask about a set of resources rather than just one. I expect that will be important for performance, given the costs of sending messages between web services. The operations on individual resources seem to be a special case of the general case, and this raises the question (to me) that if the job management service provides the general case, then when is it better to use the special case?
3) (Job id) The job-handle is a job-factory-specific string,
I'd think that it could be an "abstract name" in OGSA naming terms (though the naming proposal isn't fixed yet, so I may be wrong).
and we define job-factory-specific operations for manipulating the job, e.g.:
send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory
#3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info).
As described in my comments on option #1 above, I'd suggest that both these operations should be defined to operate on a set of jobs (c.f. option #1's "destroy(all-jobs-owned-by-ian)).
e.g. the operations on the service would allow:
"check-jobs-status(job1, job14,job27)" "terminate-jobs(job2, job35)"
Allowing multiple job names in a message is, I think, no more difficult to implement, and naturally scales up to larger granularity operations (e.g. one interaction with a service is enough to carry out actions on 1,2 or 500 jobs).
Option #3 also differs from #1 and #2 as it does not rely on ws-addressing (though it could use it). [A personal view is that I see this as an advantage for those who want to design and build services now or in the near future. This is because the service can use only currently stable specifications found in the set "blessed" by WS-Interoperability, and these are provided in an interoperable manner by a wide range of existing WS platforms.]
What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations.
Have I captured all of the options that people think we should be considering?
I note that Dave & Karl have now posted about the possible use of ResourceGroups. I based the above on your message which did not discuss their use, and so I wonder if it would therefore be helpful for someone to produce a version of option #1 that creates and uses resourcegroups.
This was a very good start for discussion, and I'd be interested on your views on my comments above.
Regards
Paul.
-----Original Message----- From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: 07 March 2005 04:47 To: Tony Hey; Frank Siebenlist Cc: Dennis Gannon; Samuel Meder; ogsa-wg; paul.watson@ncl.ac.uk; dave.pearson@oracle.com; savas.parastatidis@ncl.ac.uk; gray@microsoft.com; humphrey@cs.virginia.edu; grimshaw@virginia.edu; aherbert@microsoft.com; gcf@indiana.edu; mark.linesch@hp.com Subject: Modeling State: Technical Questions
Dear All:
In an effort to move forward this debate about "OGSA plumbing", I thought I'd attempt to describe the different positions that I've seen expressed. Perhaps people can read this quickly, and provide feedback as to where I have not captured things correctly. I'll be happy to collate responses sent directly to me and forward them, if there is interest.
CONTEXT
The context is that OGSA-WG needs to develop some low-level specifications, such as execution management services, that require modeling interactions that involve server-side state. E.g., in the following pseudo-code example, we request the creation of a "job":
send "create(jsdl-specification)" to job-factory-web-service receive "job-handle" from job-factory-web-service
I think that everyone accept that this sort of interaction is needed. (Let me know if not.)
Where people differ in their views is with respect to what the "job-handle" should be and how we should represent operations on the job. I've heard three views expressed, as follows.
OPTIONS
1) (WSRF)
The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete:
send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle
In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.:
send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service
This approach exploits the standardized syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WSRF/WSN specifications.
2) (WS-Transfer)
The job-handle is an EPR to a WS-Transfer resource, in which case the appropriate WS-Transfer operations can be used to get status and delete.
send "Get" to job-handle send "Delete" to job-handle
Assuming that there is no strong encapsulation in WS-Transfer either, one can also contact the job-factory directly when required:
send "destroy(jobs-owned-by-ian)" to job-factory
This approach exploits the syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WS-Transfer specification.
#2 is very similar to #1. One can argue the pros and cons of the two approaches. I'm concerned that you have to return the whole resource state, not just a single component (e.g., the status field). But that's a relatively minor issue.
3) (Job id) The job-handle is a job-factory-specific string, and we define job-factory-specific operations for manipulating the job, e.g.:
send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory
#3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info). What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations.
Have I captured all of the options that people think we should be considering?
WHAT OGSA-WG SHOULD DO
Given this characterization, I'd also be interested in people's views as to how OGSA-WG should proceed when considering specifications that involve this sort of interaction pattern.
The majority of active participants OGSA-WG participants seem to favor option #1, but I've also heard people argue in favor of approaches #2 and #3.
Tony Hey proposed, I think, that we should define specifications like job management in terms of some more abstract interface that can then be mapped to each of the approaches above, as desired.
Frank Seibenlist observed that we can use WSRF/WSN as such an abstract interface: given an interface defined in terms of WSRF/WSN specifications, one can derive, via straightforward transformations, a concrete specification in the style of approach #2 or #3.
Regards -- Ian.
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org
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
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
Yes, your example confused me as my later reply should indicate. I am all in favor of opaque URIs. This is less disconcerting, but it begs the question of how one obtains the URI for the example below. I can only imagine it is by posing a structured query to a well-known service with a well-known data model and query language. I think this is the hard part; once the structured model is known, does it really help to "cook" queries into an intermediate URI result versus just embedding the query expression in the intended operation(s) as a scoping/selection argument? karl On Apr 05, Mark McKeown loaded a tape reading:
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
-- Karl Czajkowski karlcz@univa.com
Hi Karl,
Yes, your example confused me as my later reply should indicate. I am all in favor of opaque URIs. This is less disconcerting, but it begs the question of how one obtains the URI for the example below. I can only imagine it is by posing a structured query to a well-known service with a well-known data model and query language. I think this is the hard part; once the structured model is known, does it really help to "cook" queries into an intermediate URI result versus just embedding the query expression in the intended operation(s) as a scoping/selection argument?
I am not sure why you need an "intermediate" URI result, the URI http://thegrid/35467356754674567456770807 can identify the resource that represents all of Ian's active jobs that have used more than 1 hours CPU time for all time. You only have to find out what the URI is once - still doesn't help you find it the first time though ;-) cheers MArk
karl
On Apr 05, Mark McKeown loaded a tape reading:
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
-- Karl Czajkowski karlcz@univa.com
participants (3)
-
Ian Foster -
Karl Czajkowski -
Mark McKeown