Re: When is a Fault a Fault?

 Mark,
 you seem to be distinguishing between so called "transport 
protocol bindings" and "application protocol bindings". As far as 
I know, SOAP only knows about the first term. The only part of 
our spec where the distinction might be sort-of implied is the 
section 6.3 - Binding to Application-Specific Protocols (again, 
AFAIK). I don't think that we want to add this distinction.

 I see a few options here:
 1) we could create the distinction and explicitly say what 
changes for "application protocol bindings" (compared to 
"transport protocol bindings"),
 2) we could choose to always bind to "application protocols",
effectively saying that we will always obey every semantic of the
underlying protocol (lots in HTTP, few in TCP), which might
change some things above the protocol binding framework (like
knowing which messages are faults),
 3) we could choose to always bind to "transport protocols" - 
tunneling view.

 IMO, option 1 feels arbitrary and controversial (are there 
additional categories? where's the line?); option 2 feels like 
"ok, so what we do depends on which binding was used to get us 
the message"; option 3 is my favourite, obviously.

 My view is that of starting with SOAP - what we want to 
accomplish with SOAP (sending XML messages with some structure) 
and what we need to do it. Obeying HTTP's semantics is not what 
we need. Sure it's something we'd better get close to (as a part 
of W3C), but no need to go too close when it starts being 
incomfortable. The incomfort shows that there is some clash here, 
in this particular case we both do and don't want to be close to 
HTTP (obeying its semantics while being transport independent).

 Additional point: the whole SOAP ('cept for the transport 
binding framework, obviously) only deals with the infoset. Why 
should there be anything outside it?

 Please see additional reactions to selected points below.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



 > >  The difference in your HTTP 404 and a SOAP Fault, as I perceive
 > > it, is the fact that there is no prescribed content for HTTP
 > > errors whereas there is a specific structure of the content for
 > > SOAP Faults which can be checked for.
 > 
 > That's true, but perhaps not the problem you appear to be suggesting
 > (if I understand your reasoning for bringing this up).  HTTP already
 > includes a means for signifying whether "content" should be
 > considered content, or a failure.  It is a Good Thing that it
 > doesn't require any format of failures, since that allows us to
 > say, in Apache .conf-speak;
 > 
 >   ErrorDocument /404.html

I understand this very much. My view is that in the successful 
cases (2xx) the content is the desired data. In unsuccessful 
cases (4xx, 5xx) there is no content (because the error codes 
should be enough) but there may be some "user-friendly" stuff 
there - nice for presentation, not at all necessary for 
applications without human-oriented interface.

 > > Moreover, we expect that
 > > there will be bindings to one-way protocols and request/response
 > > patterns built on top of these bindings. In such cases (say email
 > > binding) it is inappropriate to signal that the transmitted
 > > message is in fact a fault message since the information is
 > > already in the message itself.
 > 
 > I disagree.  We are talking about two pieces of information here, not
 > one.  There's the information about the type of the content (a SOAP
 > fault), and then there's the information about whether it should be
 > processed as a fault or not.

I maintain that saying "this fault is not fault, it's application 
data" should be handled by the application, for example by 
wrapping the actual fault in a Body's child element.

 > >  What can we expect from transport bindings? They must be able to
 > > actually (try to) transfer the infoset and that's it.
 > 
 > They must try to transfer the infoset with the transfer semantics
 > from the underlying protocol.  That means respecting the method
 > semantics, and also the failure semantics.

Why? What do your additions to my statement give SOAP? Agreed, 
the world will be much cleaner and simpler and more maintainable 
when everybody agrees on semantics of protocols and keeps them. 
The agreement part is important here. But it should not be the 
concern of SOAP how Jacek binds it to FooProtocol.

 > > We'd have to create a format for the "outer" data, for example
 > > sending a MIME content with one necessary header - the faultHint.
 > >  Using the non-tunelling view in this case leads us to a 
 > > potential inconsistency (200 OK and a fault message), which IMHO 
 > > is a reason _for_ the tunelling use of HTTP or disallowing other 
 > > protocols, if we want to be consistent.
 > 
 > But that's not an inconsistency.  Like I said in my example, what if I
 > wanted a debugging interface on my components such that I could ask
 > "give me the last fault you sent".  In the tunnelled view of SOAP,
 > there's no way to know whether what you're getting is the fault
 > you're asking for, or a fault generated because of your question.

See above - wrap the fault. Or transform it. Or base64 the whole
previous fault message. You seem to want to send it as you sent
it before, without changes to the infoset, but again - not quite
as you sent it before.

Received on Monday, 4 March 2002 17:17:47 UTC