Network Computingwww.networkcomputing.com

As a corollary to the lack of services, we could find no examples of existing applications that make use of DCOM in a useful manner (other than the sample Network Clipboard provided on the DCOM Web site). The registered COM applications we found were primarily GUI-based OLE controls intended to support local installed applications.

Easy to Run, But Where? If you look for it, you'll find that DCOM is there, but somewhat difficult to find. You won't find a network services option to install under the Windows NT network conf iguration control panel and you won't find it listed anywhere in the installed applications under the Start menu. Under Windows NT, DCOM is already there; you'll have to trust Microsoft. Under Windows95, however, you'll need to download DCOM95.

EXE and DCM95CFG.EXE from Microsoft's Web site and run through the installation. DCOM will only run on 32-bit Windows platforms, so don't expect support for 3.x.

We found that executing DCOM clients and servers couldn't be easier. We ran TTCP across NT and Win95 machines without a hitch. Of course, there are essentially no interoperability issues between the Win95 and NT platforms. Installing a server executable on the server host, setting two registry keys that enable automatic execution, and invoking the client was all that was necessary to successfully launch the client/server applicati on.

A Port by Any Other Name Not completely convinced that DCOM was the perfect distributed object middleware, we decided to throw together Software AG's DCOM For the Enterprise (FTE) for SPARC Solaris 2.5 with DCOM on Windows NT. It was then we discovered DCOM's most significant failing.

Our first step with the Software AG port was to test operation between like Solaris hosts. This went well, just as it did with DCOM running between two Windows hosts. We also managed to successfully interoperate Windows and Solaris DCOM when the server executable was running on the Solaris host. However, after repeated attempts and several debugging cycles, we could not get the Solaris client to call the Windows NT server. With this beta release of Software AG's port, Windows NT requires Service Packs 1, 2 and a special DCOM patch all to be installed to interoperate. (Final releases of Software AG's product are not expected to have this requirement.) As an aside, it was eerie seeing a Motif-based Registry Edit or running on our Solaris machine.

Software AG has aggressive plans to port DCOM to many operating systems, including beta versions of Solaris 2.5, Digital Unix 4.0, MVS 5.22, O/S3 90 and Linux 2.0, by the time you read this. Betas for HP-UX, AIX, UnixWare, O/S400, VMS and Sinix (a Unix variant) should be available later this quarter.

We do question whether DCOM will have the facilities to efficiently scale across multiple hosts. By default, CORBA shares this weakness, but many CORBA vendors have provided solutions that enable a load-balanced and fault-tolerant distribution of objects. CORBA ORBs route active object information among themselves to satisfy client requests, a good example being Visigenic Software's VisiBroker.

Distributed objects tend to consume more system resources from overhead due to invocation, data formatting and marshaling. Distributing server objects across multiple physical servers is essential to efficient scaling. DCOM has a head start on the tools that can manage that typ e of infrastructure, but it lacks the negotiating capability.

An Offer You Can't Refuse Whether or not to use DCOM really isn't an issue. There's no doubt that you will, because DCOM is a core technology for Microsoft's Windows platforms. It's integrated into Windows NT 4.0 (Server and Workstation) and is available as a free download from Microsoft's Web site for Windows95. It will become even more prevalent as Microsoft and its partners develop applications based on DCOM. Both Transaction Server and Internet Information Server, for example, rely on DCOM for their intermachine communication.