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 & 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/><http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu<http://www.ci.uchicago.edu/><http://www.ci.uchicago.edu/> & www.ci.anl.gov<http://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/><http://www.globus.org/> _______________________________________________________________ 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/>