it clear that CCM was technically immature: sections of it were essentially unimplementable or, if they were imple-mentable, did not provide portability.
˲No commercial CORBA vendor
commited to implement CCM.
˲ Even if implementations had been
available by the time CCM was published, it was too late. EJB had become
entrenched in the industry to the point
where another component technology
had no chance of success.
CMM failure did little to boost the
confidence of CORBA customers, who
were stuck with complex technology.
Meanwhile, the industry’s need for
middleware was stronger than ever. After some experience with e-commerce
systems that used HTTP, HTML, and
the CGI (Common Gateway Interface),
it had become clear that building distributed systems in this way had serious
limitations. Without a proper type system, applications were reduced to parsing HTML to extract semantics, which
amounted to little more than screen-scraping. The resulting systems turned
out to be very brittle. On the other hand,
EJB had a proper type system but was
limited to Java and so not suited for
many situations. There were also a few
flies in the CORBA ointment:
˲ Commercial CORBA implementations typically cost several thousand
dollars per development seat, plus, in
many cases, runtime royalties for each
deployed copy of an application. This
limited broader acceptance of the platform—for many potential customers,
CORBA was simply too expensive.
˲ The platform had a steep learning
curve and was complex and hard to use
correctly, leading to long development
times and high defect rates. Early implementations also were often riddled with
bugs and suffered from a lack of quality documentation. Companies found it
difficult to find the expert CORBA programmers they needed.
Microsoft never embraced CORBA
and instead chose to push its own
DCOM (Distributed Component Object
Model). This kept much of the market either sitting on the fence or using
DCOM instead, but DCOM could not
win the middleware battle either, because it worked only on Windows. (A
port of DCOM to Unix by Software AG
never gained traction.) Microsoft eventually dropped DCOM after several
failed attempts to make it scale. By that
time, the middleware market was in a
very fragmented state, with multiple
technologies competing, but none was
able to capture sufficient mindshare to
unify distributed systems development.
Another important factor in CORBA’s
decline was XML. During the late 1990s,
XML had become the new silver bullet of
the computing industry: almost by definition, if it was XML, it was good. After
giving up on DCOM, Microsoft wasn’t
going to leave the worldwide e-commerce market to its competitors and,
rather than fight a battle it could not win,
it used XML to create an entirely new
battlefield. In late 1999, the industry saw
the publication of SOAP (Simple Object
Access Protocol). Originally developed
by Microsoft and DevelopMentor, and
then passed to W3C for standardization,
SOAP used XML as the on-the-wire encoding for remote procedure calls.
SOAP had serious technical shortcomings, but, as a market strategy, it
was a masterstroke. It caused further
fragmentation as numerous vendors
clambered for a share of the pie and
moved their efforts away from CORBA
and toward the burgeoning Web services market. For customers, this added
more uncertainty about CORBA’s viability, often prompting them to put investment in the technology on hold.
CORBA suffered another blow when
the Internet bubble burst in early 2001.
The industry’s financial collapse drove
many software companies out of the market and forced the survivors to refocus
their efforts. The result was significant
attrition in the number of commercial
CORBA products. Before the collapse,
several vendors had already dropped or
deemphasized their CORBA products
and, after the collapse, more followed.
What in the mid- to late 1990s had been
a booming market with many competing products had suddenly turned into
a fringe market with far fewer vendors,
customers, and investment. By then,
open source implementations of CORBA were available that partially compensated for the departure of the commercial vendors, but this was not enough to
recover the lost mindshare and restore
the market’s confidence: CORBA was no
longer the darling child of the industry.
Today, CORBA is used mostly to wire
together components that run inside
companies’ networks, where commu-
nication is protected from the outside
world by a firewall. It is also used for
real-time and embedded systems development, a sector in which CORBA
is actually growing. Overall, however,
CORBA’s use is in decline and it cannot
be called anything but a niche technology now.
Given that only a few years ago, CORBA was considered to be the cutting
edge of middleware that promised to
revolutionize e-commerce, it is surprising to see how quickly the technology
was marginalized, and it is instructive
to examine some of the deeper reasons
for the decline.
technical issues
Obviously, a number of external factors contributed to the fall of CORBA,
such as the bursting of the Internet
bubble and the competition with other
technologi es, such as DCOM, EJB, and
Web services. One can also argue that
CORBA was a victim of industry trends
and fashion. In the computing industry,
the technical excellence of a particular
technology frequently has little to do
with its success—mindshare and marketing can be more important factors.
These arguments cannot fully account
for CORBA’s loss of popularity, however.
After all, if the technology had been as
compelling as was originally envisaged,
it is unlikely that customers would have
dropped it in favor of alternatives.
Technical excellence is not a sufficient prerequisite for success but, in
the long term, it is a necessary prerequisite. No matter how much industry hype
might be pushing it, if a technology has
serious technical shortcomings, it will
eventually be abandoned. This is where
we can find the main reasons for CORBA’s failure.
Complexity: The most obvious technical problem is CORBA’s complexity—
specifically, the complexity of its APIs.
Many of CORBA’s APIs are far larger than
necessary. For example, CORBA’s object
adapter requires more than 200 lines of
interface definitions, even though the
same functionality can be provided in
about 30 lines—the other 170 lines contribute nothing to functionality, but severely complicate program interactions
with the CORBA runtime.
Another problem area is the C++ language mapping. The mapping is difficult to use correctly and contains many