RE: Proposal: abstract faults (amendment)

Proposal to hoist faults into the interface alongside operations
- 3rd attempt!


Changes from Original Proposal
------------------------------

Original Proposal (Paul + Glen!):
http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0046.html

Made fault name a qname (Amy):
http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0058.html

Moved fault name to /binding/fault (Sanjiva):
http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0068.html

Status Quo from latest Editor's copies (Tom):
http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0061.html
I haven't added Tom's further simplification to hoist the fault/code 
into a faultcode attribute on the soap binding. I like this 
simplification very much, but think we should discuss this separately 
as it is soap binding specific change and may confuse this discussion.

Moved @messageReference to interface/operation/infault
and interface/operation/outfault rather than on interface/fault
+ clarification of qname/ncname in fault references (Roberto):
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0062.html




Status Quo
----------

<definitions>

  <interface>
    <operation>
      <(in|out)fault name="ncname"
            messageReference="ncname"?
            message="qname"?
        <documentation />?
      </(in|out)fault>*
    </operation>*
  </interface>

  <binding>
    <operation>
      <(in|out)fault> name="ncname"
	    messageReferences="ncname">
        <wssoap:fault>*
          ....
        </wssoap:fault>*
      </(in|out)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 such as documentation are defined under
   each operation, possibly duplicated again 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 
   as operations.

2) each fault is to be given a abstract name, unique within the 
   interface.

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="ncname"
            message="qname"?>
        <documentation />?
     </fault>*

     <operation>
       <(in|out)fault name="qname"
                      messageReference="ncname"?
       </(in|out)fault>*
     </operation>*
   </interface>

   <binding>
     <operation>
       <(in|out)fault name="qname">
         <wssoap:fault>*
           ....
         </wssoap:fault>*
       </(in|out)fault>*
     </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.


Paul

--
Paul Sumner Downey
Web Services Integration
BT Exact

Received on Tuesday, 20 January 2004 05:11:28 UTC