Rise and fall of CORBA
Since I was, at least for a while, an enthusiastic lover of CORBA, sometimes I have been quest for reasons CORBA has been displaced by SOAP and all this paraphernalia of SOA. Today I found an excellent article that address that question. The article is authored by Michi Henning who worked on CORBA as a member of the OMG’s architecture board and as an ORB implementor, consultant and trainer.
Besides a crystal explanation of the shortcomings of CORBA, he offers a number of tenets for an organization to follow when creating a standard. Now that I am part of the Interoperability and Markup subcommittees for the OpenAjax Alliance, I found them very insightful. Here I copy those principles:
Standards consortia need iron-clad rules to ensure that they standardize existing best practice. There is no room for innovation in standards. Throwing in “just that extra little feature” inevitably causes unforeseen technical problems, despite the best intentions.
No standard should be approved without a reference implementation. This provides a first-line sanity check of what is being standardized. (No one is brilliant enough to look at a specification and be certain that it does not contain hidden flaws without actually implementing it.)
No standard should be approved without having been used to implement a few projects of realistic complexity. This is necessary to weed out poor APIs: Too often, the implementers of an API never actually use their own interfaces, with disastrous consequences for usability.
Interestingly, the open source community has done a much better job of adhering to these rules than have industry consortia.
Open source innovation usually is subject to a Darwinian selection process. Different developers implement their ideas of how something should work, and others try to use the feature and critique or improve it. That way, the software is extensively scrutinized and tested, and only the “fittest” version survives. (Many open source projects formalize this process with alternating experimental and production releases: The experimental releases act as the test bed and evolutionary filter.)
To create quality software, the ability to say “no” is usually far more important than the ability to say “yes”. Open source embodies this in something that can be called “benevolent dictatorship”: Even though many people contribute to the overall effort, a single expert (or a small cabal of experts) ultimately rejects or accepts each proposed change. This preserves the original architectural vision and stops the proverbial too many cooks from spoiling the broth.
At the heart of these open source practices are two essential prerequisites: cooperation and trust. Without cooperation, the evolutionary process cannot work; and without trust, no cabal of experts can act as an ultimate arbiter. This, however, is precisely where software consortia find their doom. It is naïve to put competing vendors and customers into a consortium and expect them to come up with a high-quality product—commercial realities ensure that cooperation and trust are the last things on the participants’ minds.
Of course, software consortia contribute to an evolutionary process just as much as open source projects do. But it is the commercial marketplace that acts as the test bed and evolutionary filter, and it is the customers who, with their wallets, act as the (usually not so benevolent) dictator. This amounts to little more than an industry that throws up silver bullets and customers who leap after them like lemmings over a cliff. Until we change this process, the day of universal e-commerce middleware is as far away as ever.
