Re: Fault name in WSDL1.1

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.


Here is an example:

Lets say that there is a BankServer.wsdl that is defined as follows:

<wsdl:definitions .... >
    <types>
       <xsd:schema targetNamespace="...">
           <xsd:element name="InvalidRequest">
               <xsd:complexType>
                  <xsd:sequence>
                     <xsd:element name="accountNumber" type="xsd:int"/>
                     <xsd:element name="amount"        type="xsd:int"/>
                  </xsd:sequence>
               </xsd:complexType>
           </xsd:element>
       </xsd:schema>
    </types>

    <message name="operException" >
        <part name="faultDetail" element="tns:InvalidRequest" />
    </message>

    <wsdl:portType .... > *

        <wsdl:operation name="withdraw" ...>

           <wsdl:input name="inp"   message="..."/>
           <wsdl:output name="outp" message="..."/>

           <wsdl:fault name="flt1"  message="tns:operException"/>
           <wsdl:fault name="flt2"  message="tns:operException"/>

        </wsdl:operation>

    </wsdl:portType >

    ...

</wsdl:definitions>


And there is a client using this wsdl and calls the "withdraw" operation.


If there is an exception that occurs within the "withdraw" operation
implementation, then the client CAN NOT differentiate if the fault with name
"flt1" has occured at the server side or the fault with name
"flt2" has occured at the server side. 

If there were different message types that were used to define the faults
(ie.
           <wsdl:fault name="flt1"  message="operException1"/>
           <wsdl:fault name="flt2"  message="operException2"/>
) 
then it would be possible to differentiate between these faults and use the
name (flt1 or flt2) in a catch clause to catch the proper fault in the client side.



So, per my understanding, the current state of affairs are as follows:

1) In the JAX-RPC spec, the WSDL1.1 to Java mapping treats faults defined within
an operation as equivalent if their message type is the same and then the mapping is done to one
Java class encapsulating the fault message type.

2) In the OASIS BPEL TC (in which I am an active member) we have the following issues logged
against fault related problems (with 180, 185 the most relevant to our discussion):

Fault handling Issue 133 Access to unnamed fault bodies  
Fault handling Issue 141 Standard Fault Format  
Fault handling Issue 180 Clarification of WSDL fault declarations and Reply in BPEL
Fault handling Issue 182 Adding body to BPEL faults 
Fault handling Issue 185 Clarify relationship between fault name and type of fault data
Fault handling Issue 190 BPEL Internal Faults

3) In Oracle's implementation we use in the client side:
a) the oper name b) the message type that is returned as fault
to find the fault name within WSDL and from there we can throw the proper faultName.
If there are two faults with the same message type as in the example above, then we 
raise a generic exception that does not have a fault name. So, a catch using
a faultName would not work.


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.


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.
    <wsdl:portType name="nmtoken">*
        <wsdl:documentation .... />?
        <wsdl:operation name="nmtoken">*
           <wsdl:documentation .... /> ?
           <wsdl:input name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:input>
           <wsdl:output name="nmtoken"? message="qname">?
               <wsdl:documentation .... /> ?
           </wsdl:output>
           <wsdl:fault name="nmtoken" message="qname"> *
               <wsdl:documentation .... /> ?
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:portType>
  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>