Getting no REST

Hi Stuart,

> Hi Mark,
> 
> [I know this looks a bit long, please bear with it up to the end of the
> second of the two following paragraphs before filing in the usual place -
> Thanks]
> 
> So... I think we are yet again running up against the tensions between the
> 'tunneling' and 'chameleon' views of SOAP. I'm not sure that I believe that
> these two views can be accomodated within a single binding... but I have a
> thought with respect to the 'chameleon' view applied in the context of HTTP
> - which I'll try out here and see if I get buried under a tonne of rubble
> ;-)
> 
> I think that it would be possible to regard a SOAP message simply as a
> content-type (application/soap+xml) along with a model for processing that
> content-type (the SOAP part 1 section 2 processing model). Move SOAP
> messages around in HTTP and you are doing HTTP.... no-binding required...
> you're doing HTTP and normal HTTP semantics apply - and the SOAP messages
> are in some sense (although I don't know what) resource representations.
> This gives you access to all the HTTP methods and (I think) requires no
> definition of a binding. Of course in the process SOAP ceases to be a
> protocol (in this view), it becomes a content-type and a processing model.

No, it's still a protocol, in that mustUnderstand, actor, and the
end-to-end model defined with them, comprise extended agreement
required to permit a priori communication.  This is (roughly) the
definition of a protocol.

A litmus test of whether something is a protocol or not, is whether the
thing has faults.  If it does, it's a protocol.  If not, it isn't.
This works because faults are a by-product of agreement.

> In the other view, the 'tunneling' view, folks very much see SOAP as a
> protocol for exchanging messages and they want to be somewhat agnostic to
> what underlying protocol SOAP is bound to, much in the way that folks can be
> (mostly) agnostic about what the data-link technology IP is bound to. In
> this view folks conceive of themselves as exchanging messages (SOAP
> messages) between endpoints (which process messages) identified by URIs. In
> this 'view' the messages are not considered to be representations of
> resource state (representations of the state of an endpoint) - they are
> messages exchanged between entities bound to those endpoints. This view
> requires a binding, because it is *not* doing HTTP, its is doing Message
> Exchange over HTTP (tunneling).
>
> These two views re at odds because the 'chameleon' view seeks to expose
> HTTP as fully as possible and in the limit SOAP/HTTP is HTTP (full-richness)
> whereas the 'tunneling' view seeks to abstract away from or 'hide' HTTP and
> avoid exposing details of the underlying protocol to the thing (application
> entity) using SOAP.

That's a good characterization.  Another way of saying it is that the
chameleon view exposes the application model in use, whereas tunneling
hides it.

I think this explanation goes a long way to explaining why the tunneling
view disregards Web architecture.  The Web is an application, and
tunneling over it disregards that application and all the rules and
constraints that were built into it (Tim's axioms).

> So we have two communities (at least) pulling toward these different
> extremes. 
> 
> I think that one reasonable viewpoint is that one can 'do' HTTP and
> simply(?) use SOAP for the content-type of the of an HTTP request/response
> entity body. This *is* HTTP, no binding required.

A binding is required in the chameleon view because 1) you have to know
how to map SOAP faults into the fault model of the application protocol,
and 2) you have to know which parts of the application model of the
underlying protocol is being reused.  For example, we currently only
define a POST binding, which means that we can't do replacement-type
stuff, since HTTP PUT is required for that, nor can we do retrieval,
since GET is used for that.

> However, in the Messaging/Tunneling view you do need a binding to establish
> how messages are exchanged between messaging endpoints. Of course you then
> need to establish the (binding independent) semantics of your messaging
> system (what messaging operations does it support and what are their
> semantics)

Ah, see, there's the rub.  Application protocols *already* define those
semantics for you (some being more general than others).  The chameleon
view reuses them, whereas the tunneling view ignores them and reinvents
new ones.

> - and an account that describes how the semantics of message
> transfer are accomplished as a pattern of resource state manipulations. eg.
> these resources represent intermediary-points and end-points in a messaging
> system, and that the effects of  HTTP are to transfer messages that are
> either immediately processed yielding an immediate result (200), or that are
> accepted as subordinates (201) (an entry in a queue at the endpoint).
> 
> I have a concern that we may be trying to align messaging semantics and HTTP
> semantics so tightly that ultimately we fail to define a messaging system
> and all we end up with is SOAP as a content-type for HTTP.

I don't know what a "messaging system" is, nor do I believe the WG
could ever agree on that.

Also, as I've tried to reiterate many times, I'm not trying to align
anything with HTTP semantics, except for the HTTP binding.  I'm trying
to say that the big value add of SOAP is where it is used in a way
that, at each hop in a path, reuses the application model in use for
that hop.

An example ...

Suppose I want to build a SOAP/HTTP based interface to email.  I would
build a SOAP/HTTP node that accepted a message in over POST, and then
sent it out over DATA.  So I could do;

POST skw@hplb.hpl.hp.com HTTP/1.1
Host: marks-email-gateway.markbaker.ca
Content-Type: application/soap+xml
Content-Length: 1234
From: distobj@acm.org

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
 Hi Stuart, how are you?
 </env:Body>
</env:Envelope>

and then my software would convert that to;

HELO marks-email-gateway.markbaker.ca
MAIL FROM: distobj@acm.org
RCPT TO: skw@hplb.hpl.hp.com
DATA
[headers..]
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope" >
 <env:Body>
 Hi Stuart, how are you?
 </env:Body>
</env:Envelope>
.

That's what a SOAP HTTP/SMTP gateway would do.  The value of SOAP as a
protocol here is the extended end-to-end model; that I could include
extension headers that I require that your end understand (assuming
your receiving SMTP processor dispatches on one of the headers we
included - note to self, see what email binding does here).

> > For sure, and I'd rather not have to enumerate these.  That's why I
> > think it's easiest to use broad strokes and say that *if* a response
> > includes a body *and* uses any 4xx or 5xx response code, then it is a
> > fault ...
> 
> So wrt 4xx status codes, 2616 states:
> 
> <quote>
>    Except when responding to a HEAD request,
>    the server SHOULD include an entity containing an explanation of the
>    error situation, and whether it is a temporary or permanent
>    condition. These status codes are applicable to any request method.
>    User agents SHOULD display any included entity to the user.
> </quote>
> 
> I think that there is a mismatch of expectations here if the entity body is
> a SOAP fault ;-)

How so?  You mean the "display" bit?  It's not hard to build a browser
plug-in, or an intermediary, that could display a fault.

> > I agree that there are different POVs, and that MUST is the right
> > conformance level here, but that still doesn't say what the
> > authoritative determinant of a fault is.
> 
> Well, it would say that one party is non-compliant... ie is broken. They are
> in error. If you proceed at all, proceed with caution. Maybe throw your
> hands up in horror and refuse to play because you have received something
> invalid... as broken as badly formed XML.
>
> One could produce a ruling one way or the other for these non-conformant
> cases, but which way to make the rule is open to debate. 

Hmm.. But there's no "parties" here, it's a single message that asserts
two conflicting things; "I'm a fault", "I'm not a fault".

Are you suggesting that a fault be generated if such a fault is
received?

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

Received on Tuesday, 5 March 2002 11:13:23 UTC