CORBA的麻煩事... (轉)

CORBA的麻煩事... (轉)[@more@]

The Trouble With

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, provd neither. It defined very loose programming interfaces, especially on the server side, and left completely unspecified what protocol should be used to communicate between request brokers (ORBs) produced by different vendors. Under pressure from users, the Object Management Group created the Inte 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 seamley—every feature in both products must work in the combined environment. If this isn't true, I'll be stuck kee 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 components on 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 nois to stick with a single supplier. And surprise, surprise, every succesul 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 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 doubought 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 inate.

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 s 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/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?:namespace prefix = o ns = "urn:schemas-microsoft-com::office" />