Distributed Component Object Model (DCOM) won't start shipping until late this year, but an alternative to it already exists. The Object Management Group (OMG), which now has about 600 vendor and user members, including Microsoft, has developed a standard called CORBA that defines how distributed objects can communicate over a network.
CORBA grew out of a specification started seven years ago by a group of vendors that included Hewlett-Packard Co, Novell, Sun Microsystems, IBM, and Digital Equipment. They happened to choose TCP/IP as CORBA's underlying network protocol, which was fortuitous because that's what the Internet runs on.
CORBA and DCOM both use an object request broker (ORB) to find objects or applications and send communications between them over a network. Both DCOM and CORBA replace an unstandardised way of communicating between software, which required knowledge of what was on the other side: client or server, type of remote procedure call, and path, says Chris Stone, OMG's director.
DCOM's detractors criticise Microsoft for basing DCOM on OLE, which they say is complicated to use, works slowly, contains too much code, and involves too many APIs.
CORBA works by sending out an asynchronous remote procedure call, meaning that the originating machine can take care of other processing until its request comes back. The ORB finds its target object somewhere on the network, makes sure it executes, and then tells the sender that it executed. The interfaces between the objects and the ORB are the same, regardless of which machine the software is running on, because they all conform to the CORBA interface description language.
Microsoft's DCOM, on the other hand, uses a synchronous ORB to find OLE-enabled programs, which it launches on a remote machine (provided that it has access). It returns the information to the requester, which then reads it with a reader or the actual application.
DCOM will appear in Windows NT in the fourth quarter and in Windows 95 at year's end. A Macintosh version is scheduled to ship in the first half of next year. Microsoft and Software AG recently announced that Software AG is working on versions of DCOM for various flavours of Unix. These will be available sometime in the second half of this year or early next year, says Nat Brown, Microsoft's DCOM project team leader.
But DCOM will work best with systems that already support OLE, and that's largely a Windows world, according to some users and analysts. CORBA is designed to work on a variety of systems, whereas DCOM and OLE were designed from the beginning to work with Windows.
On the other hand, CORBA and DCOM will work together to some extent. Third parties are creating gateways that will translate CORBA requests into DCOM requests and vice versa, so a CORBA application and an OLE application can communicate.
Some critics of DCOM say it lacks the high-level services found in CORBA. CORBA is object-oriented, defining characteristics such as inheritance, polymorphism, and encapsulation, whereas DCOM calls and launches applications and data.
Microsoft is working around some of DCOM's limitations. For example, DCOM will allow programmers to specify how many values a program will return at a time, so the requester doesn't have to wait for, say, a huge database to be sent over the network before it can do something else, Brown says.
Eventually, Microsoft will need to adopt an asynchronous protocol, says Don DePalma, a senior analyst with Forrester Research, in Cambridge, Massachusetts.
"People will start hitting problems when they write applications that are either connected intermittently or connected sporadically," DePalma says.
A few months ago, IS managers complained that, because it is based on OLE, DCOM (then known as Network OLE) would require users to have and launch an application on their desktop before they could read data from the same application residing on another machine. Microsoft plans to address this concern by creating run-time modules, or "readers", for Microsoft Office and making the readers available at no charge.
This approach is similar to CORBA's, which also uses run-time modules to read various file formats.
Whether the OLE architecture will be capable of handling mission-critical systems with large amounts of traffic remains to be seen.
"The OLE world is desktop-centric," says Bud Tribble, vice-president of Internet strategy for Sun. "You're talking about documents with images and objects embedded in them, such as a spreadsheet with a word processor embedded in it. It is a stretch to take that to the point where you could have an airline reservation system talking back to a Sabre system."
But OLE has the advantage of having a huge installed base. Many Windows applications are OLE-enabled, and all of Microsoft's tools, as well as third-party development environments such as Borland International's Delphi, use it. Even if DCOM isn't the best way to distribute data around a network, it will certainly be convenient for corporations that use a lot of Windows products.
Any program that supports OLE will work with DCOM without any changes, Brown says. OLE programs feature identifiers - similar to name tags - that other OLE programs can read, and DCOM uses these identifiers to find programs over a network. That means the programs accessed by the ORB don't have to know a thing about DCOM. As soon as NT supports DCOM, any OLE application will be capable of using it.
In the meantime, several vendors have come out with ORBs for CORBA, including Java applets that will run under Netscape Communication's Navigator. So if a developer is creating a Java applet that needs to communicate with a server, the company could create a connection. If a user clicks on a Web page that includes such an applet, the program can get data off a server without the user realising he or she is using CORBA.
Many corporations have yet to choose between CORBA and DCOM, but that's not surprising, because DCOM isn't out yet.
One large Midwestern manufacturer had been developing CORBA projects for several years but abandoned its development when it found that the early implementations were more appropriate for workgroup projects than the enterprise-wide applications the company needed. But now that CORBA has enterprise-wide services in place, says a member of the company's advanced technology group, the company is taking up CORBA projects with renewed enthusiasm. It wants to manage the back end of its client/server applications, including Web-based applications for sharing data with business partners, and has been working with a beta copy of DCOM, which it says is inefficient. Its limited levels of service also make it more of a workgroup than an enterprise solution.
At least one Microsoft shop, a Fortune 500 food company, has chosen DCOM.
"We need the flexibility in our business processes of having distributed objects and the ability to reuse objects and call them as needed," the company's IS manager says.
The upshot is that most Windows users, particularly Visual Basic programmers, will probably use DCOM when they need it to run, for example, queries against a database on another machine. Corporations that rely on mainframes and Unix systems and develop their own enterprise-wide applications are likely to go with CORBA, analysts agree. Windows ISVs will make use of DCOM, whereas Unix, Macintosh, minicomputer, and mainframe vendors have already embraced CORBA, and they are adding it to their OSes and software. OpenDoc, the multimedia development environment created by IBM and Apple Computer, uses CORBA for messaging.
"Out of the chute, the CORBA technology is much more scalable to the kinds of things large organisations are going to want to do," DePalma says.
The result is likely to be a split between the Windows world and everything else, just as today OS/2, Unix, and Windows developers have their separate camps. But the two worlds will be able to communicate with the translation layer the OMG is developing for OLE.