- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Tue, 3 May 2005 14:54:08 -0700
- To: "Charlton Barreto" <charlton_b@mac.com>, <public-ws-chor@w3.org>
Forwarding to the public list the private email thread that occured between
Charlton, Gary and myself
regarding this issue.
--
Nick
----- Original Message -----
From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
To: "Gary Brown" <gary@enigmatec.net>; "Charlton Barreto"
<charlton_b@mac.com>
Sent: Monday, April 11, 2005 9:18 AM
Subject: Re: Fault Handling
I completely disagree about the 'fault' type on WSDL 2.0 being
implementation detail.
It is actually desinged for re-usability at the abstract level.
I am pasting in below (again) the link I put in my initial email I sent you:
> >> Look at the info below for WSDL 2.0:
> >>
> >> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> >> primer.html#more-interfaces-faults
> >>
> >>
> >> 4.2.1.2 Reusable Faults
> >>
> >> The fault element can be used to declare faults that may occur during
> >> execution of operations of an interface. Declaring faults directly
> >> under interface and referencing these faults in operations where they
> >> apply allow one to easily indicate that some faults can occur in
> >> multiple operations.
> >>
> >> The fault element has a required name attribute. Within a same
> >> namespace, all faults must be named uniquely. The optional element
> >> attribute can be used to indicate the content or playload of the fault
> >> message. Its value should be the QName of the XML schema global
> >> element declaration which defines the fault message. Please note when
> >> other type systems are used to define a fault message, additional
> >> attributes may need to be defined via WSDL's attribute extension
> >> mechanism to allow associating such a message definition with the
> >> fault.
> >>
> >> Here is an example of reusing faults.
> >>
> >> Editorial note: dbooth
> >>
> >>
> >> To do: Update this example
> >>
> >> Example 4-2. Declaring interface faults
> >> <description
> >> targetNamespace= "http://greath.example.com/2004/wsdl/resSvc"
> >> xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"
> >> xmlns = "http://www.w3.org/2004/08/wsdl"
> >> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> >>
> >> <documentation>
> >> Description: The definition of the reservation Web service of
> >> GreatH hotel.
> >> Author: Joe Somebody
> >> Date: 05/17/2004
> >> </documentation>
> >>
> >> <types>
> >>
> >> <xs:import
> >> namespace="http://greath.example.com/2004/schemas/resSvc"
> >> schemaLocation=
> >> "http://greath.example.com/2004/schemas/resSvc.xsd"/>
> >>
> >> </types>
> >>
> >> < interface name = "reservation" >
> >>
> >> <fault name = "invalidCreditCardFault"
> >> element = "ghns:invalidCreditCardError">
> >> <documentation>
> >> falut declaration for invalid credit card
> >> information.
> >> </documentation>
> >>
> >> </fault>
> >>
> >> <fault name = "invalidDataFault"
> >> element = "ghns:invalidDataError">
> >> <documentation>
> >> falut declaration for invalid data.
> >> </documentation>
> >>
> >> </fault>
----- Original Message -----
From: "Gary Brown" <gary@enigmatec.net>
To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>; "Charlton Barreto"
<charlton_b@mac.com>
Sent: Sunday, April 10, 2005 3:42 AM
Subject: Re: Fault Handling
> Hi
>
> Sorry, have been on holiday. However, I would still prefer an email
> exchange.
>
> Nick can I have your thoughts on my last email. Basically if we look at
the
> abstract model of faults in WSDL1.1 and 2.0, then it defines an operation
as
> having a list of named faults each with a type. The fact that the concrete
> representation of WSDL2.0 wraps this name and type into a further type,
> which is associated with the operation, is a implementation detail.
>
> We have the opportunity to define CDL to use this abstract model, rather
> than relying on the concrete implementation approach used by a particular
> version of the WSDL spec. I would like to understand your reasons for
being
> against this approach.
>
> Regards
> Gary
>
> ----- Original Message -----
> From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> To: "Charlton Barreto" <charlton_b@mac.com>
> Cc: "Gary Brown" <gary@enigmatec.net>
> Sent: Monday, April 04, 2005 7:51 PM
> Subject: Re: Fault Handling
>
>
> > fine by me either days.
> >
> > --
> > Nick
> >
> > ----- Original Message -----
> > From: "Charlton Barreto" <charlton_b@mac.com>
> > To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> > Cc: "Gary Brown" <gary@enigmatec.net>
> > Sent: Monday, April 04, 2005 10:41 AM
> > Subject: Re: Fault Handling
> >
> >
> >> Hi Nick/Gary,
> >>
> >> As I've seen no response I take it that this won't happen today. Would
> >> it work to still do this today, or to do this at 10.00 PST Tuesday
> >> (prior to our ws-chor conf call)?
> >>
> >> -Charlton.
> >>
> >> On 31/03/2005, at 11:28, Nickolas Kavantzas wrote:
> >>
> >> > Gary/Charlton,
> >> >
> >> > lets try to have a call next Monday, and we can record the minutes
> >> > from the
> >> > meeting so we can have a trace. How about Monday @10am PST?
> >> >
> >> > --
> >> > Nick
> >> >
> >> > ----- Original Message -----
> >> > From: "Gary Brown" <gary@enigmatec.net>
> >> > To: "Charlton Barreto" <charlton_b@mac.com>; "Nickolas Kavantzas"
> >> > <nickolas.kavantzas@oracle.com>
> >> > Sent: Thursday, March 31, 2005 12:05 AM
> >> > Subject: Re: Fault Handling
> >> >
> >> >
> >> >> Sorry Nick and Charlton, I am off on holiday this evening so cannot
> >> >> do.
> >> >>
> >> >> However, might be good idea for you two to chat further in advance
of
> >> >> next
> >> >> weeks conf call. Personally I would prefer the chat to remain on
> >> >> email as
> >> > it
> >> >> provides a good audit trail for the discussion.
> >> >>
> >> >> BTW - Nick, I know one of your issues with the proposal was how it
> >> >> related
> >> >> to the exception handling mechanism - if we don't have the 'fault'
> >> >> type
> >> > (as
> >> >> it WSDL2) as the informationType, then how would the exception
> >> >> handling
> >> >> mechanism be able to differentiate which fault has occurred.
> >> >>
> >> >> Referring back to the discussion in my previous email, this would
> >> >> seem to
> >> > be
> >> >> one place where having the five different information types would be
> >> > useful.
> >> >>
> >> >> However, the exception handling mechanism is not actually throwing
any
> >> >> information - it is just doing a correlation between the
> >> >> informationType
> >> >> field on the throwing element, with the field inside the
> >> >> hasExceptionOccurred function - i.e. it is matching labels, nothing
> >> >> more.
> >> >>
> >> >> With the current exception handling mechanism, it would be possible
> >> >> for
> >> > two
> >> >> parts of a choreography to cause exception on a node that has the
same
> >> > fault
> >> >> informationType, and in this situation, the exception handler for
that
> >> > fault
> >> >> informationType would not know which part of the choreography had
> >> >> caused
> >> > the
> >> >> problem - and therefore it would have to examine the choreographies
> >> >> state
> >> > to
> >> >> determine what had gone wrong.
> >> >>
> >> >> Therefore I would suggest that rather than use the informationType,
we
> >> >> actually change the causeException to provide an exception name,
e.g.
> >> >>
> >> >> <exchange ...>
> >> >> <receive ...... causeException="myException" />
> >> >> </exchange>
> >> >>
> >> >> which would then be caught by an associated exception block,
> >> >>
> >> >> <exceptionBlock>
> >> >> <workunit guard="cdl:hasExceptionOccurred('myException')" />
> >> >> </exceptionBlock>
> >> >>
> >> >> There is very little change in the syntax (and no change in the
> >> >> semantics)
> >> >> and it frees the exception mechanism from being tied to any
particular
> >> > type.
> >> >>
> >> >> Regards
> >> >> Gary
> >> >>
> >> >> ----- Original Message -----
> >> >> From: "Charlton Barreto" <charlton_b@mac.com>
> >> >> To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> >> >> Cc: "Gary Brown" <gary@enigmatec.net>
> >> >> Sent: Wednesday, March 30, 2005 10:26 PM
> >> >> Subject: Re: Fault Handling
> >> >>
> >> >>
> >> >>> Hi Nick,
> >> >>>
> >> >>> I'm available after 10.00 PST at 650-303-4682.
> >> >>>
> >> >>> Cheers,
> >> >>>
> >> >>> -Charlton.
> >> >>>
> >> >>> On 30/03/2005, at 13:18, Nickolas Kavantzas wrote:
> >> >>>
> >> >>>> Maybe we can discuss this on the phone. How about tomorrow,
Thursday
> >> > 11am
> >> >>>> PST? I can conf-call you in?
> >> >>>> What are the numbers I can reach you?
> >> >>>>
> >> >>>> --
> >> >>>> Nick
> >> >>>>
> >> >>>> ----- Original Message -----
> >> >>>> From: "Gary Brown" <gary@enigmatec.net>
> >> >>>> To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>;
"Charlton
> >> >>>> Barreto"
> >> >>>> <charlton_b@mac.com>
> >> >>>> Sent: Wednesday, March 30, 2005 12:51 AM
> >> >>>> Subject: Re: Fault Handling
> >> >>>>
> >> >>>>
> >> >>>>> Nick,
> >> >>>>>
> >> >>>>> I am not arguing that in WSDL2 it would be possible to uniquely
> >> > identify
> >> >>>> the
> >> >>>>> 'fault name' using the information type. However, this is not
> >> >>>>> possible
> >> >>>>> in
> >> >>>>> WSDL1.1 - and therefore we have a consistency problem across the
> >> >>>>> versions
> >> >>>> of
> >> >>>>> WSDL, which ideally we do not want to expose to the end user.
> >> >>>>>
> >> >>>>> However, imagine that you had a WSDL2 interface that had five
> >> >>>>> faults
> >> >>>>> defined, each was of underlying type xs:string. In CDL, you would
> >> >>>>> need
> >> >>>>> to
> >> >>>>> define 5 informationTypes to represent each separate fault using
> >> >>>>> the
> >> >>>>> reference to the fault element within the interface.
> >> >>>>>
> >> >>>>> What I am suggesting is that possibly a better way to represent
> >> >>>>> this
> >> > in
> >> >>>> CDL
> >> >>>>> is to separate the 'name' of the fault from its underlying type,
as
> >> > the
> >> >>>>> underlying type may be re-usable, and therefore avoid unnecessary
> >> >>>>> duplication of definitions.
> >> >>>>>
> >> >>>>> In the example above, my approach would have a single
> >> >>>>> informationType
> >> >>>>> for
> >> >>>>> xs:string, and each exchange element would name the fault and
> >> > reference
> >> >>>> the
> >> >>>>> single underlying information type. Using these two pieces of
> >> >>>>> information,
> >> >>>>> it is possible to infer the 'fault' being referenced in WSDL1.1
and
> >> >>>>> WSDL2,
> >> >>>>> therefore you have a consistent approach that simplifies a CDL
> >> >>>>> definition
> >> >>>>> without adding any constraints on the user.
> >> >>>>>
> >> >>>>> Regards
> >> >>>>> Gary
> >> >>>>>
> >> >>>>>
> >> >>>>> ----- Original Message -----
> >> >>>>> From: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> >> >>>>> To: "Charlton Barreto" <charlton_b@mac.com>
> >> >>>>> Cc: "Gary Brown" <gary@enigmatec.net>
> >> >>>>> Sent: Wednesday, March 30, 2005 2:19 AM
> >> >>>>> Subject: Re: Fault Handling
> >> >>>>>
> >> >>>>>
> >> >>>>>> how can you do re-usability of fault as in WSDL 2.0 within an
intf
> >> > per
> >> >>>>>> Gary's proposal?
> >> >>>>>>
> >> >>>>>> ----- Original Message -----
> >> >>>>>> From: "Charlton Barreto" <charlton_b@mac.com>
> >> >>>>>> To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>
> >> >>>>>> Cc: "Gary Brown" <gary@enigmatec.net>
> >> >>>>>> Sent: Tuesday, March 29, 2005 3:24 PM
> >> >>>>>> Subject: Re: Fault Handling
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Yes, but I believe thew crux of Gary's proposal and arguments
> >> > circulate
> >> >>>>>> around scoping vs. pure unique identification. We can use
> >> >>>>>> faultName
> >> > to
> >> >>>>>> identify the fault per its interface/operation scoping vs. the
> >> >>>>>> package-level scoping of an information type. This is especially
> >> >>>>>> important since WSDL faultNames are scoped to the
> >> >>>>>> interface/operation
> >> >>>>>> rather than globally, while fault types may be globally defined.
> >> >>>>>> If
> >> > we
> >> >>>>>> thus use InformationType to uniquely identify faults we are
> >> >>>>>> creating
> >> >>>>>> one per faultName rather than fault type, where we may not need
> >> >>>>>> to do
> >> >>>>>> this (the fault type may be globally defined), encountering the
> >> >>>>>> duplication Gary mentions.
> >> >>>>>>
> >> >>>>>> On 29/03/2005, at 14:19, Nickolas Kavantzas wrote:
> >> >>>>>>
> >> >>>>>>> Well, WSDL 1.1 did it the way you describe (but with no
> >> >>>>>>> constrain)
> >> >>>>>>> and WSDL 2.0 did it the way CDL has it now.
> >> >>>>>>>
> >> >>>>>>> I think that what we have now is really consistent with WSDL
2.0
> >> >>>>>>> and
> >> >>>>>>> works great
> >> >>>>>>> for WSDL 1.1 by adding the missing uniqueness constraint.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Look at the info below for WSDL 2.0:
> >> >>>>>>>
> >> >>>>>>> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> >> >>>>>>> primer.html#more-interfaces-faults
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> 4.2.1.2 Reusable Faults
> >> >>>>>>>
> >> >>>>>>> The fault element can be used to declare faults that may occur
> >> > during
> >> >>>>>>> execution of operations of an interface. Declaring faults
> >> >>>>>>> directly
> >> >>>>>>> under interface and referencing these faults in operations
where
> >> > they
> >> >>>>>>> apply allow one to easily indicate that some faults can occur
in
> >> >>>>>>> multiple operations.
> >> >>>>>>>
> >> >>>>>>> The fault element has a required name attribute. Within a same
> >> >>>>>>> namespace, all faults must be named uniquely. The optional
> >> >>>>>>> element
> >> >>>>>>> attribute can be used to indicate the content or playload of
the
> >> > fault
> >> >>>>>>> message. Its value should be the QName of the XML schema global
> >> >>>>>>> element declaration which defines the fault message. Please
note
> >> > when
> >> >>>>>>> other type systems are used to define a fault message,
additional
> >> >>>>>>> attributes may need to be defined via WSDL's attribute
extension
> >> >>>>>>> mechanism to allow associating such a message definition with
the
> >> >>>>>>> fault.
> >> >>>>>>>
> >> >>>>>>> Here is an example of reusing faults.
> >> >>>>>>>
> >> >>>>>>> Editorial note: dbooth
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> To do: Update this example
> >> >>>>>>>
> >> >>>>>>> Example 4-2. Declaring interface faults
> >> >>>>>>> <description
> >> >>>>>>> targetNamespace=
> >> > "http://greath.example.com/2004/wsdl/resSvc"
> >> >>>>>>> xmlns:ghns =
> >> >>>>>>> "http://greath.example.com/2004/schemas/resSvc"
> >> >>>>>>> xmlns = "http://www.w3.org/2004/08/wsdl"
> >> >>>>>>> xmlns:xs="http://www.w3.org/2001/XMLSchema">
> >> >>>>>>>
> >> >>>>>>> <documentation>
> >> >>>>>>> Description: The definition of the reservation Web
> >> >>>>>>> service
> >> > of
> >> >>>>>>> GreatH hotel.
> >> >>>>>>> Author: Joe Somebody
> >> >>>>>>> Date: 05/17/2004
> >> >>>>>>> </documentation>
> >> >>>>>>>
> >> >>>>>>> <types>
> >> >>>>>>>
> >> >>>>>>> <xs:import
> >> >>>>>>> namespace="http://greath.example.com/2004/schemas/resSvc"
> >> >>>>>>> schemaLocation=
> >> >>>>>>> "http://greath.example.com/2004/schemas/resSvc.xsd"/>
> >> >>>>>>>
> >> >>>>>>> </types>
> >> >>>>>>>
> >> >>>>>>> < interface name = "reservation" >
> >> >>>>>>>
> >> >>>>>>> <fault name = "invalidCreditCardFault"
> >> >>>>>>> element =
"ghns:invalidCreditCardError">
> >> >>>>>>> <documentation>
> >> >>>>>>> falut declaration for invalid credit
card
> >> >>>>>>> information.
> >> >>>>>>> </documentation>
> >> >>>>>>>
> >> >>>>>>> </fault>
> >> >>>>>>>
> >> >>>>>>> <fault name = "invalidDataFault"
> >> >>>>>>> element = "ghns:invalidDataError">
> >> >>>>>>> <documentation>
> >> >>>>>>> falut declaration for invalid data.
> >> >>>>>>> </documentation>
> >> >>>>>>>
> >> >>>>>>> </fault>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> ----- Original Message -----
> >> >>>>>>> From: Gary Brown
> >> >>>>>>> To: Nickolas Kavantzas ; Charlton Barreto
> >> >>>>>>> Sent: Tuesday, March 29, 2005 1:51 PM
> >> >>>>>>> Subject: Fault Handling
> >> >>>>>>>
> >> >>>>>>> Hi,
> >> >>>>>>>
> >> >>>>>>> I think using the informationType mechanism to identify a
fault,
> >> > which
> >> >>>>>>> is scoped to a particular operation, is wrong.
> >> >>>>>>>
> >> >>>>>>> This could mean the definition of an excessive number of
> >> >>>>>>> information
> >> >>>>>>> types, just to define a potentially wide range of faults, where
> >> >>>>>>> they
> >> >>>>>>> may actually be all associated with a small set of real types.
> >> >>>>>>>
> >> >>>>>>> If we add a 'name' attribute to the fault exchange, then it
means
> >> > that
> >> >>>>>>> the informationType field can be used for its actual purpose,
to
> >> >>>>>>> identify the type of the information carried in the message
> >> >>>>>>> payload.
> >> >>>>>>>
> >> >>>>>>> Scoping the identification of the fault to the interaction
> >> > (operation)
> >> >>>>>>> to which it is associated seems a simplier design.
> >> >>>>>>>
> >> >>>>>>> Regards
> >> >>>>>>> Gary
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
>
----- Original Message -----
From: "Charlton Barreto" <charlton_b@mac.com>
To: <public-ws-chor@w3.org>
Sent: Tuesday, May 03, 2005 12:19 PM
Subject: Discussion on issue 1008
>
> With respect to issue 1008, I support Gary's proposal and feel that we
should pursue it. By separating the fault name from its underlying type, as
this type may be reusable, we will:
>
> 1) Uniquely identify WSDL 1.1 faults - at present one cannot uniquely
identify a WSDL 1.1 'fault name' using the information type.
>
> 2) Avoid unnecessary duplication of definitions - at present information
type is used to identify a fault; as a fault is scoped to a particular
operation, we can end up defining an excessive number of information types
for a wide range of faults, when these faults may actually be all associated
with a small set of real types.
>
> Using fault name and information type, it is possible to infer the 'fault'
being referenced in either WSDL 1.1 and WSDL 2.0, providing a consistent
approach which simplifies the CDL definition, while not adding any
constraints on the user.
>
> This isn't inconsistent with the CDL exception handling mechanism, as it
doesn't actually 'throw' an exception; instead it simply correlating
information type on the throwing element to the field in
hasExceptionOccurred. As it exists, the CDL exception handling mechanism
allows for two parts of a choreography to cause exception on a node that has
the same fault informationType. In this situation, the exception handler for
that informationType would not have information on which part of the
choreography had caused the problem, forcing it to examine the
choreographies state to determine what had gone wrong. 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. This achieves the objective of having the
exception mechanism not being bound to particular types.
>
> Let's discuss this at the next conference call (2005-May-10) towards
resolving the issue.
>
>
>
Received on Tuesday, 3 May 2005 21:54:21 UTC