Are We There Yet?

In most types of competition, there comes a point at which it becomes fairly clear who the winner will be. The games over distributed objects have been going on for six long years, however, and there are still no clear winners. Don't you think we develop ers have waited long enough?

Don't get me wrong. I'm a big fan of distributed objects, and I understand the value they bring to the realm of client/server development, as well as their potential on the Internet. However, we've yet to achieve the seamless interoperability goals set f orth six years ago (that's 42 in dog and client/server years), when the Object Management Group (OMG) began work on the first Common Object Request Broker Architecture (CORBA) specification. It's been three years since Microsoft proposed its component ob ject model (COM).

Although the press greeted the CORBA specification with much hoopla, today there is little information to be found. What's more, distributed objects receive less and less interest at conferences, within the trade press, and from developers. At issue is t he slow-moving CORBA specification, the lack of widespread acceptance of commercial Object Request Brokers (ORBs) based on CORBA, and the lack of mainstream development tools that are using CORBA distributed objects.

OpenDoc, for example, a CORBA-based component architecture created by several industry sponsors (including IBM Corp. and Apple Computer Inc.), has yet to receive wide tool support. Without providing developers with the ability to use OpenDoc components e asily, especially in mainstream Windows environments, its future is grim. Other distributed object vendors, including PostModern Computing Technologies Inc. (which recently merged with Visigenic Software Inc.), IBM, and Sun Microsystems Inc., have yet to capture hearts and minds although their distributed objects have been available for over three years.

The CORBA dream could be coming to a quick close now that Windows NT 4.0 is out and about. Although the operating system basically puts a new Windows 95 face on an old architecture, the inclusion of the Distributed Component Object Model (DCOM, formerly known as Network OLE) mechanism could finally bring distributed objects into the mainstream. DCOM could also become the plumbing and wiring for Microsoft's Internet-enabled ActiveX components.

Microsoft's long-awaited dream to take the lion's share of the distributed object market might very well come true, despite the fact that DCOM's base architecture is largely inferior to CORBA. Clearly, we are at a crossroads in the world of distributed c omputing.

Promises Made

The OMG was founded for the sole purpose of creating a distributed object standard and thus fulfilling the promises of distributed objects. Over 300 vendors signed up with the OMG initially, including Microsoft (albeit late in the game). In the fall of 1 990 I received a copy of the first published Object Management Architecture Guide that defined the initial architecture. It divided the architecture into four main components: the object request broker (ORB), object services, common facilities, and appli cation objects. Although these concepts relate more to the OMG's view of the world, these features are found in Microsoft's DCOM as well.

An ORB, simply put, is an engine that can communicate with other local or remote objects by using a common interface and network protocol (such as TCP/IP). ORBs can make requests to other ORBs; they can also process responses. The beauty of ORBs is that all of these processes happen behind the scenes, hidden from the user and the client/server application. The idea is to guarantee portability and interoperability of all application objects, even objects that exist on various connected computers. The OMG 's CORBA defines how these objects interface with each other.

ORB interfaces are defined via an Interface Definition Language (IDL). The IDL defines the interface between one object and the next. OLE (DCOM) uses a similar mechanism, known as the ODL (Object Definition Language).

Object Services are basically just a group of services that use object interfaces. They provide a base set of services encapsulated within the ORBs. In other words, Object Services augment the base functionality of the ORB.

Object Services enable ORBs to provide functions such as security, transaction management, and exchanging data. Common Facilities are a collection of services that relate more to clients than to the server. Component Document Facilities (such as those of fered by OpenDoc) are a good example of Common Facilities. Common Facilities are optional, but Object Services are mandated for CORBA. Application Objects, as their name implies, are objects that exist in support of a particular application. Developers d efine these objects using the IDL so that the objects can communicate with other CORBA-compliant ORBs.

The basic problem with the OMG and CORBA is that they are too late, too little, and too complicated. In the early '90s, the OMG came up with the CORBA 1.1 (and later 1.2) specification. Although it was a good start, the specification did not provide enou gh detail to let ORB vendors build objects that could communicate with other vendors' objects.

This inability to communicate led to scenarios like this one: IBM's original System Object Model (SOM) and Distributed SOM (DSOM), a CORBA 1.1-compliant ORB, will not work with other CORBA 1.1-compliant ORBs such as those sold by PostModern Computing or Iona Technologies Inc. Therefore, the value that the ORB vendors provided developers was severely limited by the ORBs' inability to work and play well with other objects.

The CORBA 2.0 specification that was released over two years ago accomplishes what CORBA 1.1 did not. CORBA 2.0 provides enough detail, especially when you consider the object-to-object communications links, to enable two ORBs from two or more vendors to work together. Meanwhile, commercial ORBs (from Iona, IBM, and Digital Equipment Corp.) based on CORBA 2.0 recently hit the streets after six years of work. The question is: Is it too late?

When creating a successful specification and attracting vendors to sell promotional products, the real issue at hand is timing. The OMG "design by committee" approach to building the specification means that the process - from the press-release phase, to finding a specification that everyone can agree on, to commercially available products - is much too long. This slow pace is caused by the inevitable infighting that occurs as various vendors promote their own agendas.

The result of this time-consuming approach was that mainstream client/server developers became weary of waiting for distributed objects to become a reality. Tool support was (and is) virtually nonexistent, especially in the Windows world where most clien t/server development was and is still taking place.

Microsoft Is Taking Over

In the second or current phase of exposing us to its version of distributed objects, Microsoft plans to allow OLE automation services as they exist today to reach across networks. This capability is the heart of DCOM: the ability of OLE-enabled applicati ons to connect to other OLE-enabled applications across a network - as easily as they work on the same machine.

With the recent release of Windows NT 4.0 DCOM, it's clear that Microsoft plans to support the distributed object concept by building the infrastructure into the underlying operating system, rather than by selling ORBs. Client/server applications that co mmunicate through a common interface have seamless access to other application services, local or remote, using DCOM. There are some tradeoffs: Unlike other ORB vendors that support a variety of platforms, DCOM is married to Microsoft Windows 95 and Wind ows NT. Although there has been a push to provide DCOM support for Unix and the Macintosh, I would not bet a system on DCOM support for those environments just yet. For the heterogeneous computing environments, CORBA-based ORBs are a much better solution . Developers may also employ DCOM-to-CORBA links to integrate such systems.

For those of you who are afraid that Microsoft will own the standard and who fear that there will not be an open consortium (as is the case with CORBA), Microsoft has thought of that. At press time, Microsoft announced plans for fulfilling its vision of openness for ActiveX (and DCOM) by moving the specifications and appropriate technology to an industry-standards body, the details of which were still being worked out when this article went to press. This group is described by Microsoft as a customer-dr iven organization; Microsoft is just one of the many members that participate in the decision-making. It's still unclear how much Microsoft will continue to drive the DCOM standard, but this group is a step in the right direction.

Remember, this is just the beginning. DCOM application development is the direction of today's client/server development tools, and I suspect that 1997 could be the year of DCOM. It will also be the last chance for distributed objects to gain a strong foothold in client/server. If standardized distributed objects don't happen in 1997, I can't wait any longer.