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 ListTraditionally, 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 Interfac es 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 BeTrue 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 are not 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, 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 With I ORGANIZATION. No One Woulding Consider IT A Standard Technology At All. Yet Corba Is Still Viewed this Way, Even Though Most Customers Stic k to a single vendor's ORB on all of their systems.CORBA's Real BenefitsBut if CORBA is not 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 Uses, Microsoft IS A MUCH SAFER CHOICE. IF CORBA WERE TRULY A Standard, this Would Not, Ando 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 is not encouraging The Internet Engineering Task Force manages to do it, in no small part because the participants. Have primarily represented themselves, NOTTE FIRS THEY WORK for. The consENSUS-Oriented Process Used by omg allows vendors to simply NOT Standardize Those Areas in Which They Can '
