I spend a lot of my time with professional developers building systems on .NET,  discussing various architectural and design issues. One of my focuses as the moment is web services, and one of the topics that comes up on a fairly regular basis, when discussing web services, is the issue of speed.

 

Typically the question is couched in terms of “web services sound quite interesting, but they seem like they will be a bit slow, and speed is important to us”. Some people will then go on to tell you they have written their own special application protocol, to get the most speed out of their application.

 

So, are web services too slow? The short answer is no. The slightly longer answer? Read on….

 

So why do people think web services might be too slow. A lot of it seems to stem from the use of all those angle brackets – there seems to be some aversion to them – that and the “verbose” text that is the typical serialisation of an XML Infoset on to the wire. It is this very openness – as opposed to the opacity of say a DCOM ORPC wire level packet - that gives web services it great interoperability.

 

I think it was Pat Helland who likened XML to the cardboard packaging that we are all familiar with when we get good delivered - yes, it may be a little bulky and bigger than the item it is transporting, but its role is to help ensure that the package gets delivered to the right place safely. By and large, most of us are happy with that set up. Well, those angle brackets serve the same purpose for your application payload in a web service call.

 

However, text and angled brackets is not the only format for serialising an XML infoset – Indigo supports an optimised binary format that Don Box mentions in his Why Indigo? : The Five Minute Challenge blog. “[We] don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast”.

 

Another aspect to the web services speed issue is the assumption developers have that web services are bound to be the bottleneck. Why? Any sort of network call means latency, but are web services the bottleneck here? Not really. Yes, there is obviously a cost associated with the serialisation/de-serialisation, and the latency when the packet is on the wire, but how does that manifest itself to users – the perceived latency in the way the application handles the network calls versus the actual latency? A well designed application and judicious use of threads / asynchronous web service calls can help enormously, whatever you put on the wire.

 

There is also the issue of the application level protocol, and whether it is too chatty. This is a tougher one, but if you had a chatty interface that makes lots of calls, then you are going to be susceptible to speed issues irrespective of the protocol you use.

 

Architects and systems designers that go through this process of investigation do usually come to the conclusion that all the benefits afforded by web services – openness, cross industry support, interoperability, developer tool support, etc etc – more than make up for any issues (real or perceived) around speed.

 

In my next blog I will tackle the issue of moving large amounts of data using web services – an area where some advice and guidance is often needed, and a blog topic in its own right.