[XML-SIG] SOAP Skepticism
I'll confirm that there was a strong anti-SOAP bias at ICP10 and I
suspect it is indicative of a bias among the "hacker elite." *I* was the
SOAP defender (somebody had to play the role!) despite what I say below. (01)
Part of this is no doubt just a dislike of overhyped technology. But
part of it is: "why reinvent CORBA in XML badly?" (02)
Now I'll swing over to the other side to try and cleanse my soul. Sorry
that you're taking the brunt of it....take it as technical commentary: (03)
* too much stuff...the SOAP spec could be split into three or four
independent specs that would sink or swim on their own (04)
* neither fish nor fowl. When I last saw him speak, Henrik F. said that
SOAP was "just an envelope". Other people see it as an RPC protocol. In
one view it is an XML form of MIME. In the other it is an XML form of
CORBA/DCOM. In either view the whole point seems to be to put angle
brackets around something that already exists in a very circuitious and
expensive manner. (05)
* the churn has been so great over the last few years that
interoperability is a dream (06)
* all of the "REST versus SOAP" stuff you've seen...I won't repeat it.
But if the anti-RPCers are right then the SOAP RPC stuff has been a
massive waste of brain-power. And if they are wrong, then what would
have been the problem with just XML-ifying CORBA? Plus, when did an RPC
protocol ever succeed on the public Internet (e.g. DCE's)? Why would we
expect that to change now? (07)
* the SOAP encoding is too complex for mortals to feel like SOAP is
"human readable" (which it should be). I show people the dump of
two-param methods and they are already confused. (08)
* nit: SOAP had to have its acronym taken away because it had drifted
so far from its original goals. That's kind of a frightening world
record in requirements drift. It is also annoying to have acronyms
floating around with no expansion. (09)
* href: If you're right that it does transparent references to network
data then isn't it a little bit of a mistake to put network data (e.g.
UDDI) behind RPC interfaces that *cannot be referenced* (010)
* SOAP RPC is hard to implement interoperably. It's too big. It's more
than it needs to be to meet your bullet points below. (011)
* having a mapping from XML elements to language types (i.e. the SOAP
encoding) *in the message* is an arguably bad idea for security reasons.
The mapping should be entirely defined by the recipients (i.e.
TypeCodes, not xsi:type attributes). (012)
* the SOAP encoding is once again neither fish nor fowl. It isn't as
simple as defining a bunch of element types (as per XML-RPC). But is
isn't non-obtrusive enough that you could just take an existing
vocabulary and shove it in with a few extra attributes or something. So
you've got more flexibility than you need but not enough to be useful,
which is why you get the really hideous gensym: stuff. etc. etc. I could
complain about the encoding all day...either tell me precisely what
element types to use to get a certain structure or get out of my way.
Half and half doesn't help. (013)
* SOAP RPC tunnels RPC over firewalls whose admins would never
knowingly externalize RPC interfaces. (014)
* SOAP is full of optional features. XML philosophy was to drive
optional features out as much as possible (we failed once or twice but
overall did a much better job of SOAP). Optional features are an interop
nightmare. (015)
* I don't know that it is really meaningful to define a "transport
independent protocol." Most protocol specifications make some statement
about the underlying transport like: "HTTP relies on a reliable
connection-oriented protocol" or "Foobar relies on a broadcast
protocol". (016)
SOAP makes no such statement. As such, I don't know if it is really
even a protocol. The SOAP RPC binding to HTTP is a protocol. But SOAP in
general? If a SOAP message floats in to one system through email with no
reply addrss, and another system through an HTTP RPC, are they really
using the same "Protocol"? If it doesn't define the pattern of messages
back and forth, isn't it really just a data format? (017)
Leaving the operation mode of the underlying protocol up to the user
seems like the ultimate "optional feature." How can I reason about SOAP
systems if I don't even know whether, in general, they will return 0, 1
or N responses? (018)
Paul Prescod (019)