Michi Henning writesÂ about The Rise and Fall of CORBA on the ACM Queue website. In the article he describes the history and development of the CORBA standard and details why it has been relegated to a infrastructure backwater. They key reason for CORBA’s failure that resonates with me is the following statement,
The OMG does not require a reference implementation for a specification to be adopted. This practice opens the door to castle-in-the-air specifications. On several occasions the OMG has published standards that turned out to be partly or wholly unimplementable because of serious technical flaws. In other cases, specifications that could be implemented were pragmatically unusable because they imposed unacceptable runtime overhead. Naturally, repeated incidents of this sort are embarassing and do little to boost customer confidence. A requirement for a reference implementation would have forced submitters to implement their proposals and would have avoided many such incidents.
2 thoughts on “The Rise and Fall of CORBA”
I’m in complete agreement. I coded CORBA for years throughout college and also completed a major project with the language. The entire specification is not standardized which wholly leads to incompatibility down the road. Customer’s want reliable middleware solutions that can be still implemented / expanded upon in years to come. Not an overly clunky language that takes an age to code and slow interaction due to unacceptable due to runtime overhead.
It’s as if you’re reading my mind …. 😉
Recommend one powerful Corba Simulator tools. Very simple & useful.
UCS (Ultra Corba Simulator) is one more powerful corba client/servant simulator tool than other similar products(e.g. Telcopro’s MtSim, or OpenFusion’s Corba Explorer, or eaiBridge’s CAST). It doesn’t need idl-related helper class or IR service.