W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2005

Re: Fault name in WSDL1.1

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Mon, 23 May 2005 12:30:28 -0700
Message-ID: <3e2b01c55fcd$e13e2d50$538e1990@us.oracle.com>
To: "Gary Brown" <gary@pi4tech.com>, "Charlton Barreto" <charlton_b@mac.com>
Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>

Hi Gary,

See below for my comments.



Regards,

--
Nick
----- Original Message ----- 
From: Gary Brown
To: Nickolas Kavantzas ; Charlton Barreto
Cc: 'WS-Choreography List'
Sent: Friday, May 20, 2005 1:29 AM
Subject: Re: Fault name in WSDL1.1


Hi Nick,

Firstly, before addressing your questions:

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

If you had two services that implemented exactly the same functional
interface, where the operations included faults, but one used WSDL1.1 and
the other WSDL2, in the current CDL it would require the interactions (and
information types) to be modified to deal with these different cases. To
meet the statement above, I don't think this is a very good situation.
Taking the approach that Charlton and I are backing, would mean that the CDL
would be completely independent of 'implementation' details, as it would be
using the abstract interface description that is consistent across WSDL1.1
and WSDL2.

Do you agree?

<NK>
I would like to see how this would work per your proposal for both WSDL 1.1
and WSDL 2.0.

Since, in your proposal you have removed any reference to WSDL 1.1/2.0, I am
not sure what is
the mapping of faultName from CDL to WSDL 1.1/2.0 faults.

Please clarify.

</NK>


Now on to your questions:

1) In order to answer this question, let me ask you one. If as a software
engineer, you are given an interface to implement against. Would you
de-compile the implementation code, understand how it works, and then base
your usage of the interface on the implementation details?

I hope the answer to this question is that you would not! A good software
engineer implements based on the interface contract, as this enables the
implementation of that interface to evolve without impacting the clients of
the interface, as they have a common contract to adhere to.

The arguments that you have consistently raised on this topic relates to the
implementation details behind the WSDL interface. What Charlton and I are
doing is focusing on the interface.

It does not matter what bindings are currently out there, only what is
possible given the interface definition language.

<NK>
WSDL 1.1/2.0 are the interface definition languages that CDL depends on.

And both versions of WSDL include not only an abstract part (that defines
the interface/oper/...) but also a binding part.
The binding part describes concrete message format(s) and transmission
protocol(s) which can be used to access an endpoint.

It is the combination of the both the WSDL 1.1/2.0 abstract and binding
parts that need to be defined properly, so that "interoperability" is
guaranteed between applications developed for different platforms/languages.

Otherwise, if one looks only at the abstract part, then this would be just a
"theoretical" exercise, since apps would not be able to
exchange messages that they would understand.


So, what I am/was saying is that since there are issues with the
abstract/binding part of WSDL regarding faults,
we (in CDL land) should depend on the WSDL fault features that do work.

</NK>


2) Again I would say that you are focusing on implementation rather than
interface. Can you guarantee that BPEL engines of the future won't support
other bindings than SOAP, and therefore that the faultname may get carried?


<NK>
Please look above for my WSDL abstract/binding point.

Also, lets remember that BPEL is one of the different types of endpoint
implementations that need to conform to
a CDL collaboration contract and a WSDL service description contract (that
includes both the abstract and the binding parts).

As we've discussed before in the Choreography WG another important endpoint
implementation would be Java/WS.
</NK>





Regards
Gary
----- Original Message ----- 
From: Nickolas Kavantzas
To: Charlton Barreto ; Gary Brown
Cc: 'WS-Choreography List'
Sent: Thursday, May 19, 2005 8:11 PM
Subject: 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>
Received on Monday, 23 May 2005 19:30:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:34 GMT