Re: Proposal: abstract faults

I think that I agree with all of this, except that I would prefer to see
infault and outfault get name=xs:qname, which might allow an interface
to use faults defined in another interface (including those defined in a
base interface from which it inherits).  Or have I not read deeply
enough here?  QName composed from definitions/@targetNamespace :
fault/@name.

Amy!
On Thu, 18 Dec 2003 09:25:48 +0000
paul.downey@bt.com wrote:

> 
> 
> In fulfilment of my Action point, here is a proposal to hoist faults
> into the interface alongside operations.
> 
> 
> Status Quo
> ----------
> 
> <definitions>
> 
>   <interface>
>     <operation>
>       <infault
>             name="xs:NCName"
>             messageReference="xs:NCName"?
>             message="xs:QName"?
>         <documentation />?
>       </infault>*
>       <outfault
>             name="xs:NCName"
>             messageReference="xs:NCName"?
>             message="xs:QName"?
>         <documentation />?
>       </outfault>*
>     </operation>*
>   </interface>
> 
>   <binding>
>     <operation>
>       <fault>
>         <wssoap:fault message="nmtoken"
>                 namespace="uri"?
>                 encodingStyle="uri"? >
>           ....
>         </wssoap:fault>*
>       </fault>*
>     </operation>*
>   </binding>*
> 
> </definitions>
> 
> 
> 
> Problems with Status Quo
> ------------------------
> 
> 1) how a binding/operation/fault is linked to an 
>    interface/operation/fault is unclear.
> 
> 2) it is not obvious how several different binding faults may map
>    to a single interface fault.
> 
> 3) duplication: many operations across the interface may return the 
>    same fault, but the details are defined under each operation,
>    possibly for infault and an outfault.
> 
> 4) there is no certain way to ensure that two operations return 
>    the "same" fault.
> 
> Proposal
> --------
> 
> 1) each fault is defined in the interface at the same level of
> operations.
> 
> 2) each fault is to be given a abstract name, unique within the
> interface.
> 
> 3) the fault details are defined under the interface/fault.
> 
> 4) each interface/operation identifies the interface faults returned 
>    using the abstract name.
> 
> 5) each fault in the binding is linked to an interface fault 
>    by the abstract name
> 
> 
> The following is an illustration of how this new structure could be
> represented in XML:
> 
> <definitions>
>   <interface>
>     <fault name="xs:NCName"
>             messageReference="xs:NCName"?
>             message="xs:QName"?
>         <documentation />?
>     </fault>*
> 
>     <operation>
>       <infault name="xs:NCName"/>*
>       <outfault name="xs:NCName"/>*
>     </operation>*
>   </interface>
> 
>   <binding>
>       <fault>
>         <wssoap:fault name="xs:NCName"
>             message="nmtoken"
>             namespace="uri"?
>             encodingStyle="uri"? />
>            ....
>         </wssoap:fault>*
>       </fault>*
> 
>     <operation>
>     </operation>*
>   </binding>*
> 
> </definitions>
> 
> 
> Conclusion
> ----------
> 
> Abstracting faults has the following benefits:
> 
> - inference: identifying a fault using an abstract name, explicitly.
> 
> - This supports a common way of working: an implementer may identify
> all
>   the exceptions and an action to be taken.
> 
> - a binding does not have to actually describe all of the interface
> faults
> 
> - several different <binding> section faults may map to a single
> interface
>   fault e.g. both 'HTTP 404' and 'SOAP fault code: notfound' may
>   result in the same interface fault 'missing' being generated.
> 
> 
> Thanks to Glen for his input!
> Paul
> 
> --
> Paul Sumner Downey
> Web Services Integration
> BT Exact
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 18 December 2003 12:13:32 UTC