COM and CORBA: Not Really Competitors

Microsoft's COM and the Object Management Group's CORBA have long been portrayed as fierce competitors. Forests have been leveled to generate paper for the voluminous written attacks by partisans in both camps, and megawatts of electricity were expended to convey their electronic equivalents. COM vs. CORBA is one of the most visible industry conflicts of the last few years.

But it's not really correct.

Don't worry. I'm not going to explain how COM and CORBA can actually live in harmony, or how the Microsoft lion will lie down with the OMG lamb and peace will reign in the land. None of that is going to happen. All the hopeful predictions of the eventual technological union between COM and CORBA are wrong. These two technologies will remain distinct -- although the CORBA camp has understood the necessity of defining mappings to COM, if only to support those ubiquitous Visual Basic clients.

If COM and CORBA were really competitors, however, you'd be faced with situations where you were forced to choose between them. In fact, this almost never happens. And if you don't get to choose between two technologies for a given application, then, by definition, those technologies can't be competitors.

To explain what I mean, let me start by pointing out that there are some important cases where CORBA just doesn't apply. The OMG never really defined a standard for running objects in the same process as their client, for example, while this is a critical part of COM. A more correct comparison, then, is between CORBA and Distributed COM. Both CORBA and DCOM focus on the same thing: creating and communicating with objects running on remote machines. So the real question becomes, when are you faced with a choice between DCOM and CORBA?

Suppose you've decided to build an application using distributed object technology. If your clients are Windows 9x or Windows NT machines, and your servers run NT, DCOM is the obvious choice. You certainly could go out and purchase an appropriate number of licenses for your favorite CORBA-based product and use it instead, but why would you? DCOM is free, it has reasonable security (something that's harder to find in CORBA-based products), and it has great tool support on Microsoft platforms.

If, on the other hand, you'd like to use Unix or the mainframe for your server, DCOM isn't really an option. True, Microsoft and others do sell DCOM products for operating systems other than Windows and Windows NT, but it's hard to take these products seriously. Microsoft has said publicly that COM's next release, COM+, won't be available anywhere except Windows and Windows NT, which means that COM on non-Microsoft systems is already becoming legacy technology. But more fundamentally, do you really believe that Microsoft cares about operating systems other than its own? While it's plausible that they're interested in connecting to existing applications and data on those systems, it's much less believable that Microsoft will help you build new business logic on those systems. All of this means that choosing to build a new server application on non-Microsoft platforms using DCOM, while technically possible, is a very risky choice.

So here's the very simple decision tree for building distributed object applications: If both client and server run Microsoft operating systems, use DCOM. If not, use a CORBA-based product. Once you've chosen the operating systems, the choice of a distributed object technology is already implied. The apparent competition between DCOM and CORBA is really just an artifact of a much more titanic struggle: the fight between Windows NT and everything else.

One final note: The COM vs. CORBA battle gets so much attention that I sometimes think other middleware choices don't get the consideration they deserve. In particular, there are plenty of situations where message queuing middleware, such as IBM's MQSeries, makes much more sense then either COM or CORBA. And some projects that are built using distributed objects might have been doable as Web-based applications instead. Despite the hype around objects, there are other choices worth considering than just COM or CORBA. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at