For some reason this did not make it to
the OGSA-WG mailing list. In particular I think this points out the need
for a bit more clarity in the Basic Profile.
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
From:
Sent: Monday, August 21, 2006 3:44
PM
To: Maguire_Tom@emc.com;
foster@mcs.anl.gov; theimer@microsoft.com; ogsa-bes-wg@ggf.org; ogsa-wg@ggf.org
Subject: RE: [ogsa-bes-wg] Create
a revised BES spec draft that reflects the decisions of the July F2F mtg
As an aside I am not quite sure how
BaseFaults breaks tooling. The BaseFault element is carried as an
extensibility item in the s11:detail or s12:Detail elements. Isn’t
that what these items were designed for??
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
From:
owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Maguire_Tom@emc.com
Sent: Monday, August 21, 2006 3:30
PM
To: foster@mcs.anl.gov;
theimer@microsoft.com; ogsa-bes-wg@ggf.org; ogsa-wg@ggf.org
Subject: RE: [ogsa-bes-wg] Create
a revised BES spec draft that reflects the decisions of the July F2F mtg
Apologies
for the cross post but some of this discussion is relevant to the OGSA-WG
I would
agree that WS-BaseFaults are not required for BES. In
WS-ResourceProperties the use of BaseFaults is optional (SHOULD). The
OGSA Basic Profile for WSRF has mandatory (MUST) use of BaseFaults for
WS-Resources.
R0711 A MESSAGE for a fault from a WS-Resource MUST conform
to the structure specified in Web Services Base Faults Section 2, "Base
Fault Type."
As I
re-read this section it is not nearly clear enough about the scope of
‘WS-Resource’ness. I could interpret this requirement several
ways:
·
ALL
faults from a WS-Resource MUST be extensions of BaseFaults
·
ALL
faults from a WS-Resource based portType MUST be extensions of BaseFaults
·
ALL
faults from a WS-Resource base portType that match the semantics of existing
BaseFaults MUST use the BaseFault extension type that is defined for that
portType (basically what this does is turn the SHOULD in WSRF specs for faults
into MUSTs)
Clearly,
point 1 is a non-starter; no implementation will be able to guarantee that all
faults are extension of BaseFaults. Point 2 is also extremely difficult
as there are significant numbers of interceptors between the consumer and the
provider implementation all of which are likely to not fault with
WS-BaseFaults. Which leads us to point 3, I think this is the only reasonable
interpretation of the requirement; that faults that are defined in WSRF specs
MUST be used (as opposed to the SHOULD requirement in WSRF).
Perhaps
we should clarify this requirement in the Basic Profile.
w.r.t the
subject at hand I think that any consumer will need to deal both SOAP faults
and BaseFaults and as such I don’t see much of a need to fuss about the
fault definitions in BES. I do however, agree with Ian that there is
value in having a common base type for faults.
Tom
_______________________________________________
Tom Maguire
+1(845) 729-4806
From:
owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Ian Foster
Sent: Friday, August 18, 2006
11:27 AM
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:
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
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 &
Tel: +1 630 252 4619. Web: www.ci.uchicago.edu.
Globus
Computation Institute: www.ci.uchicago.edu &
www.ci.anl.gov
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org