[
Lists Home |
Date Index |
Thread Index
]
>> 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.]
|
