Re: When is a Fault a Fault?

 Mark,
 my position about your examples is that I specify what happens 
when somebody sends me an evelope to 10.0.0.1:2345, exactly the 
same way that I specify what happens when somebody sends me an 
envelope to http[POST]://systinet.com/jacek. It's not like the 
sender's telling me how to understand and process the envelope, 
it's me telling the sender what it can expect when it sends me an 
envelope.
 And we have, too, got back to REST - I haven't (yet) fully 
accepted this fairly restricted view of HTTP. The (yet) part is 
because I can see how REST can be useful in its restrictedness. 
8-)
 Best regards,

                   Jacek Kopecky

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



On Mon, 4 Mar 2002, Mark Baker wrote:

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

Received on Tuesday, 5 March 2002 06:40:22 UTC