Paul's email bounced.
----
Hiro Kishimoto
Subject: RE: Modeling State: Technical Questions
Date: Fri, 11 Mar 2005 12:14:07 -0000
From: "Paul Watson" <Paul.Watson(a)newcastle.ac.uk>
To: "Ian Foster" <foster(a)mcs.anl.gov>
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
>=20
> 1) (WSRF)
>=20
> The job handle is an EPR to a WS-Resource, in which case the case the=20
> WSRF operations can be used to get status and delete:
>=20
> send "GetResourceProperty(status)" to job-handle
> send "Destroy" to job-handle
>=20
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=20
> to the job-factory, which is straightforward as there is no strong=20
> encapsulation in WSRF. E.g.:
>=20
> 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)"=20
"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.:
>=20
> send "check-job-status(job-handle)" to job-factory
> send "terminate-job(job-handle)" to job-factory
>=20
> #3 is very similar to #1 and #2: the message sent over the wire in=20
> each case contains the same information (operation name + Web service=20
> 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=20
> separately from the job-factory EPR. Also, you don't use the=20
> standardized WSRF/WSN operations.
>=20
> Have I captured all of the options that people think we should be=20
> considering?
>=20
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.=20
>-----Original Message-----
>From: Ian Foster [mailto:foster@mcs.anl.gov]=20
>Sent: 07 March 2005 04:47
>To: Tony Hey; Frank Siebenlist
>Cc: Dennis Gannon; Samuel Meder; ogsa-wg;=20
>paul.watson(a)ncl.ac.uk; dave.pearson(a)oracle.com;=20
>savas.parastatidis(a)ncl.ac.uk; gray(a)microsoft.com;=20
>humphrey(a)cs.virginia.edu; grimshaw(a)virginia.edu;=20
>aherbert(a)microsoft.com; gcf(a)indiana.edu; mark.linesch(a)hp.com
>Subject: Modeling State: Technical Questions
>
>Dear All:
>
>In an effort to move forward this debate about "OGSA=20
>plumbing", I thought=20
>I'd attempt to describe the different positions that I've seen=20
>expressed.=20
>Perhaps people can read this quickly, and provide feedback as=20
>to where I=20
>have not captured things correctly. I'll be happy to collate=20
>responses sent=20
>directly to me and forward them, if there is interest.
>
>
>CONTEXT
>
>The context is that OGSA-WG needs to develop some low-level=20
>specifications,=20
>such as execution management services, that require modeling=20
>interactions=20
>that involve server-side state. E.g., in the following=20
>pseudo-code example,=20
>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=20
>needed. (Let=20
>me know if not.)
>
>Where people differ in their views is with respect to what the=20
>"job-handle"=20
>should be and how we should represent operations on the job.=20
>I've heard=20
>three views expressed, as follows.
>
>
>OPTIONS
>
>1) (WSRF)
>
>The job handle is an EPR to a WS-Resource, in which case the=20
>case the WSRF=20
>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=20
>requests to the=20
>job-factory, which is straightforward as there is no strong=20
>encapsulation=20
>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=20
>various operations (GetResourceProperty, Destroy, etc.) defined by the=20
>WSRF/WSN specifications.
>
>
>2) (WS-Transfer)
>
>The job-handle is an EPR to a WS-Transfer resource, in which case the=20
>appropriate WS-Transfer operations can be used to get status=20
>and delete.
>
> send "Get" to job-handle
> send "Delete" to job-handle
>
>Assuming that there is no strong encapsulation in WS-Transfer=20
>either, one=20
>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=20
>various operations=20
>(GetResourceProperty, Destroy, etc.) defined by the=20
>WS-Transfer specification.
>
>#2 is very similar to #1. One can argue the pros and cons of the two=20
>approaches. I'm concerned that you have to return the whole=20
>resource state,=20
>not just a single component (e.g., the status field). But that's a=20
>relatively minor issue.
>
>
>3) (Job id) The job-handle is a job-factory-specific string,=20
>and we define=20
>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=20
>wire in each=20
>case contains the same information (operation name + Web=20
>service address +=20
>job-id-info). What is different about #3 is that you have to=20
>manage this=20
>job-handle separately from the job-factory EPR. Also, you=20
>don't use the=20
>standardized WSRF/WSN operations.
>
>Have I captured all of the options that people think we should=20
>be considering?
>
>
>WHAT OGSA-WG SHOULD DO
>
>Given this characterization, I'd also be interested in=20
>people's views as to=20
>how OGSA-WG should proceed when considering specifications=20
>that involve=20
>this sort of interaction pattern.
>
>The majority of active participants OGSA-WG participants seem to favor=20
>option #1, but I've also heard people argue in favor of=20
>approaches #2 and #3.
>
>Tony Hey proposed, I think, that we should define=20
>specifications like job=20
>management in terms of some more abstract interface that can=20
>then be mapped=20
>to each of the approaches above, as desired.
>
>Frank Seibenlist observed that we can use WSRF/WSN as such an abstract=20
>interface: given an interface defined in terms of WSRF/WSN=20
>specifications,=20
>one can derive, via straightforward transformations, a concrete=20
>specification in the style of approach #2 or #3.
>
>Regards -- Ian.
>
>
>
