[
Lists Home |
Date Index |
Thread Index
]
"Simon St.Laurent" wrote:
>
>...
>
> I think that in the end I'm asking whether SOAP has any real added
> value, apart from its most frequently disclaimed but still most popular
> use: RPC over HTTP.
Great minds think alike. I was writing another xml.com article on this
issue before I got distracted by the concrete issue of Google.
SOAP rhetoric today seems to me as a big shell game. If you say: "SOAP
doesn't work, it isn't interoperable and it doesn't do much", people
will point you at all of the great SOAP RPC services (okay both of them)
and say: "see, it is interoperable. It does everything that other RPC
protocols do."
If you say: "SOAP sucks because it is RPC and RPC doesn't scale", people
say: "no, it isn't RPC. If you think SOAP is RPC then you don't
understand it."
So you can either have interoperability/actual usefulness or you can
have vague promises of scalability in a wonderful message-oriented
future -- with no demonstration of interoperability or actual
usefulness. The most craven examples include people who say SOAP will
replace HTTP because HTTP is synchronous and one-way, whereas SOAP isn't
"limited to that". No, it isn't. But you also can't do anything else
*interoperably*.
RPC is "SOAP as it is used". "Asynchronous messaging" is a kind of
"platonic SOAP" that doesn't exist in reality.
Paul Prescod
|
