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."
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.
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).
"Sometimes we automatically assume that the latest platform or tool is the universal best. Read about two situations where the old approaches worked better."
This makes me think we're not dealing with BSD people here.
Seriously though, if a new technology offers something valuable for the future, and speed is a problem, upgrading my not be a bad thing. If performance is an issue for you, it's gonna be an issue for someone else. Also bigger, badder machines are always coming out, so you can maybe solve the speed problem there.
It all comes down to the question: what are we getting out of the migration that makes it worthwhile.
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.
1. Built a DOM-Tree from the native Delphi data structures.
2. Serialized the tree.
Since the resulting datasets were usually big, it was painfully slow, mostly because of allocation/deallocation of the tree nodes. Once I built an "on the fly" converter, the XML generation time fell below 10% of the database access time.
The point - perhaps it's not the protocol, but the inefficient implementations that slow things down? In the above case, replacing SOAP with a tightly packed binary protocol, would only (at best) speed things 10% up. On the other hand, if the client were a handheld, perhaps things would be indeed much slower on the client side because of the XML/SOAP issues.
What I'd prefer to see is an objective article on why .NET and/or web services are ever better, rather than an assumptive "are they not always better?" piece. As has often been noted in these parts, often new != better, whereas tried-and-tested is a Good Thing in the absence of a compelling reason to change. The line at the top of the article is pretty telling:
Not if we're smart, we don't! (Although if we did, MS would be much happier. How many places do you know who haven't moved to VS.NET yet, because of either the things MS messed up compared to VS 6 or because they simply see no business case for doing so?)
I have seen lots of waffly arguments about .NET and web services, most of them sponsored by MS and others with an interest in selling the development tools. I can easily believe that there is some truth behind them, and some applications for which they are well suited, but I've yet to see anyone put forth a convincing and supported case for why it's worth moving to web services from established tools such as C++, Java and VB.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It sound and reads more like a blog to me.
.NET? Perhaps using .NET's builtin SOAP/XMP stuff is like using a shotgun to kill a fly?
This guy rants about his personal experience, covers only about 10% of the possibilies and bases his conclusion on BS.
How about using your own method to send objects over to the client app using
What about other platforms such as java?
I also don't understand what is with this guys hardon for C++ developpers. He talks as if C++ is some kind of ancient art, that is nearly impossible to master.
It's like any other fucking language. So there are pointers, big deal. I can learn C# just as easily as C++, or PHP. The high-level/Low-level nature of the language doesn't necessarily make it more difficult, you just have to THINK differently (sorry apple).
Hmmmm. So what if people want to build a car using bricks? Well, just wait until the engines are strong enough... That's sick.
I think there is some misplaced believe that performance has a bad influence on maintainability. Well, so have dependencies on JRE's, application servers and IDE's. I have seen enough trouble when upgrading from e.g. WebSphere X to WebSphere Y, or developers who are dependant on an IDE, or etc...
IMHO the will to spoil CPU speed and memory to technologies such as Java, XML, SOAP, .NET coming with very heavy runtintime environments, application servers and feature rich IDE's will leave real developers with skill and brains - like you - unemployed.
giel.y contains 2 shift/reduce conflicts