Re: Issues 12 & 192

+1!

noah_mendelsohn@us.ibm.com wrote:

> Mark Baker writes:
> 
> 
>>>My proposal just *suggests* that it be a feature of 
>>>all application protocol bindings that the fault 
>>>mechanism of the underlying protocol be authoritative 
>>>in determining whether a SOAP fault be processed as a
>>>fault or not.
>>>
> 
> I think we need to be very clear on the relative responsibilities of the 
> binding vs. the soap node that it is supporting. 
> 
> * The responsibility of the binding is to deliver the Infoset [1].  That's 
> true whether the Infoset contains a fault or another envelope, and it's 
> true independent of whether the underlying protocol has its own notion of 
> error or status.
> 
> * Chapter 2.6 of framework [2] specifies the logic used by a SOAP node to 
> determine the processing of an envelope that has been received.  Unless I 
> am missing something, these rules apply equally to envelopes containing 
> faults.
> 
> * Bindings may signal to the local node failure to transmit or receive a 
> message.  The reasons for such failure and the means used to determine 
> whether such failures have occurred are binding specific.  An obvious 
> example might be loss of hardware connectivity, but we cannot prevent a 
> binding from signaling such failure based on the presence or absence of 
> status codes from the underlying protocol.   These signaled errors not the 
> same architectural construct as a SOAP fault; they are manifest as 
> transitions in the state machine for the binding.
> 
> * If the application protocol (e.g. HTTP) has a standard means of 
> signaling that the message being transmitted represents failure at the 
> application level, a binding to that protocol MAY (and in many cases 
> SHOULD) adopt such signal when transmitting a SOAP  fault message.  That's 
> why we use HTTP 4XX and 5XX for SOAP faults.
> 
> The second point above makes clear that no binding can make a 
> determination as to how a SOAP envelope is to be interpreted; the binding 
> can signal failure to receive the message, but (in the absence of 
> features) cannot change its interpretation.  Therefore, it would be 
> possible for an HTTP binding receiving a 4XX or 5XX to claim to the SOAP 
> node that in fact no message had been received.  If the message is 
> delivered, the SOAP node will use QNames in the envelope to determine 
> whether a fault has occurred, and if so why.  The binding can, if it 
> wishes, assure that it redundantly encodes sufficient information that it 
> knows unambiguously from checking its own status codes that the envelope 
> does indeed contain a SOAP fault.  Still, it is the envelope that is the 
> fundamental carrier of their information, and chapter 2 of the framework 
> document that specifies the logic for determining how the node processes 
> the fault.
> 
> In short, I disagree strongly with the suggestion that any binding would 
> be the principal determinant of whether a message carried a SOAP fault.  I 
> do think that a well constructed binding can ensure that there is never 
> disagreement between what's in the envelope and signals encoded in the 
> underlying protocol.  In such cases, the binding-specific signal may be 
> taken as a highly reliable hint.
> 
> [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#bindfw
> [2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#procsoapmsgs
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
>

Received on Wednesday, 27 March 2002 07:12:19 UTC