sion of the architectural vision.
CORBA’s numerous technical flaws
have accumulated to a point where it
is very difficult to fix or add anything
without breaking something else. For
example, every revision of CORBA’s
interoperability protocol had to make
incompatible changes, and many fixes
and clarifications to the protocol had
to be reworked several times because of
unforeseen interactions with features
that were added over time.
can We Learn from the Past?
A democratic process such as the OMG’s
is uniquely ill suited for creating good
software. Despite the known procedural problems, however, the industry prefers to rely on large consortia to produce
technology. Web services, the current
silver bullet of middleware, uses a process much like the OMG’s and, by many
accounts, also suffers from infighting,
fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web
services will enact a history quite similar to CORBA’s.
What steps should we take to end up
with a better standards process and better middleware? Seeing that procedural
failures are the root cause of technical
failures, I suggest at least the following:
Standards consortia need iron-cast
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 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. Dif-
ferent 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
technical problems extensively scrutinized and tested, and only the “fittest” version survives. (Many
are at the heart open source projects formalize this pro-
of coRBa’s decline. cess with alternating experimental and production releases: the experimental
this raises the releases act as the test bed and evolu-
question of how tionary filter.) To create quality software, the ability
it is possible for to say “no” is usually far more important
than the ability to say “yes.” Open source
a technology that embodies this in something that can be
was produced called “benevolent dictatorship”: even though many people contribute to the
by the world’s overall effort, a single expert (or a small
largest software cabal of experts) ultimately accepts or ejects each proposed change. This
consortium to preserves the original architectural vi-
suffer such flaws. sion and stops the proverbial too many cooks from spoiling the broth.
as it turns out, At the heart of these open source
practices are two essential prerequi-
the technical sites: cooperation and trust. Without
problems are cooperation, the evolutionary process cannot work; and without trust, no ca-
a symptom rather bal of experts can act as an ultimate ar-
than a cause. biter. 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.
Michi henning ( michi@zeroc.com) is chief scientist of
ZeroC, Palm Beach Garden, FL. From 1995 to 2002, he
worked on CORBA as a member of the OMG’s architecture
board and as an ORB implementer, consultant, and trainer.
A previous version of this article appeared in the June
2006 issue of ACM Queue.
© 2008 ACM 0001-0782/08/0800 $5.00