OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Elliotte Rusty Harold on Web Services

[ Lists Home | Date Index | Thread Index ]

On Sat, 08 Feb 2003 17:56:23 -0700, Uche Ogbuji 
<uche.ogbuji@fourthought.com> wrote:

> Which is the problem.  SOAP is not XML, and should stop saying it is so.

 SOAP is a *customer* of XML, and uses more or less the same subset as 
"Common XML", the Skunk Works proposal, and what most non-XML geeks use in 
practice.   It uses XML, (the syntax in 1.1, the InfoSet in 1.2), it never 
says it is XML.

> I used to appreciate Paul Prescod's point that the significant 
> contribution of SOAP is the extensibility XML gives header formats.

That is exactly the major contribution of SOAP to the world.  (The encoding 
stuff has been deprecated by WS-I, the synchronous RPC stuff is useful 
mainly in fast, well-managed environments for all the reasons that Paul 
Prescod has elucidated over the last year or so). The 
hearder/extensibility/intermediary processing model comes through if one 
reads the 1.2 spec rather than all the blather put out by the marketing 
departments of "just use our wizard and you don't have to worry about that 
XML crap" vendors.  BTW, Uche has a nice rant on that very subject at 

> Ans anyway, if I want that, I'd rather just stuff an XML EPE into a 
> extension HTTP header.

Recall that SOAP (1.2 anyway)  is protocol-neutral.  Those HTTP headers 
don't have an obvious place to reside when one moves a good ol' XML 
document from a mainframe via a proprietary MOM through various app servers 
and finally out over HTTP.  Soap envelopes provide a home for such 
information.    In an all-HTTP environment, the SOAP headers provide more 
or less the same advantages that XML offers over alternative 
representations (S-expressions, ASN.1 encodings, etc) -- the network effect 
of all the pre-existing tools, utilities, books, tutorials, firewalls, etc. 
that understand (or surely will soon understand) various standard headers 
for encryption, security assertions, authenticated identity tokens, message 
correlation and choreography conventions, and so on.  As Prescod at least 
used to point out, these use cases for SOAP apply as well or better in 
message/document-oriented design patterns as they do in RPC message 
exchange patterns.

> So why am I supposed to care about SOAP again?  Oh yes, the wizards I can 
> use to generate "web service end-points" from programming language code.

I agree about the wizards, and whatever benefits they apprar to offer SOAP 
are mostly illusory.  They get SOAP in the door, but used unwisely (maybe 
perhaps used at all) the wizards tend to create lock-in, interop problems, 
and far more message-level complexity than is actually needed.

> So as far as I'm concerned, SOAP is not XML, nor is it useful to even a 
> fraction of the degree to which it is destructive.

Ah, but XML is what powers SOAP.  For example, following the classic 
RESTifarian doctrine of "visibility" allows message headers to be 
intelligently processable by generic intermediaries so that messages can be 
cached, filtered, re-routed, etc.  In the pre-XML world, as a practical 
matter that meant the HTTP headers; in the XML-based messaging world, 
intermediaries can peek deep into messages with SAX/DOM/XPath or whatever.  
SOAP headers just provide some standardization at the outermost layer, and 
a framework for further standardization of other headers (for example, the 
kinds of things addressed by proposals such as WS-Reliability, WS-Security, 
and so on.  If we were looking back at what SOAP + the wizards have offered 
to date, I would agree with much of what you're saying.  But if we're 
looking forward at what  SOAP itself + emerging standardized 
header/processing tools based on SOAP will offer, I do not.

The only sense in which I would agree that SOAP is "destructive" of XML is 
that some of the companies on the SOAP bandwagon were among those pushing 
the W3C the hardest down the road the XSDL and XQuery have traveled, and 
those who would put this stuff in the core of XML are doing XML no favors.  
But whatever one thinks about W3C XSDL, the PSVI, etc., blaming them on 
SOAP seems like a bit of a stretch.  I think it would be more accurate to 
say that the same (possibly malign or misguided) notions are driving SOAP 
as an object serialization format and RPC mechanism, W3C XSDL as  a 
language for defining interoperable object serializations, and XQuery as a 
way of querying all this stuff.  If the essence of SOAP was an object 
serialization and RPC mechanism, I would tend to agree with critics such as 
Uche. IMHO its essence is the header/extension framework, which has very 
little to do with objects, static types, the PSVI, etc.  (BTW, in 1.2 
"SOAP" is no longer an acronym, reflecting the reality that SOAP never was 
an "access protocol" and does not really have all that much to do with 

> Again this is the fork.  Just go ahead and fork, but be wise enough to 
> make the fork explicit, rather than wiggling it sub rosa into all the 
> places where it can do the most violence to interoperability.

I understand why people are pissed and suspicious seeing that SOAP is being 
hyped by companies with a less than sterling record of promoting truly 
standards-based interoperability.  But if one gets past the politics and 
skulldudgery in the industry (which would still be there if SOAP 
disappeared tomorrow) and look at precisely what we're talking about here, 
I don't think all the sturm und drang is warranted. This profile/subset 
stuff isn't coming the Web services world asking for XML to accomodate 
their needs.  The users of the wizards don't give a rat's patootie about 
XML standards .. the people that will be hurt by a fork are those trying to 
use XML standard tools such as SAX, DOM, XSDL, etc. to build legal SOAP 
messages, and they are likely to be the ones doing document-oriented 
messaging without the "assistance" of wizards.  Forking won't hurt MS, IBM, 
etc. ... it will hurt the smaller, innovative folks trying to leverage the 
full power of XML and SOAP-based technologies.

> Now reflect that XML came from the document-oriented world.  The data- 
> oriented world really just needs CSV with better support for hierarchies.

"Is XML for data, is XML for documents?"  is the Mother of Permathreads and 
I suspect I have nothing to say that I haven't said a dozen times on this 
list.   Let's just leave it as  "reasonable people disagree on this, and 
should probably agree to disagree and get on with life."

> Now what could it possibly be that separates these efforts from the 
> sneaky tactics of the WS crowd?  Whatever could it be?...

Beats me ... (seriously, I don't know where you're going with that).  If 
the argument is that when little guys diverge from the standards it's 
"innovation" and when big guys diverge from the standards its "embrace and 
extinguish",  I'm sympathetic.   But look beyond the superficial trade 
press "analyses" of Web services and you'll see a lot more diversity and 
real innovation (by large and small companies working alone or in different 
ad hoc groups and standards bodies) than you seem to be giving credit for.  
The Web services hype has lost its luster, and the marketing weasels of the 
world are looking for new worlds of BS to conquer.  That means it's time 
for the real work to begin -- lots of unworkable ideas to toss, lots of 
productive ideas to build on.

A lot like XML itself, in other words.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS