sions of type versioning and reference counting pervade newsgroups and lead to bitter resentment on both sides. And you're in the middle, trying to make a decision about which platform to base your next project on.
The traditional logic has said something like, "Use CORBA whenever you need to talk to a non-Windows platform; use DCOM for Windows-only systems." But things have changed. Microsoft turned the management of DCOM over to the Open Group and introduced the Transaction Server as part of its Active Platform. In addition, German giant Software AG is porting DCOM to many non-Windows platforms. So much for CORBA proponents' assertions about DCOM's openness and scalability. Similarly, the incredible popularity of Java, and Netscape's incorporation of an Internet Interoperable ORB Protocol (IIOP, pronounced "eye-op") ORB in its browser,
are countering some of Active Platform's statements about the availability of CORBA ORBs. Traditional logic just fell apart.
Where once CORBA had complete dominance in cross-platform environments, DCOM is blazing its way in. Where once COM was the desktop solution, Netscape has given CORBA an inroad. Independent software vendors (ISVs) and corporate software developers both need to consider (or reconsider) their distributed component strategies. If that happens, we could see more environments that use both, through either gateways or wrappers.
Lay Down Your Weapons
The CORBA and DCOM camps alternately lance and bludgeon each other with assertions about each other's technology. In the bludgeon category are sweeping generalizations. "[DCOM] is going to be challenged in multiplatform environments," says Colin Newman, vice president of marketing at Iona, a leading ORB vendor. Possibly. But Software AG is porting DCOM to Solaris, HP-UX, MVS, and Linux (to name a few), and Digital is
porting it to Digital Unix and OpenVMS. "CORBA is
not
more mature than DCOM," says Richard Dumas, SunSoft's product manager for Neo, another CORBA implementation. "We're talking about specifications that more than 600 companies have been working on for eight years." Oh yeah? "CORBA is
not
more mature than COM," says Mark Ryland, technical evangelist at Microsoft. "In fact, COM was there first." It didn't, however, have distributed capabilities until last year.
In the lance category are specific, sometimes picayune assertions about each other's technology. "CORBA doesn't support versioning of types," says Microsoft's Ryland. "Future versions of objects won't necessarily be compatible with existing interfaces." If you know that, you probably know that Microsoft's answer was an effective but Draconian method that required future versions always to support the past versions' interfaces, in effect creating multiple interfaces that can do pretty much the same thing. "Reference counting [in D
COM] is a bad way to do memory management with respect to distributed garbage collection," says Patrick Ravenel, principal software engineer of the architecture group at ORB vendor Expersoft. "Unless an application pings clients, it can't know how many outstanding references there are for its server objects." True, but according to Microsoft, the ping traffic isn't that great, and CORBA's solution isn't much better.
It seems that for every statement one camp makes, the other can respond reasonably. Going about an evaluation of CORBA and DCOM at this level simply isn't helpful. Even simple descriptions can become occluded: When we tried to write a simple explanation of how CORBA works, we inadvertently generated a small cloud of controversy. (Natural language couldn't express clearly enough how object invocation works.)
Leveling the Playing Field
"The technical nitpicking just doesn't matter," says Richard Esmond, chief technology officer and executive vice president of Diamond H
ead Software, an imaging system software vendor. DCOM and CORBA provide similar enough services that a debate at this level is really interesting only to a very small number of people -- like the architects of the two technologies. For everyday use, the debate centers around much simpler issues, like what operating systems you need to support, what languages you want to program in, and (yes) your political feelings toward Microsoft and standards bodies.
When it comes to platform support, CORBA holds an edge. Not only can you get an ORB for every popular operating system, but for some OSes you can get two or four different vendors' ORBs. Native implementations of CORBA are available on just about every platform. You can get Digital's ObjectBroker, for example, on 20 platforms including Mac OS, AIX, MVS, OS/2 Warp, OS/400, Digital Unix, OpenVMS, HP-UX, Windows 3.x, Windows 95, and Windows NT. ObjectBroker is an extreme example of how cross-platform CORBA is, but much the same story is true for Iona's Orb
ix, Visigenic's VisiBroker, Expersoft's PowerBroker CORBAplus, and IBM's System Object Model (SOM). Most of these vendors are also working on Java versions of their ORBs, so expect to see CORBA on any platform that has a Java virtual machine.
"CORBA is open," says Dan Gilfix, business product manager for Digital's ObjectBroker. But so, he continues, is DCOM. Now that Microsoft has turned management of the DCOM standard over to the Open Group, expect CORBA's total domination in multiplatform environments to come under attack. Currently released for Windows 95 and NT, DCOM will be making its way to other platforms this year. Software AG and Digital are both doing the ports. Expect general releases of DCOM for Solaris, MVS, Linux for Intel, Digital Unix, HP-UX, AIX, SCO Unix, and OpenVMS throughout the year, according to evangelist Ryland at Microsoft. This rapid port schedule should do a lot to narrow CORBA's cross-platform lead.
So which standard is more open? One of the big differences in the stan
dards is how they're implemented. CORBA implementations work from a set of written standards. DCOM proponents say that working from a written standard means there can be incompatible interpretations of the standard -- interpretations that actually lock you into a single vendor solution. DCOM implementations work from source code licensed either from Microsoft or from the Open Group. CORBA proponents say that Microsoft controls the source code so it's not really open. Further, if there's a difference between the written DCOM standard and the source code, the source code stands as correct. Both the OMG and the Open Group require implementers to pass a set of validation tests.
After operating system, choice of programming language is probably the largest factor that will affect your decision. Probably the clearest case is if you have a company stocked with Smalltalk programmers. Then you're going to be looking strongly at CORBA. Otherwise, it's another mess. For example, Visual Basic works with ActiveX and
generally prefers DCOM. But by spending some extra time and effort, you can get tools from vendors such as HP and Iona that enable you to access
CORBA objects
from Visual Basic (with varying degrees of success).
IIOP and Netscape
Talk to people about DCOM and CORBA and you'll hear dozens of variations on the theme "Microsoft on the desktop, OMG on the servers." With Microsoft aggressively opening DCOM and having it ported to myriad OSes, the first part of that assertion is changing. Netscape's agreement to incorporate Visigenic's VisiBroker ORB in the Communicator browser can change the second. "The Internet is putting a lot of energy back into CORBA," says Eckart Walther, product marketing manager for Netscape's Open Network Environment (ONE).
One of the problems that confronts CORBA on an almost daily basis is that it's not ubiquitous on the desktop. Worse, with the exception of IBM's SOM, you have to pay to extend your OS with an ORB. By contrast, Micr
osoft has placed the seeds of COM in every copy of Windows, and DCOM will soon follow. And until 1994, there was no standard way for one vendor's ORB to talk to another's.
But in 1994, the OMG ratified the Internet Interoperable ORB Protocol. This specification, which virtually every ORB vendor claims to support (whether they really do is another matter), enables objects created with one vendor's development tools to talk to objects created with another vendor's. In other words, the ORBs have a standard protocol for talking to each other. "IIOP was meant to be the least common denominator for ORB interoperability, and it's good for that," says Expersoft's Ravenel. "However, it isn't the most efficient or highest-performing protocol that you could use. ORB-specific protocols can be made to exhibit higher performance and higher reliability, but not at the same time."
By itself, IIOP is an important standard if you are considering CORBA. On July 30, 1996, it became important to every user of Netsca
pe's browser. Netscape and a small ORB vendor named Visigenic announced that VisiBroker for Java would become a standard part of every copy of Netscape's browser and its SuiteSpot server software. With one agreement, CORBA -- or at least IIOP -- became ubiquitous.
It might seem a strange marriage. After all, CORBA has traditionally been the domain of Fortune 500 companies that need solutions for integrating multiple desktop OSes with multiple server OSes and mainframes. But, when you look at it from Netscape's perspective, the requirements aren't so different. "We have to run on 17 platforms," says Netscape's Walther. "CORBA is a multiplatform integration solution. Although ActiveX is being standardized, it's the protocol [that's being standardized], not the services." (See "Will Netscape Set the Standard?," March BYTE.)
With a Java ORB inside every copy of Netscape, client applets have an efficient way to connect to server objects to invoke their services. For example, Wells Fargo Bank in San Fr
ancisco reengineered its infrastructure to use CORBA. This system integrated many of its services to be accessible from one interface. Currently, only employees of the bank can use the interface, but it's possible that a customer-oriented interface could access the ORB back end from inside a Netscape browser. Wells Fargo wouldn't have to redesign its back end at all -- just write a simple new front-end applet that would talk to the Visigenic ORB in Netscape Navigator.
What's holding back such advances? First, the version of Netscape's browser with the integrated ORB (called Netscape Communicator) didn't become available in beta form until the beginning of this year. Second, and possibly more important, there's currently no standard CORBA interface definition language (IDL) mapping to Java. That means applications written to take advantage of the Visigenic VisiBroker ORB in Communicator might not necessarily be able to talk to other client-side ORBs. The OMG is working on a mapping specification; the sub
mission to the OMG was expected to be ratified last month.
Once the IDL-to-Java mapping is ratified, you'll be able to choose from a variety of Java ORBs. Many of the ORB vendors are working on or have finished Java ports of their ORBs. Sun's Joe, for example, currently provides an IDL-to-Java mapping and a Java ORB. In theory, you could run Joe as an applet inside Netscape. Iona also has a Java version of Orbix (called OrbixWeb Java), and HP is working on a Java version of ORB+. Expect to see lots more Java ORBs when the standard is ratified. Until then, however, you might want to be a little careful about developing for one particular Java ORB.
So what can you do with a Java ORB that's special? For starters, "We're going to make LDAP [Lightweight Directory Access Protocol] available through IIOP," says Netscape's Walther. "You'll be able to register an object in the LDAP directory," making it easy to find. Also, says Walther, expect IIOP over Secure Sockets Layer (SSL) to have shipped in the fi
rst quarter of 1997, creating a secure transport for IIOP transactions.
There are still a few questions to be resolved, however. First, there's the performance question: IIOP isn't known as the fastest communication method, and Java is no speed demon itself. Is the speed of the ORB going to be a hindrance? According to Walther, performance won't be a problem -- the round trip to get an acknowledgment is measured in the single-digit milliseconds. So much for that.
A second question has to do with Microsoft's Internet Explorer (IE). Microsoft has aggressively matched Netscape Navigator's feature list. So, if the ORB-browser integration thing really takes off, won't Microsoft just integrate an ORB into IE? "We have one component architecture. We have the DCOM
stub
which offers equivalent functionality already in IE," says Microsoft's Cornelius Willis, group product manager, Internet Platforms. This enables Microsoft to scale the model from components running in the browser to co
mponents on multiple servers, even scripting transactions in the Transaction Server. Willis says the big problem that Netscape is going to have is multiple component architectures: Internet Foundation Classes (IFC), Java-Beans, ActiveX, IIOP, Java remote method invocation, and LiveConnect. Having these different models is going to make it difficult to move component development knowledge across different parts of the network, from client to server.
Of course, nothing is ever that simple. Across the diversity of the Internet, the likelihood of every company supporting the same single architecture is close to zero. So while there may be an implementation difficulty, Netscape could have better support for the diversity of the Internet. The question then becomes whether a single-minded focus on one architecture from Microsoft will gain enough mind and market share to marginalize other architectures.
Although Microsoft won't integrate an ORB into IE, you'll still be able to run any ORB written in Java
in it. And if you don't fancy running Java inside IE, you may even find ORBs implemented as ActiveX extensions: "We'd consider implementing IIOP as an ActiveX control," says Iona's Colin Newman.
Choose Both?
The choice between CORBA and DCOM could be too hard to make. So maybe you should choose both. If, for example, you like COM on the desktop and CORBA on the server, you can bridge them with products from many of the ORB vendors including Digital, HP, Iona, and SunSoft. Or you could wrapper one within the other.
Diamond Head produces imaging and work-flow solutions. Currently, its ImageBASIC product is based on COM, but Diamond Head is going to implement CORBA as a wrapper by the third quarter of this year. "For the longest time, we were thinking of doing the objects in CORBA and wrapping them through DCOM," says Esmond. "But CORBA was too slow. With CORBA, you have to deploy an ORB on each client plus an ORB at a server. Each machine has to be configured and tested. So you ra
ise the bar of effort of what you have to do to get your system deployed."
But a funny thing happened on the way to the CORBA port: Microsoft released some astounding tools for network communication. First among these is the Transaction Server. Esmond says Transaction Server will give ImageBASIC a level of security and reliability that its current network transport doesn't have. In addition, Microsoft is releasing a development suite, called Visual Studio 97, that includes Visual InterDev, Visual Basic, Visual C++, Visual J++, and Visual FoxPro, and it enables you to create distributed applications easily with Wizard-like controls. "Using VBScript or JavaScript, you can script components regardless of location, regardless of source-code language," says Microsoft's Willis.
Where, What, When, Whom
If you're looking at building a distributed application, you're going to have to answer four questions: Where do you want it deployed, what language do you want to write it in, when do
you need it, and whom do you trust?
Where? According to virtually everyone we talked to -- even the CORBA vendors -- Windows-only sites have no reason to consider CORBA right now. Similarly, shops with no Windows at all have no reason to consider developing for DCOM. Mixed marriages are somewhat more complicated. Right now, CORBA holds an edge in the cross-platform world, with more than 20 OSes supported. And Netscape's IIOP support gives you the capability to run the same applet, unchanged, on 17 platforms. But things change, and DCOM is going to come out on myriad OSes by the end of 1997 if Software AG's timetable holds. And if DCOM really becomes cross-platform, it could really hit CORBA hard because, according to Diamond Head's Esmond, "The strength of the ActiveX option is really the incredible tools that Microsoft is offering and the thousands of controls that are currently available from third-party partners."
And that brings us to the what and when questions at the same time. What languag
e do you want to use, and when do you need your application? Few people would argue that the development tools for CORBA are superior in usability and ubiquity to Microsoft's. For many developers, C++ means Visual C++. But if you need a cross-platform application right now, you'll choose CORBA because, with the exception of Solaris and Windows, DCOM isn't soup yet.
The last question, for many, is the most fundamental: Whom do you trust? Some people despise Microsoft out of principle. "If this is a religion, Microsoft is the Antichrist," says Microsoft's Willis. Others view DCOM as a single-vendor solution and fear lock-in. Yet others sneer at the standards-making process at the Object Management Group, considering it too slow and impractical. They like the high availability and level of integration of Microsoft's tools.
There is no capital "T" truth to lead you to the correct choice. A year ago, CORBA held a decisive lead over DCOM in many areas -- cross-platform support, openness, and especially
networkability. But Microsoft's Active Platform strategy is narrowing the gap. So far, Active Platform's main inroads have been in Windows NT and one very popular version of Unix. But by the end of the year, that, too, could change. How comfortable are you with Microsoft?
Where to Find
Digital Equipment Corp.
Maynard, MA
Phone: (508) 493-5111
Internet: http://www.digital.com/objectbroker/
Distributing Components
