Re: Fault name in WSDL1.1

Hi Charlton & Gary,


Quoting from the WS-CDL WD spec:

1) The WS-CDL specification depends on the following specifications: 
XML 1.0 [XML], XML-Namespaces [XMLNS], XML-Schema 1.0 [XMLSchemaP1], 
[XMLSchemaP2] and XPointer [XPTRF]. Support for including and referencing 
service definitions given in WSDL 2.0 [WSDL20] is a normative part of 
the WS-CDL specification. In addition, support for including and referencing 
service definitions given in WSDL 1.1 as constrained by WS-I Basic Profile 
[Action: add references] is a normative part of the WS-CDL specification. 

2) A Choreography Description Language does not depend on a specific business 
process implementation language. Thus, it can be used to specify truly 
interoperable, collaborations between any type of party regardless of the 
supporting platform or programming model used by the implementation of the 
hosting environment. Each party, adhering to a Choreography Description 
Language collaboration representation, could be implemented using completely 
different mechanisms such as:
  -Applications, whose implementation is based on executable business 
   process languages [XLANG], [WSFL], [WSBPEL], [BPML], [XPDL] 
  -Applications, whose implementation is based on general purpose 
   programming languages [JLS], [C#S] 
  -Or human controlled software agents


Including again the example that I sent yesterday, 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. 


Based on this example I have few questions for you:

1) CDL needs to be able to "work" not only when BPEL is used as the endpoing 
executable platform but also when Java is used as the endpoing executable 
platform. 

Clearly, in the Java/WS space it is not possible to distinguise a fault name when 
there is fault type oveloading in the same operation, as I described in the example above.
 
So, if I had:
a) a Java/WS client and a Java/WS server  OR
b) a Java/WS client and a BPEL server  OR
c) a BPEL     client and a Java/WS server

I COULD NOT make these interactions conform to the CDL contract.


Do you agree?


2) I guess if both the client and the server are BPEL executable programs 
running on a BPEL engine supplied from one vendor this would work.

But, when both the client and the server are BPEL executable programs 
running on BPEL engines supplied from different vendors,
then there is not concrete intreop defined anywhere on how to encode a 
fault-name in the server side so that the client
can get it when the fault response arrives.

I am saying that we COULD NOT make these interactions conform 
to the CDL contract in these cases. 


Do you agree?




Thanks,

--
Nick



  ----- Original Message ----- 
  From: Charlton Barreto 
  To: Nickolas Kavantzas 
  Cc: Gary Brown ; 'WS-Choreography List' 
  Sent: Wednesday, May 18, 2005 8:20 PM
  Subject: 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>