Web Services Not Always Better 21
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."
Why are his conclusions a suprise? (Score:1)
Re:Why are his conclusions a suprise? (Score:3, Informative)
Re:Why are his conclusions a suprise? (Score:1)
Re:Why are his conclusions a suprise? (Score:2)
This old chestnut seems to come up in every other programming thread these days. :-)
It's an intriguing and credible idea, and I don't dismiss it out of hand. However, speaking as someone who writes performance-critical maths software all day, I maintain a certain skepticism because I've yet to see any real evidence (or even a convincing anecdote) to support it. Can you give us
Tight vs. loose coupling will always be a tradeoff (Score:5, Informative)
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.
no suprise here (Score:3, Interesting)
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.
Re:no suprise here (Score:2)
If only someone could PLEASE explain this to the
Dave
XML is probably not to blame here. (Score:2)
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 mo
Yes, you're right - it's not XML's fault (Score:2)
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.
C++ (Score:4, Interesting)
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).
Re:C++ (Score:3, Interesting)
They say "C++ requires an expensive set of skills."
What that means is "out of all our monkeys with 6 months trade school education and a few years experience, mostly in Javascript and Flash, only 1 seem to have the skill level required."
I don't think C++ makes programming any harder. It does, however, raise the entry level point you need to reach before you're capable of doing anything at all.
Grrr! (Score:3, Funny)
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
Hype, C++ and .NET (Score:2)
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. :-)
from the first line... (Score:3, Interesting)
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.
Web services and performance (Score:4, Interesting)
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
.NET Compact Framework *chortle* (Score:4, Interesting)
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.
.NET is not web services (Score:2)
My experience (Score:3, Interesting)
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.
Wrong article :-) (Score:3, Interesting)
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.
This isn't an article (Score:3, Funny)
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).
What the hell has C++ to do with Web-Services (Score:1)
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 standar