[
Lists Home |
Date Index |
Thread Index
]
ERH has a thought provoking comment on his weblog today
http://www.ibiblio.org/xml/
" It hit me suddenly today that a lot of different communities intensely
dislike web services for similar, but totally different reasons:
The HTTP community detests SOAP/XML-RPC/Web Services because they violate
the fundamental design of HTTP.
The XML community detests SOAP/XML-RPC because they violate the fundamental
design of XML.
The security community detests SOAP/XML-RPC/Web Services because they
violate fundamental network security principles.
It's interesting that the Web Services community has managed to alienate
three different communities for three different reasons that all derive
from not understanding or accepting the basic principles of the
technologies they're building on. They're either geniuses or idiots. My
money's on idiots, but time will tell."
First, a question: I understand the first two all too well from following
www-tag and xml-dev. I don't understand the "security community detests WS
because the violate fundamental network security principles" bit.
Reference? Summary? Most of the "detestation" I've seen would apply to
XML message exchange of any sort, and don't see what SOAP/XML-RPC would add
to it. But again I'm asking, not arguing.
As an old-time SGML/XML geek thrust by the Day Job into the Web services
world, I'm somewhat ambivalent on the first, but more or less convinced
that the critique from the "XML community" is misguided. My (wishy-washy)
feelings on the "REST vs SOAP" permathread are quoted by ERH today, so I
won't repeat them.
On the "XML community" critique, the way I see it is that the Web services
people are pushing the XML envelope in ways it was not pushed before, and
have found it wanting: Things like entity references play hell with
efficient buffer management in high-performance parsers; XML 1.x is not
composable as specified, which makes the full spec unusable for a header-
extension model such as SOAP offers, and so on. (See the response by the
XMLP WG to this issue on www-tag a month ago for details). It's not at all
clear what the best way forward is -- forking, profiling, deprecating for
XML 2.x -- but I personally have little patience with the argument that the
"fundamental design of XML" has been compromised. In fact, the fact that
the SOAP community independently came up with essentially the same profile
of XML that the SML-DEV folks did a few years ago ("Common XML Core") makes
me even more convinced that the "fault" lies more on the XML side than the
WS side. Document and Messaging XML use cases certainly share a lot, but
maybe they don't share everything. I resist data-heads imposing their
paradigm on XML as a whole, and I resist doc-heads insisting that data-
oriented applications do it the One True XML Way.
My money is on the geniuses (whichever community they're in!), simply
because they're learning what actually works and are adapting in real time.
I'll bet against the zeaots (in any community) who think they understand
the problems of everyone by their knowledge of certain a priori principles.
As offensive as I found much of Erik Naggum's post discussed earlier, I
gotta love his .sig:
"Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder"
So, I pose the question: are the various communities who "detest" SOAP/RPC
Web services acting from reason and learning from both the WS failures and
the failures of their own pet theories, or are they acting from faith and
blaming those who tried to apply their pet theories and found them wanting?
To be honest, I see lots of adaptation to the ideas of REST and XML in the
WS community, but don't see many signs of learning from the WS experiences
in the REST and XML communities. Maybe I'm acting "from faith" too :-)
Thoughts?
--
Mike Champion
|
