- From: Gary Brown <gary@pi4tech.com>
- Date: Fri, 20 May 2005 09:29:15 +0100
- To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>, "Charlton Barreto" <charlton_b@mac.com>
- Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
- Message-ID: <004901c55d16$03c39460$0200a8c0@GPB1>
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?
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.
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?
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 Friday, 20 May 2005 08:29:37 UTC