Web Services Not Always Better

cdthompso1 writes "In a pragmatic article at ZDNet Australia entitled 'Porting to .NET: Style at the sake of speed?' author Tim Landgrave analyzes the pros and cons of rearchitecting a legacy C++ application to .NET using the lastest services-oriented approach. His conclusions may surprise some, particularly if you are contemplating or already in the middle of a .NET migration yourself."

Comments

Re:Why are his conclusions a suprise?

[sydlexic]

I disagree with part of this. A proper VM can actually perform faster in many complex scenarios where runtime optimization is better than static compilation. What makes web services suck is XML and SOAP. It's extremely bloated compared to packed binary representations. Parsing XML and walking DOM trees can be a killer.

Tight vs. loose coupling will always be a tradeoff

[melquiades]

Good article, although it mischaracterizes the difference as performance vs. elegance; really, what they're talking about is tight vs. loose coupling.

Web services, both .NET's and J2EE's, are inherently loosely coupled. They work well, therefore, in situations which call for loose coupling. Surprise!

But loose coupling is not always what you want -- a more tightly coupled, or more language- or platform-specific, remote communication mechanism can yield better performance and less bandwidth usage, and may allow richer communication between systems and better use of language-specific features. When you don't have language independence or integration of heterogeneous systems as a design constraint, tighter integration may be the better option. Certainly the fashionable mania for web-servicifying everything under the sun is a bit overzealous.

It's a familiar moral: choose a degree of abstraction and decoupling appropriate to the problem at hand.