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 its 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=faulton 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 Im 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 youve 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 cant 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 & Canada).
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:

UNITED KINGDOM Toll Number: +44-20-7108-6316
USA Toll Free Number: 866-880-0098

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/>
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<http://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