Slashdot Mirror
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."
Good article, although it mischaracterizes the difference as performance vs. elegance; really, what they're talking about is tight vs. loose coupling.
.NET's and J2EE's, are inherently loosely coupled. They work well, therefore, in situations which call for loose coupling. Surprise!
Web services, both
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.
.DCOM interfaces marshalled binary data
Thing about XML is that it is too abstract, all that meta data & processing weighs it down.
XML/SOAP is too "It ain't what you do, it's that way that you do it"
Proper distributed computing long ago discovered that terse protocols win out. Throughput is increased when the client and server know the details of what they are talking about. The data contains more information per byte.
XML is like Esperanto
For the most part the time and trouble both parties take to learn a common language is too expensive compared to the potential length of any conversations. If there is a power differential it may even be prudent for the lesser (client) to learn the language of the greater (server).
The real solution is to try and find a properly configurable client. Pinning your tail to the WinCE Donkey, like most MS tech, is made harder by the donkey being constantly on the move. API instability & an unsettled programming methodology is why you need new tools every year.
I'll be able to usefully operate my iPaq running one of Linux/Inferno/plan9 until it breaks. My other WinCE machine is rapidly gathering dust, the tools for it long gone, the support for it discontinued.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I do not understand authors rant about C++. What it have to do with the subject of the article (web services). Indeed you can write web services (client and server part) in C++ or any other language.
The fact them amount of data transfered with XML is more than tightly packed binary structures is old news. But overall tendency of Internet protocol design seems to favor ease of parse, human readability over saving few bytes.
Side note: XMLRPC could be used for web services and it is slightly more terse than SOAP.
Overall article is very light-weight and holds almost not useful information (besides God vs C++ programmers joke).
I have also encountered this type of situation. I had a .NET server communicating with diverse clients, some running NT, some UNIX.
.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!
:). Used xmlrpc-c for all the 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
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
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
I've encountered this myself, and I don't think words can do justice to it's suckiness. It just isn't ready for production use.
If you've ever used a PocketPC or a Palm Pilot, you'd be used to the way that applications start instantly (they're executed in place in memory - no loading from disk required) and behave in a snapping fashion. A .NET CF application takes about 8 seconds to start - CF initialisation I assume. Then it runs slow as molasses, and some actions in particular (like opening a new window and drawing it's controls) take a few seconds, which is a few seconds too long.
VM versus compile-to-native arguments are irrelevant, because the thing is so slow it has to be the poor implementation, not a because-this-is-a-VM thing. Java ran faster on slower CPUs than a modern PocketPC has.
When the compact framework is shipped by default with the OS and always running, and the implementation has improved by miles, it might be ready. But not yet.