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