Re: another approach to status codes, etc. in HTTP binding

Jacek Kopecky wrote:
> 
>  Hello all. 8-)
>  I apologize if I repeat somebody but I didn't read the whole
> bulk of the discussion this time.
>  My view on 2xx/4xx/5xx is the following:
>  We've heard that SOAP is either an extension of HTTP or a layer
> above HTTP.
>  We've heard that HTTP is an application protocol, not a
> transport protocol.
>  Every application protocol can be "abused" to serve as a
> transport protocol.

So far so good.

>  Now we have XMLP. I'll use this acronym because I think we
> should consider what we would do if we built XMLP from scratch,
> and then compare it with what SOAP does and decide on the
> relative merits. What I say about XMLP may not be true about SOAP
> Version 1.2, I'm changing the facts here for the sake of
> discussion.
>  XMLP messages are defined in terms of Infoset, with processing
> rules based on the Abstract Model. We need to transport the
> messages from one XMLP node to another. We are in need of a
> transport protocol. TCP will suffice for some applications.

The "null contract" that transport provides is indeed one of the ways in
which XMLP intermediaries can "communicate".  However nothing in the
Abstract Model that I'm aware of (which isn't prescriptive anyhow)
prevents the contract between XMLP intermediaries from being stronger
than simply transport.

>  I guess nobody will argue that TCP is an application protocol.
>  Now we see HTTP, and we know HTTP is good. And we know HTTP
> traverses firewalls. And we decide to use HTTP.
>  We use HTTP as a transport protocol because we need nothing more
> from it than from TCP. This is a layered approach so XMLP faults
> are HTTP successes.

This assumes that all that is required is transport.

>  I can't see any reason why anybody would want to switch from 2xx
> to 4xx/5xx in the scenario described above (_after_ having TCP
> transport).

Agreed.

>  Now back to reality - we have SOAP/1.1 and a working draft of
> SOAP Version 1.2 and we started with the HTTP binding modeled as
> an extension of HTTP. We are considering binding to TCP now.
>  I can see how one binding could be layered over one protocol
> while an other binding would extend an other protocol, even though
> it is a bit of inconsistency.
>  Anyway, does modeling the HTTP binding as an extension of HTTP
> bring some significant added value?

I hope so, otherwise all this typing is a big waste of time 8-).

The main benefit is that you can still operate within the context of the
application defined by the application protocol.  HTTP provides a very
rich set of application semantics in addition to those used with POST. 
So SOAP-over-HTTP based apps can work together with HTTP based apps. 
Ditto for other application protocol bindings (SOAP-over-SMTP working
with SMTP).  And you can do this *and* be able to transfer a single SOAP
message over gateways for various application protocols (the work to
bridge the gateway, say a HTTP/SMTP one, is entirely at the
application-level - SOAP need not worry about how that gateway works).

> Will then the TCP binding
> actually create a whole 'nother application protocol?

The application semantics have to be defined somewhere.  TCP doesn't
have them, so SOAP would either have to be used for RPC, or the
semantics would have to be implicit by some other means.  Or the binding
would have to define them.  All of those are, IMO, worse than simply
reusing the semantics of the application protocol.

MB

Received on Thursday, 19 July 2001 14:13:06 UTC