Why CORBA failed
Uche, the article you reference is a good one. An interesting read.

Fundamentally, the reason CORBA is not more often used is because ten percent or less of programmers can wrap their brains around it. The same goes for web services now that that got complex. The same is true for J2EE.

How many programmers, percentage-wise, do you think visit this website, or xml.com, or Slashdot, on a routine basis? We both know the answer. Not many. Ask yourself, how many of the programmers that you have worked with during your career have thorough technical libraries, have invested in career enhancement, or follow decent magazines? If the answer in _your_ case is "lots", then you ain't been in typical software companies. I get lots of blank looks when I drop casual refs to DDJ or CUJ, only a few developers I know are interested in buying (and _reading_) professional books, and so forth.

It's not a problem with CORBA at all. This may sound cynical and arrogant, but what it comes down to is there ain't too many Michi Hennings or Greg Vinoskis, nor Adam Bosworths, nor Don Box's, nor Roy Fieldings, nor Uche Ogbuji's. Most programmers don't know preorder traversal from inorder, they don't know security well enough to even know the typical exploits (like overflow), they've never heard of Scheme or Haskell or Eiffel, and they can't coherently explain the nuances of functions, closures, and how one passes information - or keeps it around.

So you expect this population to master CORBA? Hell, they can't master J2EE, SOAP or XSLT either, in my experience.

That article is an alpha-geek level article, to use Tim's coinage. Well, guess what? Most programmers aren't even geeks, period - they are just punching the clock. And that's why complicated technologies fail, and that's why the whole comparison game (like J2EE vs .NET) is essentially useless.

Again, sorry to sound off cynical.

no compression timings?
I would be interested to see timings for XML-RPC and SOAP where you gzip the message before sending it out. While I know that sometimes the time to compress and send would be comparable to straight sending, perhaps in this case, you might see savings.

I suspect that if people find that gzip-and-send works well, as a rule, that it would quickly become standard practice. Clearly, you don't need to gzip COBRA objects because they're already compressed.

Re: Why CORBA failed
And the sad thing is that CORBA is not that complicated. I have one comprehensive book about CORBA, which is thinner than my XML _introduction_ book - and for most uses a subset of all the CORBA functionality is sufficient.

CORBA bad reputation
Speaking my expirence in using both, one is as painful as the other.

I think the main reason CORBA gets the bad rap, is because it came first. People tried it, thought it was too hard, too buggy, too painful to use, and now just hate it. They now are presented with WebServices, told its new and improved, it is just XML, which is just fancy HTML, you know that stuff your 12 year old son can write, and they soon they start to believe the hype.

Where I work, you can't sell a CORBA solution, too many bad expirences. Web services, expecially since you can get things like Axis from Apache for free, and so this seem like a different, lower cost solution. Plus, when the boss goes to the book store, he finds dozens of SOAP books, and maybe one CORBA book.

As with many things in life, the winning solution is often based on popularity, not merit.

For me, it means writing SOAP, cause it cheap, can be done without drawing too much attention, and I have a customer who likes new shiny things.

I think the previous comment about programmers not wanting to learn either technologies is correct. I also think this leads to CORBA reputation