Re: wsa:FaultTo unusable for SOAP mustUnderstand faults

+1

-Anish
--

Hugo Haas wrote:
> * Rogers, Tony <Tony.Rogers@ca.com> [2005-06-09 16:30+1000]
> 
>>Hmm - yes, it's not immediately obvious, and some might claim it's counter-intuitive (I don't).
>> 
>>I'd suggest that we'll want to include in the spec something in the way of a table of what faults must / can be reported in what way to aid understanding. A table with a vertical axis showing type of fault (eg: bad URL, bad headers, bad data in the request, etc), and a horizontal axis showing perhaps method, back channel, faultTo address, with an indicator of which can be used for what. A bad URL fault will probably come back as a fault from the method that you tried to call to send the request. Bad headers will probably come back on the back channel (if there is one). Bad data in the request (the -1 to a real square root function) would come back to the faultTo. And so on.
>> 
>>Would that suit what you were suggesting, Hugo? Or is that more than you expected?
> 
> 
> Actually, I was thinking of something simpler at this point, i.e. add
> in the SOAP binding in section 2.3:
> 
>   http://www.w3.org/2005/03/addressing/feature/FaultEndpoint
> 
>     Corresponds to the abstract [fault endpoint] property.
> 
>     [ The following text is the proposed addition: ]
> 
>     Note: This binding of [fault destination] to SOAP does not
>     influence the dissemination of SOAP mustUnderstand faults. A SOAP
>     processor receiving a message containing WS-Addressing SOAP header
>     blocks and faulting with a SOAP mustUnderstand fault MUST not
>     process any WS-Addressing SOAP headers.
> 
> And in section 3.2 Description (right now, we don't use the word
> "process" despite the SOAP processing model being all about
> processing):
> 
>     When receiving a message, the processing of the WS-Addressing
>     headers by the receiving SOAP node is as follows: the abstract
>     properties are populated from their corresponding element
>     information items in the message.
> 
> Cheers,
> 
> Hugo
>

Received on Monday, 13 June 2005 18:08:02 UTC