Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SOAP, XSD, and HTTP
 >> If you drop the SOAP encoding rules (section 5), which many >> now consider to be deprecated by XML Schema, Uhh, they aren't deprecated by SOAP 1.2. SOAP defines a data model that is rich enough to handle arrays, structs, graphs, etc. that can be defined in actual programming languages but XSD does not directly support. Also, SOAP -- being just an "envelope" -- defines a model to identify the encoding style, which may be XSD, SOAP, or something yet to be invented. >Let me help you. Well known headers. Well known methods. An >addressing model worth a damn. SOAP has none of these. > >The intersection between an application protocol and SOAP does not >make SOAP an application protocol. That's practically a fallacy of >composition. There really isn't much point in formulating SOAP as a competitor to HTTP. The W3C -- TAG, XMLP WG, WS Architecture WG -- has bent over backwards to respond to the very well-reasoned critique from the REST perspective of SOAP-RPC as it is currently practiced (by default), and the final version of SOAP 1.2 will reflect what we have learned. See the TAG discussion at http://www.w3.org/2002/06/10-tag-summary#whentouseget [note especially Roy Fielding's comments, especially - "I am satisfied with the XMLP work on addressing the issues."] It's time to move on ... Or to put it more bluntly, "REST WON! Learn to accept victory gracefully!" If SOAP doesn't meet any needs for some project, don't use it! But looking ahead, it is very likely that SOAP will be used to provide a *framework* for protocol interoperability (much like XML provides a framework for data interoperability). As David Orchard says in the TAG discussion quoted above, "I think that [Roy Fielding] is right on here - SOAP specifies what to do in POST since there is no format otherwise." Also, if the point is that in a pure HTTP environment, much of what SOAP offers is un-necessary, that point is well taken. BUT the simple fact is that in many, many of the environments where SOAP is flourishing, HTTP is just one of the protocols in the mix -- there's proprietary stuff such as MQ Series ... JMS ... maybe BEEP someday... as well as HTTP/SMTP/etc. SOAP's value is clarified when there ARE intermediaries, and one needs a way of bridging the information in HTTP headers across protocols that don't have them. Likewise, other protocols have things that HTTP doesn't have, such as asynch notifications, built-in reliability, transactions, security ... the chances are good that the world will collectively decide (and the W3C architecture may well reflect) that SOAP headers are a good mechanism to convey this information across applications and protocols. Of course, SOAP will continue to be mis-used, just as HTTP is mis-used; the W3C has tried to clarify best practice for its use. I would suggest that people who feel strongly about the mis-use of SOAP focus on educating the abusers, and on demanding tools from vendors that easily support best practices for the use of WSDL, HTTP, and SOAP. To trot out my favorite aphorism yet again, "the best is the enemy of the good." I could probably be persuaded that SOAP is not "the best", and that "HTTP everywhere" and using REST-friendly ideas such as tupe spaces / XML spaces to achieve notification, reliability, security, etc. are the "best" way forward. Still, a) none of these are fundamentally incompatible with SOAP and b) setting up SOAP and REST as enemies will probably result in a worse situation (e.g., the Web being "embraced and extinguished" by a SOAP Everywhere protocol stack) than we would be in with a grudging respect between the various partisans. [not speaking for XMLP or WSA WG's -- I believe the XMLP WG is drafting an official announcement on the TAG finding ... sorry to jump the gun, but I really want to discourage what I see is an unproductive line of argument.] 
|
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
|
|||||||||
