Proposal: map HTTP fault codes to interface faults

in fulfilment of my Action Item from today's telcon, here is a short 
proposal for mapping HTTP binding faults to WSDL interface faults.


Proposed Syntax
---------------

we copy/re-use the SOAP fault component as follows:

  <binding>
    <http:binding methodDefault="xsd:string"? />

    <fault ref="xs:QName"
           http:codes="list of xs:int" >
      <documentation />?
    </fault>*

    <operation>
       .....
    </operation>
   </binding>

Whilst this doesn't provide wild-carding or ranges of fault codes, 
it does provide the ability for a list of individual fault codes to 
be grouped, described and targeted at an individual abstract fault.

I see this as being a low cost, but useful feature.


Rationale
---------

  - faults are a useful abstraction regardless of binding, it is 
    possible for a toolkit to present a fault code such as '403' as 
    something meaningful to an application.

  - describing HTTP faults at the abstract level is orthogonal 
    with our SOAP/HTTP binding.

  - this continues to encourage authors of WSDL documents to 
    describe faults at the abstract level for any binding, and not 
    just for SOAP bindings.

  - should we allow the HTTP binding be reused in another binding, 
    this would allow HTTP server generated errors such as BA failures,
    to be also translated into application level faults at the same
    level as the serialisation faults.

  - it is possible that an interface which relies upon faults is 
    presented as both a SOAP/HTTP and a HTTP binding or moved from
    SOAP/HTTP to another binding such as HTTP. Not being able to 
    generate the abstract level faults in HTTP may preclude this 
    migration.


-- 
Paul Sumner Downey
Web Services Integration
BT Exact

Received on Thursday, 27 May 2004 12:47:41 UTC