Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Elliotte Rusty Harold on Web Services
 On Sat, 08 Feb 2003 17:56:23 -0700, Uche Ogbuji <uche.ogbuji@f...> 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 [expletive deleted] 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
