Re: Fault name in WSDL1.1

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>
>