World Wide Webber

I don't speak for Michi nor do I have enough expertise to do so but I do think that remark was made at a time SOAP was just beginning to gain some traction. That was a point when there weren't a whole lot of information on SOAP based deployments, its efficiency, robustness and general stability issues. I think given the current trends and the ratification of most WS-* standards, ICE could take a look at changing some of those statements atleast to reflect current realities.

One of the biggest selling points of SOAP originally was the XML encoding of the data. People kept saying until they were blue in the face that the "human-readable nature of XML" was an essential feature of SOAP and WS. In reply, I argued until I was blue in the face that XML as an encoding wastes bandwidth and CPU cycles by the bucket load. As far as I can see, the Ng paper deals with XML that's binary encoded, and with XML that's compressed into a binary blob. What Ng does not show is how these approaches would compare with a native binary protocol along the lines of Ice or IIOP. Well, I have bad news for him: a significant amount of work goes into parsing XML at the receiving end. Granted, if the XML is encoded as binary, that's more efficient than when it is encoded as text, but it's still a lot more expensive than decoding a binary encoding that is designed for the purpose. And, as far as compression is concerned, it provides bandwidth savings, but at a big cost. If you want proof, try Ice: Ice supports compression, using bzip2. It turns out that, on a LAN, compression slows things down overall because it burns too many CPU cycles. So, if you have a fast network, you are better off not compressing and just blasing the uncompressed data onto the wire. Where compression shines is when the links are slow, such as when you are sending data via modems or simple wireless devices (e.g. using GPRS). (Of course, Ice allows you to selectively use compression as appropriate). What does that mean for binary SOAP? Binary-encoded XML still loses because it requires more effort to parse. And compressed XML is a complete joke: first, we burn tons of CPU cycles creating the XML, then we burn another ton compressing that, then we burn another ton uncompressing it at the receiving end, and then be burn another ton parsing it back into a machine-usable representation. Please give me break: that's patches on patches on patches in order to compensate for a fundamentally stupid idea that was flawed from the start. And then people go and publish papers that say "hey, it's not that slow". Wow. Except that they never bother to show how slow it is compared to an efficient and well-design RPC protocol, such as the Ice protocol. Just to make the point crystal-clear: Ng quotes latency figures of 1.3ms for a simple SOAP client. 770 RPCs per second. Want to to know how many Ice does? Here you go: over 8,000 per second. Faster by more than a factor of ten. But, as the SOAP proponents keep telling me, that's not relevant... Oh yes, Ng neglects to show figures for throughput, so I can't compare directly. But you may want to test the throughput of your favourite SOAP implementation some time, say, for sending sequences of structs containing an integer, a 20-byte string, and double. With Ice, we get the full bandwidth of the underlying link. If we have a 100Mbps network, we saturate it. Depending on the application data that is being sent, that gives up to 80MB per second transfer rate. And, over the loopback interface, we do better than 500(!)Mbps. Lets' see what figures SOAP gets, shall we? The people who designed SOAP and WS have no idea of protocol and RPC design, and they persistently have ignored prior wisdom and the lessons we have learned the hard way over the past two or three decades. ("I've never done any protocol design but, after all, how hard can it possibly be...") As a result, they end up with technical solutions that are atrocious, and then try and deal with them by layering something else on top that makes it even worse. And then, to make themselves feel better, they write papers saying "ah, it's not that slow, really", conveniently neglecting that, if they were to bother and look, they'd find that what they are doing is not only slow, but appalingly so. Michi.

I've posted some comments here http://markclittle.blogspot.com/2005/06/soap-slow-or-fast.html I think you're both right, but for different reasons. SOAP is slow compared to something like ICE or CORBA. But it's an unfair comparison because they tackle different problem spaces. I'm all in favour of seeing SOAP performance improve, but comparisons with other distributed environments are easy to do but don't really convey any useful information. It would be the same as someone writing a paper on the interoperability merits of SOAP/WS versus CORBA or DCE; not a lot of point in that given commercial realities today.