I was having lunch with Keith Pijanowski (where’s your blog Keith?) last Tuesday and the topic came back to the perceived problems with Web service performance. It seems like I have been seeing more and more references to the theoretical performance problems of Web Services lately so I wanted to make a few points.
- I admit that XML is not the smallest format for representing data, but I think in 99% of the cases it is small enough. I could argue that HTML bloats data similarly, and somehow our intranets and the Internet and all our servers serving up HTML pages have managed to stay afloat despite it.
- Serializing objects into SOAP messages and deserializing SOAP messages into objects has long been the anguished cry of Web service performance nay-sayers. But what would happen if the serialization was turning the SOAP message into …something like ….XML! Well, you say, it already is XML. It sure is, that means the serialization would do … nothing! Boy, that would be fast! Admitadly, we are not really to this point yet, but in the SOA nirvana of the future you will be able to do things like update a database by streaming the input XML, after some validation, to the database and thus eliminate the whole serializer/deserializer bottle-neck. And it will be REALLY fast – potentially faster than the current distributed object mechanisms that we use today.
- Okay, so we do serialize and deserialize in most instances today. <sarcasm> And it is such an awful overhead! I don’t get to send my sql request for several milliseconds after the SOAP request is received on the wire. </sarcasm> So you are sending a SQL request? Over the network? Or maybe you are reading a file from disk? Or… I’m willing to bet that a large percentage of services out there do some sort of I/O, whether it is across the network or to a local device. In either case, if you do this, then the overhead of deserializing XML becomes a pretty mute point. Yes, it is overhead (unless you do #2, above) but there is a good chance that there are probably tighter bottlenecks in your system to widen.
Let me finally say that yes, there are situations where performance is a big problem and that trying to do #2, above, on today’s platforms may not be realistic, but performance is not the concrete barrier that some make it out to be…particularly when you consider the other advantages of Web services (like interoperability, loose coupledness, and the full featured architecture being created).