Re: Fault name in WSDL1.1

Hi Nick,

I will see what I can do regarding the WSDL 1.1/2 examples. Not sure if they 
will be available before tomorrows call.

However, I think we are going round in circles regarding the other topic - 
my position is that the abstract interfaces are the important part of the 
interface definition, as other binds can always be defined in the future - 
even for use by a BPEL engine. You are concerned with the limitations of the 
current bindings, which I feel is not a limitation that should be 
transferred to CDL.

Regards
Gary

----- Original Message ----- 
From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
To: "Gary Brown" <gary@pi4tech.com>; "Charlton Barreto" <charlton_b@mac.com>
Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Sent: Monday, May 23, 2005 8:30 PM
Subject: Re: Fault name in WSDL1.1


> 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 20:04:46 UTC