Performance: Web Services vs Remoting vs Enterprise Services

I guess anyone that has developed an n-tier application has come up against the question of how to communicate between the physical tiers of their application. Web Services are pretty popular, but if you don't need to expose your middle tier to other applications - if your middle tier is only ever going to be called by the presentation layer tier of your application do you really need all that standards overhead? I have used web services for some things and Binary remoting over http for others. Up until now there has been a fair bit of debate, but not a lot of direction. Finally Microsoft has published a white paper on the subject -

It turns out that one of the biggest performance issues was whether you were passing ADO.NET datasets between the tiers. Now I have used datasets in this manner as they provide a very quick way of creating an application. But apparently datasets always serialize to XML, even when you explicitly specifiy the binary formatter in Remoting or Enterprise Services. One of the key points that I got from this article was the fact that, in terms of performance it is faster to manually serialize a dataset into your own custom object and transport it across the tiers than it is just to pass the dataset.

So what was the conclusion of this article? Basically, don't using remoting. If you are after transactional objects or raw speed use Enterprise Services. If you are after interoperability or an approach with less manual coding go with Web Services. Both these alternatives have a good upgrade path to the technology that is coming in Indigo (which I think has been officially dubbed “Windows Communications Foundation”) Remoting is not significantly faster performing than Web Services.

(The only exception to this is if you use Remoting over TCP with the Binary Formatter and in this case you probably end up writing more custom code than if you were to use Enterprise Services)

Updated: 5 Sep 2005 - corrected the language around the presentation tier, I called it a layer instead of a tier. The common usage now is to refer to the logical divisions in an application as a layer and the physical divisions as a tier.

I did not mean to promote the idea that eveyone should be splitting their application across physical tiers. I have been there and done that, by all means split your application up into layers, but only ever split it into tiers if it is absolutely necessary. n-layer = better design. n-Tier = more headaches.

Thanks Mitch Denny for pointing this out. although I think the flame was a bit harsh.

Print | posted on Wednesday, August 24, 2005 2:51 PM