Earlier this week a friend of mine asked me for some advice over an argument that some developers at his company were having. They are collecting data from a device, and one developer wanted to have the device send the data to a web service to receive the data. The other developer thought a web service would be to much “overhead” and wanted a different solution using direct writes or XML to the database and a UDP socket notifier for the server to parse the data.
I didn’t actually speak to the developers myself, but my friend sent me an MSN transcript of their “discussion”. Apparently tempers grew quite hot! I did read most of the discussion and spoke with my friend to learn more about the system.
It turns out there would be many transactions with the database and web service coming from these devices with a fair bit of geographic data that had to be processed at the server. One developer felt that using a web service would involve too much XML/SOAP overhead and wanted to write his data as XML to the database directly.
I was not in favor of this suggestion. A web service makes perfect sense in a .NET situation. It denotes a logical boundary between applications and computers, and would be pretty obvious to any supporting developer what is going on. Usually two applications do not share the same database (maybe the same server, but not the same database). This increases complexity.
I was also not convinced that the “overhead” of the SOAP would actually limit the application. Microsoft has done a lot to optimize web services. They’re easy to develop now, easy to consume, and as I said: a logical boundary between systems.
In the end I strongly recommended that they do some benchmarking. This early in the game is the perfect time to test assumptions. I also recommended using one of the new Service Bus APIs out there that use technologies like Microsoft Message Queues if the web services are too slow.
Also, as Jeff Atwood recommended in his Coding Horror blog, sometimes it is cheaper to throw another $5000 server at the solution (even TWO servers) instead of paying two $70,000 / year developers to spend three-to-six months doing performance enhancements.