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."
Of course sometime with a runtime/vm is going to be slower than C++. As for verbosity, isn't that also kind of obvious too? Like he says, speed vs. grace. I always thought that would be the quite obvious tradeoff you'd make when switching to .NET.
Why not fork?
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.
Web services are only a small part of .NET...
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
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.
He apparently objects to "C++ gurus" (or "crafty old-hands who don't believe hype", as they're sometimes known) suggesting that things like .NET aren't actually offering any real advantage over existing practice. It's ironic that this comment should appear in an article that pretty much supports exactly that point. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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).
After having read the article twice I realize that the author actually does not talk about Web-Services.
Instead, he's talking about Windows CE - client-programming, perhaps with some communication with the rest of the universe...
It was strange because C++ doesn't have too much to do with Web Service. I have to say that the article was a complete waste of time as I didn't learn anything!!
Apart from that I have to say that Web-Services in C++ could be great fun, but as so often there is a lacking of standards. Java adresses this issue very effectively via Java Community Process, thus providing standards for the greatest technologies very fast... (While C++ doesn't even provide standardized UI,XML or DB programming - but actually some very good opensource APIs)
Please don't get me wrong - Actually I used to love C++, but recently I always had the feeling being on the wrong lane. This comes from the many decisions and concepts you have to live with:
Finally you realize that it's not C++ missing the elegance, it's the different approaches and many standard-C APIs that make your life to hell... With some accepted "organ" to propose standards C++ would be unbeatable...
XML is like Esperanto
Ha! LOL
Sometimes I think people have been brainwashed by the XML movement into forget all the computer science they every learned. Really what you are doing is designing a syntax for a language; XML defines in a sense a universe of languages that share common lexical conventions. An it's the lexical conventions of XML that make it wordy. Bandwidth and storage sensitive applications (like sending network pictures over the wire using SVG) would in my opinion be better done using more compact lexical rules -- something that would be lexed in lex and parsed with yacc.
That said, I'm not against XML. It's good in a lot of applications. In fact I'm designing a mobile application now which interchanges data with Tomcat using XML over http, and have found my solution to be quite fast. We chose to do XML, not because it was the only way to do the job, but because it appeared to us to be good enough and easy enough to use. By not having to think about designing our our data interchange language from the ground up, it allowed us to get our interchange part up and running in about a day instead of a week or so. However, had it proved necessary we could have easily ripped out the XML part and do a more terse custom language.
XML for us was not a strategic issue but an implementation detail -- and a small one at that. I think it's probably a sign of some bad design decisions or platform choices when minor implementation details come to have major strategic consequences.
The good performance of my application makes me wonder whether the problem these guys were having were in the SOAP implementation -- very likely on the handheld end. I didn't use SOAP because it wasn't available in the Java environment we chose (Waba).
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
any more than buffer overruns are C's fault.
I think my real horror comes from opening up a SOAP XML file and trying to make head or tail of it.
XML has it's place, I just don't think that "very thin clients" is that place.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter