Articles
The Trouble With CORBA
David Chappell - May 1998
I would really like to be a CORBA believer. I spent much of my career
working in the open systems world,and I know that multi-vendor standards
can do great things for our industry. CORBA has long held out the
promise of being this kind of standard, but sadly, it has never
met that promise. Even worse, it's becoming clear that it never
will.
Cataloging CORBA's Problems: A Short List
Traditionally, standardization has focused on two things: portability
and interoperability. The first CORBA specification, completed in
1991, provided neither. It defined very loose programming interfaces,
especially on the server side, and left completely unspecified what
protocol should be used to communicate between object request brokers
(ORBs) produced by different vendors. Under pressure from users,
the Object Management Group created the Internet Inter-ORB Protocol
(IIOP) as part of CORBA's next major release in mid-1995. More recently,
OMG has defined a standard interface for server-side applications,
something called the Portable Object Adapter (POA). IIOP and the
POA certainly qualify as progress toward the twin goals of interoperability
and portability, and both are appearing in today's CORBA-based products.
Unfortunately, they're not enough.
First of all, look at the timeline. From its initial release in
1991, it's taken seven years for CORBA to begin to approach the
standardization that its creators have touted since that first publication.
Even for a standards body, this is a long time. More important,
it's not clear that these additions bring true standardization.
Implementations of the POA are just beginning to appear, while IIOP
interoperability has been problematic. For basic ORB functions,
cross-vendor IIOP seems to work reasonably well. But every vendor
adds extensions to the base CORBA standards, extensions that can
cause interoperability problems when IIOP is used to connect diverse
ORBs.
And even if IIOP did offer perfect interoperability, it's not enough.
What about security services, directory services, and all the other
things required to build an effective distributed environment? True,
OMG has defined standards in all of these areas, and some vendors
have implemented a subset of those standards. But those standards
largely define interfaces, not protocols. Installing ORBs from two
different vendors may require installing, say, two different implementations
of the CORBA Naming Service, neither of which can interoperate with
the other. And in some cases, the standard interfaces defined by
the CORBA services leave crucial elements undefined, such as the
types of parameters passed in method calls. Since all of these things
make it very difficult to build an effective distributed environment
using multiple vendor's ORBs, in what sense is this a standard?
What Standards Should Be
True standardization is binary: you're either perfect or you're
broken. Suppose, for example, that I want to use two different vendor's
ORBs in my organization. Those ORBs need to interoperate seamlessly—every
feature in both products must work in the combined environment.
If this isn't true, I'll be stuck keeping track of what works and
what doesn't, and I'm likely to spend a considerable amount of time
making applications that use these "standard" products
interoperate.
Portability can be a more forgiving goal, since having even some
similarity in programming interfaces eases the burden of moving
code from one ORB to another. But if the goal is to create a third-party
software market, something analogous to today's large market for
ActiveX components on Microsoft systems, those interfaces must be
identical. There is essentially no market for shrink-wrapped CORBA
applications today because the CORBA standards aren't complete enough
to allow this level of portability.
Given CORBA's limited standardization, the most rational approach
is to install one vendor's product on all of the systems in an organization.
While some brave souls do try to mix ORBs from different vendors,
the norm is to stick with a single supplier. And surprise, surprise,
every successful CORBA vendor offers their products on a wide range
of systems. It's ironic that the major hardware vendors who originally
got the CORBA effort off the ground—IBM, Sun, and Hewlett Packard—all
seemed to believe their own marketing documents. The products those
companies produced could only have been successful if CORBA really
was a multi-vendor standard, because each one produced CORBA-based
products that ran only on their own systems. Not too surprisingly,
all three companies lost money on and eventually killed those products
(although IBM is trying again). The successful CORBA vendors were
those who, like Iona and Visigenics, realized that a viable CORBA-based
product would need to run on multiple systems.
But what kind of standard asks customers to install the same vendor’s
product on all their systems? Imagine if TCP/IP were like this,
effectively requiring the same vendor's implementation on all systems
within an organization. No one would consider it a standard technology
at all. Yet CORBA is still viewed this way, even though most customers
stick to a single vendor's ORB on all of their systems.
CORBA's Real Benefits
But if CORBA isn't a true standard, then what is it? Most fundamentally,
it has been a very effective marketing tool to help vendors sell
largely proprietary products. Many of those products are great—Iona's
Orbix, Borland's VisiBroker, BEA's ObjectBroker, and others all
have substantial numbers of happy users. But at least some of those
users no doubt bought those products in part because they supported
industry standards (getting upper management's approval is so much
easier if you can make this claim). All of the companies that make
these products quite truthfully claim to support the CORBA standards,
yet each one also encourages you to buy their product for all of
your platforms. This is hardly the goal of true standardization.
The fundamental problem is that users love standards, but vendors
often hate them. Accordingly, the vendors who control the OMG process
have created the appearance of standardization without the reality.
They chose to create "standards" that required proprietary
extensions. If, in 1991, those vendors had decided to create true,
complete standards, we might be facing a very different world today.
As it is, we're left with a choice between largely proprietary products
from small vendors or entirely proprietary products from Microsoft.
For many, perhaps most users, Microsoft is a much safer choice.
If CORBA were truly a standard, this would not be true. But it's
not, and so Microsoft will probably dominate.
Here’s a larger question, one for which there’s really
no answer yet: is it even possible for committees to successfully
create new technology? History isn’t encouraging. The Internet
Engineering Task Force manages to do it, in no small part because
the participants have primarily represented themselves, not the
firms they work for. The consensus-oriented process used by OMG
allows vendors to simply not standardize those areas in which they
can't agree. Too often, the predictable result is specifications
that are full of holes.
In fact, OMG has produced more and more specs over the years, but
seen less and less implementation of those specs. Confusing the
production of paper with the production of products is perhaps the
classic error for a standardization body. The most spectacular example
of this was the Open Systems Interconnection effort, which crashed
and burned after having churned through something like a billion
dollars of its sponsors’ money. It’s a shame that, despite
all that investment, the OMG’s sponsors—many of whom were
active players in OSI—didn’t learn much from it.
Conclusions
From the beginning, CORBA was never a true standard. Instead, the
vendors who controlled the OMG process chose to create something
that was more a marketing exercise than a complete technology. And
ultimately, this is very sad. What could have been a crucially important
industry standard has instead become just another marketing tool
for selling proprietary products. The opportunity for a true standard,
a TCP/IP for distributed objects, has been lost.
OMG and its supporters argue that given time, CORBA will become
a true standard. It's been seven years, and we're still waiting.
Why should we believe them now?
This article was originally written for Object News.