Marvin:
David's proposal, which is realized in the current draft, is that we
define BES to just have "GetStatus" and
"GetProperties" operations (as well as CreateActivity etc.). We
can then compose WS-Transfer operations or WSRF operations, if desired,
in a particular BES implementation.
This seems to me to be a really nice solution to the "problem"
that we thought we had, in that it avoids the need for multiple
renderings.
The one tricky issue is the rendering of faults. In the current BES
document, we use WS-BaseFaults. You report that the Microsoft WS team has
problems with that. I don't think we should let this be a show stopper,
as I don't think it is essential that we use WS-BaseFaults in BES. At the
same time, WS-BaseFaults was introduced for a reason. Thus I'd like to
propose that we proceed as follows:
a) We set up a phone call with the Microsoft WS team and the
WS-BaseFaults guys to talk this over, in case it turns out that we can in
fact all agree that WS-BaseFaults is useful.
b) In the (likely) case that the Microsoft WS team still doesn't want to
see WS-BaseFaults included, we check with the BES team that it is ok to
use a different fault model for the BES core vs. the specs that might be
composed with the BES core, such as WSRF.
Thoughts?
Ian.
At 05:17 PM 8/16/2006 -0700, Marvin Theimer wrote:
Hi;
Another comment/question on Dave
Snellings proposal: I dont really understand how it avoids distinct
renderings since it is still the case that we have at least 3 different
WSDLs, one per rendering option:
·
WSRF version that employs WS-ResourceProperties, etc.
·
WS-Transfer version that employs WS-Transfer, etc.
·
Resource model-free version that employs an explicit QueryStatus
operation (and potentially additional QueryFoo operations).
It is certainly the case that there
is a coreset of operations that is common to all 3 interface choices and
we should certainly write the spec that way. But dont we still end
up with 3 different rendering versions?
Marvin.
From: Ian Foster
[mailto:foster@mcs.anl.gov]
Sent: Friday, August 04, 2006 2:20 PM
To: Marvin Theimer; ogsa-bes-wg@ggf.org
Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that
reflects the decisions of the July F2F mtg
Marvin:
I've claimed the pen on the document, but have been finding it hard to
find time to make a lot of progress. I will try to do some work on it
tomorrow morning.
That said, I want to mention an important development that Dave Snelling
may or may not have mentioned on calls. Dave argues that we can avoid the
need for distinct renderings by defining our interfaces carefully. The
basic idea, as I understand it, is that:
a) the "core interface" has the basic operations for creating
jobs, modifying their status, etc., and an operation for grabbing all of
the factory state;
b) then, if desired, a WSRF service (for example) can also implement the
WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification,
operations;
c) while a WS-Resource service would implement the WS-Resource
equivalents of those.
So we exploit the power of interface composition to avoid the need for
separate bindings.
The only problematic issue, as I understand it, is that of faults. The
question is how we render faults. The WSRF binding must (by the spec) use
WS-BaseFaults. If we can all agree to use that, then we are ok. If not,
then we still have problems.
Ian.
At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote:
x-ms-exchange-organization-recipient-p2-type: To
Content-Type: text/plain; charset="us-ascii"
Hi;
The HPC Profile (HPCP) work depends critically on BES. The recent
face-to-face meeting at Argonne made substantial progress in terms of
reshaping the proposed BES specification in a way that would make it
suitable for supporting the HPCP on top of it. Are there plans to
generate a new revision of the BES specification draft in the near
future? As soon as the revised version comes into existence we'll
be able to seriously start doing the actual HPCP work (which will take
place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that
will be starting shortly).
Since the HPCP WG is effectively gated on this revised spec, having a
draft of a revised spec sometime in the next week or so would be really
helpful. I would be willing to help rewrite the BES spec if that
would be useful to the BES WG.
Marvin.
_______________________________________________________________
Ian
Foster, Director, Computation Institute
Argonne National Laboratory & University of
Chicago
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL
60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL
60637
Tel: +1 630 252 4619. Web:
www.ci.uchicago.edu.
Globus Alliance:
www.globus.org.
_______________________________________________________________
Ian Foster -- Weblog:
http://ianfoster.typepad.com
Computation Institute:
www.ci.uchicago.edu
& www.ci.anl.gov
Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439
Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org