Re: When is a Fault a Fault?

Hi Jacek,

I think we're arguing the same points that we argued in the
"response code wars" 8-)  I'll let my argument stand pat, except
to answer a couple of your questions;

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

Because application protocols frame SOAP messages, but transport
protocols don't.  That framing carries meaning.  You can ignore it
(tunnel), or use it (chameleon).

Think of it this way ...

If I send you this (and only this), say over TCP;

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
  <hrxml:resume>
   [resume goes here]
  </hrxml:resume>
 </env:Body>
</env:Envelope>

What do you know about what I want done with that resume?  Nothing.
You know that I sent you a resume, and nothing more.

With HTTP, I would send you these bytes;

POST /jacek HTTP/1.1
Host: systinet.com
Content-Type: application/soap+xml
Content-Length: 1234

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
 <env:Body>
  <hrxml:resume>
   [resume goes here]
  </hrxml:resume>
 </env:Body>
</env:Envelope>

In this case, the HTTP framing includes the intent with which I'm
sending you the resume; POST.  POST means something.  What it means is
actually quite wide open, but less wide open than the "any meaning"
that TCP provides.  POST doesn't mean PUT, for example.

>  > 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.

See above example.  In the chameleon view of SOAP, it takes on different
application semantics depending upon which protocol is in use on a hop
by hop basis.  Each hop is responsible for gatewaying between the
different application semantics.  For example, a SOAP intermediary that
accepts SOAP message in over HTTP, and send them out over SMTP has to
convert between the use of the POST and DATA methods, the same way a
non-SOAP intermediary would have to.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 4 March 2002 17:58:59 UTC