Slashdot Mirror

← Back to Stories (view on slashdot.org)

Web Services Not Always Better

Posted by timothy on from the web-toast dept.

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."

2 of 21 comments (clear)

  1. Tight vs. loose coupling will always be a tradeoff by melquiades · · Score: 4, Informative

    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.

  2. Web services and performance by r4lv3k · · Score: 4, Interesting

    I have also encountered this type of situation. I had a .NET server communicating with diverse clients, some running NT, some UNIX.

    Web services was not available for all the platforms, and even if it were, it would be too resource intensive for some- DOM is a memory hog! ONC-RPC would work for all but its ugly. CORBA is even uglier IMHO.

    The best solution I found was XML-RPC. The .NET platform has an XML-RPC library that supports remoting -- all I had to do was change a line of code to use the XML-RPC formatter instead of the SOAP formatter!

    On Solaris I could have used the Java libraries for XML, but these clients had better things to do than swap pages for the JVM :). Used xmlrpc-c for all the Unix.

    I was able to get xmlrpc-c to build on even the most braindead platform, but if for some reason I couldn't.. I'd write a quick-n-dirty SAX parser with expat, and reply with canned responses.

    My advice is don't cripple your design with the lowest common middleware solution. Encapsulate the ugliness, and embrace the future, it will be worth it in the long run.

    r4lv3k