W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002


From: Mark Baker <distobj@acm.org>
Date: Sun, 31 Mar 2002 22:34:05 -0500 (EST)
Message-Id: <200204010334.WAA06239@markbaker.ca>
To: LMM@acm.org
Cc: xml-dist-app@w3.org
> If SOAP were a natural extension of HTTP, there would be
> examples where the same resources would engage in both
> HTTP web activities and SOAP-based activities in some way.

I've tried to describe examples like this;


> In every single case, there is no justification for
> a "chameleon use" model. There is no relationship
> established between the use case and the ordinary HTTP
> access of resources using GET, Accept, cache control,
> etags, last-modified, etc. 

Agreed.  You don't have to convince me that the chameleon use isn't
well understood or supported. 8-)

> So your theory about "chameleon use" isn't
> supported... of course you could, but why would you?

Because without it, there is no "Web" in "Web services".  The
traditional use of SOAP over HTTP will fail in the long run, both
because firewalls won't allow it, and also because of all the same
reasons that CORBA, DCE, and DCOM failed to gain traction across the
Internet.  If anything is to remain of SOAP in 3 years, it will be
this use.

> Contrast this situation with WebDAV, where at least it
> is argued that WebDAV operations are a natural extension
> into 'authoring' of the ordinary access to the same
> objects via web browsing.

For sure.  WebDAV is a more traditional extension of HTTP, both because
it uses HTTP's existing extension capabilities, and because it extends
HTTP with new, recognizable features.  The chameleon use of SOAP does

> If SOAP were really a "chameleon use", there would be
> some connection between SOAP and WebDAV, for example.
> You would integrate SOAP with the rest of the mechanisms
> of HTTP, including cache controls, content negotiation,
> Vary headers, last-modified and the rest. You would integrate
> SOAP responses with all of the mechanisms of HTTP, instead
> of this one little bit of "500" vs. "200" error responses.
> There's no basis for claiming that anyone has actually
> done this integration.

There is a little work to be done, for sure, but I see no need to
standardize it.  Also, as SOAP is primarily used over POST, and most
complex HTTP features are not used with POST (caching, conneg), there's
really not much to worry about, in my experience.

> >             In this use, SOAP very closely resembles
> > PEP[1], though of course the envelope and processing model remain
> > independant of any specific application protocol.
> > 
> >  [1] http://www.w3.org/TR/WD-http-pep 
> One of the main problems with PEP was that there were
> no compelling use cases; the justification given was
> of the form "People are already doing this so we should
> provide a standard mechanism for doing it", without
> any justification for why HTTP "extensions" made more
> sense than HTTP "tunneling".  So you can't reduce this
> to a previously-unsolved problem, it gives you no leverage.

The justification for PEP, RFC 2774, or the chameleon use of SOAP is one
of those "secrets" of Web architecture.  It's hard to know you need
something until you know what you're using, how and why it works, and
what it needs to help it evolve and scale over space and time.

Perhaps the push for "Web services" will result in this knowledge
becoming more widespread.  That's my hope, at least.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Sunday, 31 March 2002 22:34:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC