Hi;
Another comment/question on Dave Snelling’s proposal: I don’t
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 “core” set of
operations that is common to all 3 interface choices and we should certainly
write the spec that way. But don’t 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:
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,
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
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.
Argonne National Laboratory &
Tel: +1 630 252 4619. Web: www.ci.uchicago.edu.
Globus