Proposal: abstract faults

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

Received on Thursday, 18 December 2003 04:25:53 UTC