So far today I've received no fewer than 16 emails, in three entirely separate threads, about Michi Henning's recent ACM Queue article, "The Rise and Fall of CORBA." As many of you know, Michi and I co-wrote Advanced CORBA Programming with C++ over 7 years ago, which I suppose is why people are emailing me to learn my opinion of his article.
Michi addresses two areas in the article: technical issues and standardization issues. The technical issues are his opinion, and are nothing different than what he's been stating in other articles and in comp.object.corba postings for years now. Go peruse the archives of comp.object.corba, and you'll quickly find that Michi was once extremely and very vocally pro-CORBA, and now he's extremely and very vocally anti-CORBA. He changed his tune because the company he now works for sells a proprietary system intended to be a better CORBA. That single fact is the ultimate source of all of his articles and news postings railing against CORBA.
When you know as much about CORBA as Michi does, finding things to pick on is trivial. The same could be said for any expert in their field of expertise. For example, he cites API complexity as an issue. If one looks at the entire CORBA API, then what Michi says about complexity is correct, but in the real world, nobody ever has to deal with the whole API. For example, I'm currently reading Programming Ruby, and it's 864 pages long. Does that make Ruby complex? No, because you never need to deal with it all at once. Similarly, many of the areas that Michi cites as problem areas are really only hypothetical problem areas, as they do not reflect the reality of what practicing CORBA developers see in normal day-to-day development.
Many people know about technical positives and negatives with CORBA. We really don't need yet another article telling us what it got right and what could have been better, especially when the article is written to appear academic and noble when in reality it's written by a businessman whose ultimate goal is to try to make the competition look bad.
The second part of the article, which talks about the foibles of standardization, is much better than the first part. It reflects similar issues to what I described in one of my "Toward Integration" columns. Standards bodies tend to result in much frustration for people like Michi, me, and anyone else who tries to design software that's generally useful, correct, minimal, maintainable, and extensible. As I mentioned on a recent panel, there are lots of people involved in standards who can't recall the last time they wrote a line of code. Such people should not be allowed to participate in standards bodies, IMO. How can you write a standard if you have no idea how to implement it?
All in all, Michi makes a variety of very good points about the negative aspects of standardization. He mentions the open source practice of having a benevolent dictator, and that's something I'd like to see for every standard spec that gets written. Michi is right -- democracy just doesn't always work, and you need someone with the power to just say no. The benevolent dictator model is proven to work well in practice, and I think it could really work well for standards too.
In summary, my advice is to take the CORBA parts of Michi's article with a grain of salt, considering they were written by someone who would like nothing more than to see his product replace all the hard-working and successful CORBA systems that are out there today. However, I advise you to pay close attention to the standardization issues Michi raises, as they are all too real and highly problematic.
