Hi;
My email from yesterday (see copy below) summarizes
where I believe things are. People should please speak up if they disagree
with my perception of things. J
Marvin.
Hi;
Apologies for replying to this email thread so late.
At the BES telecon call last week we decided to not require
WS-BaseFaults in the BES specification. As Tom Maguire pointed out in his
emails (below), there are issues with requiring that only WS-BF faults be
returned, including that one must be prepared to accept non WS-BF faults from
intermediaries in any case. I had made a statement in email and on
telecon calls that people I had queried at Microsoft had also raised various
concerns related to tooling. Included below is part of an email from a
colleague that sheds a bit more light on the issues that have people concerned.
-----------------------------
Here is my quick skim through:
Main goal of the spec is to introduce base
type for detail element of the fault
1) Not clear what value base fault type provides over SOAP 1.2 Fault ,
except for d)
a. Originator EPR:
i.
Originator
EPR is always known via Addressing facilities.
ii.
Mix in
of infrastructure details into application message parts: application may not
know what it’s EPR is.
b. ErrorCode:
i.
Limited
duplicate of SOAP1.2 fault codes and sub-codes. Uri associated with fault
should be represented by the wsa:Action
c. Description:
i.
duplicates
SOAP 1.2 Fault reason
d. FaultCause:
i.
this is
the only valuable piece IMHO – common representation of nested
exceptions.
ii.
This can
be provided by using open content model for SOAP1.2 Fault detail .
2) Child elements of Base fault are not namespace qualified –
this leads to known threats of having unqualified elements. Does not map to
DataContract.
3) Should not require name=’fault’ on the message –
there is no need for this and this blocks existing WSDL-generators.
4) Folks need to define Action uris for individual fault messages,
since Addressing is assumed to be used.
Our WSDLs generated by default for Faults
will not adhere to 2 and 3.
-----------------------------------------------
Points 2 and 3 are the key issues:
·
Point 2 implies a security issue
and I’m leery about introducing anything that even hints of a security
problem.
·
Point 2 also references the fact
that Microsoft (and others’) tooling is headed in the direction of
generating (and analyzing) contracts over web service protocols. Making a
web service protocol into a statically analyzable contract implies that you
either explicitly expose all the possible nested fault details – implying
that you’ve tightly coupled things and made them brittle with respect to
internal service behaviors that might change over time – or that you have
protocol content that can’t be determined until runtime.
·
Point 3 is a good example of WS-BF
breaking the tooling.
Marvin.
From: Ian Foster
[mailto:foster@mcs.anl.gov]
Sent: Wednesday, August 30, 2006
7:03 PM
To: Marvin Theimer;
Pulsipher_Darren@emc.com; ogsa-bes-wg@ggf.org
Subject: RE: [ogsa-bes-wg] OGSA
BES Meeting and WS-BaseFaults
Where do things stand with the WS-BF issue?
At 04:14 AM 8/24/2006 -0700, Marvin Theimer wrote:
Hi;
Apologies for not responding until now. I will try to cover the topic of
WS-BaseFaults and potential alternatives on today's BES telecon call. I
will also send out an email about the topic afterwards.
Marvin.
________________________________
From: owner-ogsa-bes-wg@ggf.org On Behalf Of Ian Foster
Sent: Wednesday, August 23, 2006 8:14 PM
To: Pulsipher_Darren@emc.com; ogsa-bes-wg@ggf.org
Subject: Re: [ogsa-bes-wg] OGSA BES Meeting
I can't make the call tomorrow. It seems important to address the WS-BaseFaults
issue. I've proposed that we organize a call with the Microsoft people who say
that they cannot use WS-BS, so that we can understand their concerns and also
have an opportunity for a WS-BS advocate to explain the benefits of WS-BS. I
haven't seen a response to that proposal.
At 05:23 AM 8/22/2006 -0400, Pulsipher_Darren@emc.com wrote:
When: Thursday, August 24, 2006 10:30 AM-11:30 AM (GMT-06:00) Central Time
(US &
Where: On Line
*~*~*~*~*~*~*~*~*~*
You are invited to join a meeting hosted by MR DARREN PULSIPHER. Meeting
details are listed below.
Instant Meeting Details:
-------------------------------
Aug. 24, 2006
11:30 am EDT
8:30 am PDT
If you are unable to join with the above link, please dial in using one of
the phone numbers below:
Participant Passcode: 3425861
Instant Net Conference Details:
-------------------------------
Meeting Number: SW124357
Meeting Passcode: GGF
Meeting Host:
MR DARREN PULSIPHER
Join Instructions for Instant Net Conference:
1. Join the meeting now:
http://www.mymeetings.com/emc/nc/join.php?i=SW124357&p=GGF&t=c
2. Enter the required fields.
3. Indicate that you have read the Privacy Policy.
4. Click on Proceed.
EMC˛
Darren Pulsipher
Director of Engineering
Grid Business Unit
501-442-9074
Email: Pulsipher_Darren@emc.com <mailto:Pulsipher_Darren@emc.com>
_______________________________________________________________
Ian Foster -- Weblog: http://ianfoster.typepad.com<http://ianfoster.typepad.com/>
Computation Institute: www.ci.uchicago.edu<http://www.ci.uchicago.edu/>
& www.ci.anl.gov<http://www.ci.anl.gov/>
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org<http://www.globus.org/>
Computation Institute: www.ci.uchicago.edu &
www.ci.anl.gov
Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org