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