Cart
[Home] [By Thread] [By Date] [Recent Entries]
"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 [expletive deleted] 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
|
