[
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
http://www.adtmag.com/article.asp?id=7238
> 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
"objects.")
>
> 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.
|
