of CORBA was another major factor in
the rise of SOAP. The supposedly loosely
coupled nature of XML was seen as addressing the problem, despite this idea
being just as naïve as funneling all communications through port 80.)
For a commercial e-commerce infrastructure, lack of security and versioning
are quite simply showstoppers—many
potential e-commerce customers rejected CORBA for these reasons alone.
A number of other technical issues
plague CORBA, among them:
˲ Design flaws in CORBA’s interoperability protocol make it pretty much impossible to build a high-performance
event distribution service.
˲ The on-the-wire encoding of CORBA contains a large amount of redundancy, but the protocol does not support compression. This leads to poor
performance over wide-area networks.
˲ The specification ignores threading
almost completely, so threaded applications are inherently nonportable (yet
threading is essential for commercial-grade applications).
˲ CORBA does not support asynchronous server-side dispatch.
˲ No language mappings exist for C#
and Visual Basic, and CORBA has completely ignored .NET.
This list of problems is just a sample and could be extended considerably. Such issues affect only a minority
of customers, but add to CORBA’s bad
press and limit its market.
Procedural issues
Technical problems are at the heart of
CORBA’s decline, raising the question
of how it is possible for a technology
produced by the world’s largest software consortium to suffer such flaws. As
it turns out, the technical problems are
a symptom rather than a cause.
The OMG is an organization that
publishes technology based on consensus. In essence, members vote to
issue an RFP (request for proposals)
for a specification, member companies
submit draft specifications in response,
and the members vote on which draft
to accept as a standard. In theory, this
democratic process is fair and equitable
but, in practice, it does not work:
There are no entry qualifications to
participate in the standardization process. Some contributors are experts in
the field, but, to be blunt, a large num-
ber of members barely understand the
technology they are voting on. This repeatedly has led to the adoption of specifications with serious technical flaws.
RFPs often call for a technology that is
unproven. The OMG membership can
be divided into roughly two groups: users of the technology and vendors of
the technology. Typically, it is the users who would like to expand CORBA to
add a capability that solves a particular
problem. These users, in the hope that
vendors will respond with a solution
to their problem, drive issuance of an
RFP. Users, however, usually know little
about the internals of a CORBA implementation. At best, this leads to RFPs
containing requirements that are difficult to implement or have negative performance impact. At worst, it leads to
RFPs that are little more than requests
for vendors to perform magic. Instead
of standardizing best existing practice,
such RFPs attempt to innovate without
prior practical experience.
Vendors respond to RFPs even when
they have known technical flaws. This
may seem surprising. After all, why
would a vendor propose a standard for
something that is known to suffer technical problems? The reason is that vendors compete with each other for customers and are continuously jostling
for position. The promise to respond to
an RFP, even when it is clear that it contains serious problems, is sometimes
used to gain favor (and, hopefully, contracts) with users.
Vendors have a conflict of interest when
it comes to standardization. For vendors,
standardization is a two-edged sword.
On the one hand, standardization is attractive because it makes it easier to sell
the technology. On the other hand, too
much standardization is seen as detrimental because vendors want to keep
control over features that distinguish
their product from the competition.
Vendors sometimes attempt to block
standardization of anything that would
require a change to their existing products. This causes features that should
be standardized to remain proprietary
or to be too vaguely specified to be useful. Some vendors also neglect to distinguish standard features from proprietary ones, so customers stray into
implementation-specific territory without warning. As a result, porting a CORBA application to a different vendor’s
implementation can be surprisingly
costly; customers often find themselves
locked into a particular product despite
all the standardization.
RFPs are often answered by several
draft specifications. Instead of choosing
one of the competing specifications, a
common response of OMG members
is to ask the submitters to merge their
features into a single specification. This
practice is a major cause of CORBA’s
complexity. By combining features,
specifications end up as the kitchen
sink of every feature thought of by anyone ever. This not only makes the specifications larger and more complex than
necessary, but also tends to introduce
inconsistencies: different features that,
in isolation, are perfectly reasonable
can subtly interact with each other and
cause semantic conflicts.
Major vendors occasionally stall proceedings unless their pet feature makes
it into the merged standard. This causes
the technology process to degenerate
into political infighting, forces foul
compromises, and creates delays. For
example, the first attempt at a component model was a victim of such infighting, as was the first attempt at a C++
mapping. Both efforts got bogged down
to the point where they had to be abandoned and restarted later.
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 embarrassing 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.
Overall, the OMG’s technology adoption process must be seen as the core
reason for CORBA’s decline. The process encourages design by committee
and political maneuvering to the point
where it is difficult to achieve technical
mediocrity, let alone technical excellence. Moreover, the addition of disjointed features leads to a gradual ero-