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

Mark, please see my comments inside. 8-)
I've cut out the cut-out-able stuff.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Thu, 19 Jul 2001, Mark Baker wrote:

 > Jacek Kopecky wrote:
 >
 > >  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.

See further below.

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

Certainly it does, that was the intention.

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

I'm afraid you understood my last question as

 "does HTTP binding bring some added value?"

instead of the intended

 "does HTTP binding as an extension of HTTP (as opposed to using
HTTP as a transport protocol) bring some added value?"

See below as well for I might have misunderstood you here.

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

I don't see how HTTP binding specifies application semantics for
SOAP. I don't see how any part of if does. In my opinion, to SOAP,
HTTP only provides the natural request/response messaging pattern.

The HTTP requests don't differ except in the SOAP envelope if I'm
doing an RPC or an async notification or some data submission. How
does HTTP define application semantics? (I'm not necessarily
saying it does not, I'm saying I can't see it.)

 In my view HTTP adds to TCP the following significant things:
 1) hierarchical address namespace
 2) application metadata (in HTTP headers, in SOAP now used only
by Content-type, Content-length, and SOAPAction that is being
considered for removal)
 3) transport methods (GET,POST...) of which SOAP only uses POST
so it could as well be the only method
 4) wider transport support - transparent compressions, chunking
etc.
 5) status reporting

Which of these do we really need for SOAP as an XML protocol?
 2) Content-type for MIME envelope support
 5) some status reporting so that we can have requests without
responses and still reuse one connection (think "204 No Content"
or "200 OK, content-length: 0" and add pipelining of requests)

These two things still don't define an application protocol, they
make rather a "smarter" transport protocol.

Here's why I think the others are not really needed:
 1) there's always just one significant (server) address in a
client/server communication; anyway there's as many addresses as
there are nodes in a communication; so IP addresses and ports
should suffice, although they are not as pretty.
 2) SOAP has perfectly good way of transporting metadata (SOAP
headers) except for the info about the payload, and of that only
content-type and length are used now, putting aside SOAPAction
(I'm a proponent of removing it.)
 3) SOAP only uses POST and I don't see how others would be needed
(as opposed to somewhat convenient)
 4) again not _needed_, just somewhat convenient sometimes


Best regards,
Jacek

Received on Thursday, 19 July 2001 16:32:41 UTC