practice
Doi: 10.1145/1378704.1378718
There’s a lot we can learn
from CORBA’s mistakes.
By michi henninG
the Rise
and fall of
coRBa
DEPENDING ON ExACTLy when one starts counting,
CORBA (Common Object Request Broker
Architecture) is around 15 years old. During its
lifetime, CORBA has moved from being a bleeding-edge technology for early adopters, to being a popular
middleware, to being a niche technology that exists
in relative obscurity. It is instructive to examine why
CORBA—despite once being heralded as the “
next-generation technology for e-commerce”—suffered
this fate. CORBA’s history is one that the computing
industry has seen many times, and it seems likely that
current middleware efforts, specifically Web services,
will reenact a similar history.
ILLUSTRATION BY JASON LIMON
In the early 1990s, persuading programs on
different machines to talk to each other was a
nightmare, especially if different hardware, operating
systems, and programming languages were involved:
programmers either used sockets and wrote an
entire protocol stack themselves or their programs
didn’t talk at all. (Other early middleware, such as
Sun ONC, Apollo NCS, and DCE, was tied to C and
Unix and not suitable for heterogeneous
environments.)
After a false start with CORBA 1.0,
which was not interoperable and provided only a C mapping, the OMG (Object
Management Group) published CORBA
2.0 in 1997. It provided a standardized
protocol and a C++ language mapping,
with a Java language mapping following
in 1998. This gave developers a tool that
allowed them to build heterogeneous
distributed applications with relative
ease. CORBA rapidly gained popularity
and quite a number of mission-critical
applications were built with the technology. CORBA’s future looked rosy.
During CORBA’s growth phase in the
mid- and late 1990s, major changes affected the computing landscape, most
notably, the advent of Java and the Web.
CORBA provided a Java language mapping, but it did nothing to cooperate
with the rapidly expanding Web. Instead of waiting for CORBA to deliver
a solution, companies turned to other
technologies and started building their
e-commerce infrastructures based on
Web browsers, HTTP, Java, and EJB (
Enterprise Java Beans).
In addition, developers who had
gained experience with CORBA found
that writing any nontrivial CORBA application was surprisingly difficult.
Many of the APIs were complex, inconsistent, and downright arcane, forcing
the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible),
so calls for a CORBA component model
became louder and louder. A component model was a long time in coming,
however. Work was started in 1996 on a
CBOF (Common Business Object Facility), but that effort got bogged down in
political infighting and was eventually
abandoned, to be replaced by the CCM
(CORBA Component Model). A specification for CCM was finally published in
late 1999, but was largely a nonevent:
˲ The specification was large and
complex and much of it had never been
implemented, not even as a proof of
concept. Reading the document made