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

Comments

no suprise here

[DrSkwid]

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

C++

[krokodil]

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

Re:C++

[lpontiac]

I do not understand authors rant about C++.

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.

from the first line...

[Enrico Pulatzo]

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

Web services and performance

[r4lv3k]

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

.NET Compact Framework *chortle*

[lpontiac]

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.

My experience

[archeopterix]

I've recently implemented a SOAP interface to a database (as an Apache module written in Delphi 7). It crawled, albeit only until I replaced the standard Delphi native-to-SOAP translator with a custom one. The problem was that the standard translator:

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 :-)

[Anonymous Brave Guy]

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:

Sometimes we automatically assume that the latest platform or tool is the universal best.

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.