Re: Fault name in WSDL1.1

As far as I can follow this the net effect is +ve if we choose this 
proposal and the cost of implementing the proposal is minimal. Could 
you (Charlton) point to where the spec needs to be changed in order to 
accomodate the proposal? In particular where in needs to be brought 
into alignment elsewhere (i.e. functions and other places that might 
use exceptions).

Does anyone else feel like supporting this effort or are you all silent 
(except for Nick, Gary and Charlton)?

Cheers

Steve T

On 19 May 2005, at 04:20, Charlton Barreto wrote:

> Hi Nick, Gary:
>
> My responses are inline. I apologize for not being able to stay on 
> Tuesday's call for the entire duration to further discuss this.
>
> -Charlton.
>
> On 18/05/2005, at 17:01, Nickolas Kavantzas wrote:
>
>> Hi Gary,
>>  
>> Here is what I said yesterday in the WS Choreography WG conf-call:
>>  
>> The fault name defined within an request-response operation using 
>> WSDL 1.1
>> is not visible in an interoperable way to a client getting a fault 
>> response
>> as a return from an invocation to the request-response operation.
>
> [cbb] It may not be visible to a client, but I don't think this is the 
> point. In CDL we're dealing with interface-level logical definitions 
> as opposed to what a client is seeing on the wire. It's the executable 
> platforms which care what is on the wire, and we already have BPEL 
> which uses a fault name association similar to what Gary has proposed 
> to solve the same WSDL 1.1 problem. The fault name is clearly used at 
> the interface level and the WSDL 1.1 ambiguity has been enough of an 
> issue to have languages such as BPEL address it in such a fashion. 
>
> The CDL exception handling mechanism doesn't actually throw an 
> exception, but correlates the information type on the throwing element 
> to the field in hasExceptionOccurred. The mechanism allows for two 
> parts of a choreography to cause an exception on a node that has the 
> same fault informationType - the exception handler for that 
> informationType would not have any information on which part of the 
> choreography had raised the fault, forcing the handler to examine the 
> choreography state to determine this. Gary's proposal addresses this 
> by ensuring that the exception mechanism is not bound to particular 
> types. 
>
>>  Here is an example:
>>  
>> <snip>
>>
>> Concluding I would repeat what I said yesterday in the conf-call:
>>  
>> When I was designing the fault mechanism for WS-CDL, I chose a simple
>> design, where a fault is caught based on its type, that would not 
>> have to solve
>> all the issues listed above.
>>  
>> IMHO, the current WS-CDL fault mechanism works fine as is but if 
>> there is a
>> different proposal I would be happy to review it and comment on it.
>
> [cbb] We do have a different proposal which is the existing WS-CDL 
> fault mechanism as modified by Gary's proposal (Note that the 
> proposal's modifications have a small footprint on CDL). 
>
> To reiterate, Gary's proposal provides a way to uniquely identify WSDL 
> 1.1 faults, which cannot be done at present, and to avoid unnecessary 
> duplication of definitions when faults may actually be associated with 
> smaller set of real types, while enabling a consistent approach which 
> simplifies the CDL definition. As part of his proposal Gary suggests 
> we modify causeException to provide and exception name, rather than 
> using the information type - a minor change to the syntax with zero 
> effect on the semantics.
>
>>
>> Regards,
>>  
>> --
>> Nick
>>> ----- Original Message -----
>>> From: Gary Brown
>>> To: 'WS-Choreography List'
>>> Sent: Wednesday, May 18, 2005 8:13 AM
>>> Subject: Fault name in WSDL1.1
>>>
>>> Responding to Nick's comment on yesterday's conference call, 
>>> regarding the fault name attribute in WSDL1.1 not being used (i.e. 
>>> faults are only distinguished by their type), I would point to the 
>>> following two pieces of evidence that in my view contradict that 
>>> view, and therefore indicates that we need a means of 
>>> differentiating faults by name in WS-CDL:
>>>  
>>> 1) WSDL1.1 spec:
>>>  
>>>  The 'name' attribute on the fault element is mandatory.
>>>     *
>>>         ?
>>>         *
>>>             ?
>>>            ?
>>>                 ?
>>>
>>>            ?
>>>                 ?
>>>
>>>             *
>>>                 ?
>>>
>>>
>>>
>>>  
>>> 2) WS-BPEL:
>>>  
>>>  The following syntax for an invoke, with embedded fault handlers, 
>>> shows that the 'catch' elements have a mandatory 'faultName' 
>>> attribute, whereas the type attribute is optional.
>>> <invoke partnerLink="ncname" portType="qname"? operation="ncname"
>>>         inputVariable="ncname"? outputVariable="ncname"?
>>>         standard-attributes>
>>>        
>>> standard-elements
>>> <correlations>?
>>>      <correlation set="ncname" initiate="yes|no"?
>>>         pattern="in|out|out-in"/>+
>>> </correlations>
>>> <catch faultName="qname" faultVariable="ncname"?
>>>                          faultMessageType="qname"?>*
>>>         activity
>>> </catch>
>>> <catchAll>?
>>>         activity
>>> </catchAll>
>>> <compensationHandler>?
>>>       activity
>>> </compensationHandler>
>>> </invoke>

Received on Thursday, 19 May 2005 08:17:51 UTC