WebServices dot org

SOAP for the masses

There’s been an interesting discussion going on about the performance of SOAP and the advantages of a binary protocol have in that situation over XML and HTTP “ Even if you think you can beat Waldo, you can’t beat Einstein ”, “ SOAP Performance Considered Really Rather Good ”. The proponents of binary protocols, such as ICE or CORBA argue that much of the overhead in SOAP comes from parsing the XML, thread dispatch, connection setup and tear down etc., all of which have usually been optimised away in more mature technologies and simply cannot be removed from SOAP because of its fundamental architecture. The advocates of SOAP say that the performance can be improved and that when you consider its typical mode of use, performance isn’t always the limiting factor.

I agree with both sides to a degree, but think that the most important point is being missed. However, before we get there, I want to briefly discuss why I think both sides are right.

CORBA implementations these days are very fast and message service implementations such as AMS are built for speed. One of the earliest RPC implementations that I helped implement back in the mid 1980's was Rajdoot and we could easily achieve round trips on 5ms for messages up to 1K in size (packet fragmentation/re-assembly happens above this, so this was the maximum critical packet size). Not fast by today's standards, but fast back then. Having been working with SOAP and Web Services for many years now, I know it is slow compared to what we had in 1986, so it simply doesn’t compare to what iss possible these days.

However, SOAP performance can be improved. The sorts of things that go on under the covers today in terms of XML parsing, for example, are pretty inefficient. Next time you want to see, just pop up your favourite analyzer and watch what happens. I’m pretty confident that developers can and will improve on this though. As an analogy, back when the market leading CORBA ORB was first released its performance was terrible compared to later revisions, because opcodes were shipped as strings, for a start! SOAP doesn't have to be this slow - it can be improved.

But this is where I stop agreeing and come to the fact that it’s beginning to sound like the “PC versus Mac, Unix versus Windows” debates of old. You’re not comparing like with like. This is definitely a case of using the right tool for the right job, combined with some unfortunate commercial realities. If you want interoperability with other vendors (eventually pretty much any other vendor on the planet), then you would go the SOAP route: there is no logical argument to the contrary. CORBA didn’t get mass adoption; DCE failed before it, and despite Microsoft's power, so did DCOM. The reason SOAP works well is because of XML, HTTP and pretty much universal adoption. I can’t see that changing. In the foreseeable future, I can’t see the likes of Microsoft, IBM, Oracle, BEA etc. agreeing on a single protocol and infrastructure as they have with SOAP. To be honest, I think they were forced into the current situation because of the mass take-up of the original Web: if you’re a vendor, then vendor lock-in is good and the preceding decades have shown that many vendors will do whatever they can to maintain it.

But you pay a heavy price for this kind of interoperability. There are inherent performance problems in SOAP that I just can’t see going away. We may be able to chip at the surface and perhaps even make bit dents, but fundamentally I’m confident that SOAP performance versus something like ICE (or CORBA) will always be a one-sided contest. However, a contest of interoperability will be just as one-sided, with SOAP winning. From the moment I got into Web Services, I’ve said that I can’t see it (and SOAP) replacing distributed environments like CORBA everywhere. It frustrates me at times when I see clients trying to do just that though and then complaining that the results aren’t fast enough! If I want to go off-road, I’ll buy a Land Rover; but if I want speed, give me a Ferrari any day! Distributed systems such as CORBA have been heavily optimised over the years and use binary encodings as much as possible - with the resultant impact on interoperability and performance. But that is fine. That’s what they’re intended for.

Fortunately I’m certain that Web Services and SOAP are going have to improve: though how long it will take is something I’m not willing to take a stab at. A good analogy comes if you consider natural languages. There may well be an argument that English isn’t the best global language and perhaps something like French or German would be a better choice. For example, I’ve heard people say that English isn’t structured enough and has many illogical rules that make teaching it as a foreign language difficult. Due to historical events, English has become the language of commerce and a fairly global language too. However, what we speak today isn’t the same as was spoken in the tenth century or even the eighteen century: it has evolved to take into account the changing needs of society (e.g., slang). This is how I see SOAP (and Web Services) evolving too. Now it would be wonderful if we could all agree to adopt something that is more efficient than SOAP, but that isn’t going to happen. But I do believe things will evolve and improve. Let’s hope it doesn't take a couple of centuries though.

So in summary: I think we can all agree that the performance of SOAP is poor compared to other platforms. Of course there will be performance improvements for the SOAP infrastructure. There may even be a slow evolution to a pure binary, extremely efficient distributed invocation mechanism that looks similar to those systems that have gone before. But it’s not strictly necessary and I don’t see it happening as a priority: in terms of interoperability, SOAP wins time and again over those other platforms. It lowers the integration barrier. However, if you are really interested in performance and/or can impose a single solution on your corporate infrastructure, you may be better off looking elsewhere, to something like CORBA, or maybe even ICE.