Network Computingwww.networkcomputing.com

At times we found Microsoft's tools somewhat crude, because they didn't let us configure all possible aspects o f the DCOM infrastructure. For example, they don't expose essential network configuration options. Also, even though DCOM supports multiple protocols, including TCP/IP, IPX/S PX and Named Pipes, we could only change the default protocol by modifying the registry entry HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc. (Current CORBA ORBs only support TCP/IP-based Internet Inter-Orb Protocol (IIOP) or proprietary inter-ORB protocols, so protocol configuration is not an issue). Nevertheless, it's a start.

Underneath DCOM's Hood Microsoft calls DCOM's core network protocol Object Remote Procedure Call (ORPC). It comprises a number of extensions to DCE RPCs. Chief among them is an extension that adds a primitive data type to support object references. This data type is necessary to support the interface model inherent to DCOM--it's not another Microsoft maneuver to subvert a standard. All Microsoft implementations of DCOM utilize the same RPC mechanism as the rest of the OS, however, this is not necessarily the case with other ports of DCOM.

Unfortunately, Microsoft's strong foundation is undermined by the DCOM reference counting design that requires active objects to be regularly pinged over the network. Reference counting manages the life cycle of instantiated components. With it, an object increments a counter whenever an instance is created and decrements the counter whenever an instance is destroyed. DCOM has no way of knowing when a client object has abruptly terminated, therefore, it must verify that the object reference held by the client is still active by pinging it. It's easy to picture how a large number of active objects could easily swamp the network with traffic.

The DCOM specification also provides for some sophisticated reference counting and pinging optimizations, such as updating multiple interface reference counts with a single call and creating sets of objects that can be pinged simultaneously.

We found the network performance of DCOM to be comparable to that of CORBA's IIOP. Each exhibits reasonable request-reply response times, even on a 10-Mbps network. But until either of these technologies can demonstrate a standard method of communicating over an async hronous transport, operation will be limited to LANs and server backbones. Corporate WANs and Internet use will be excluded because of the high rate or synchronous request-reply activity.

This could change with Microsoft's forthcoming Message Queue Server (MSQS), previously known as Falcon, if it's fully integrated into the Windows networking stack as a drop-in replacement for DCOM. Microsoft's Transaction Server is completely dependent on DCOM, making it an application that could benefit from MSQS on WANs and the Internet.

In addition, we think the concerns over whether DCOM was a viable evolution of Microsoft's OLE/COM technology to be unfounded. The COM revision of OLE has proven to be an efficient object model for a single host environment. Substantial portions of the current Windows OS are built on COM. Putting that mod el on top of a standard RPC mechanism was successful.

A Jump on CORBA DCOM has the jump on CORBA in terms of its flexible security implementation. With CORBA, the security specification has only recently been completed. This has left ORB vendors to come up with their own incompatible security implementations. Although DCOM's actual security managers are platform-dependent, the application programming interface (API) itself has been available since DCOM's inception. The Win32 security manager allows both activation and call-level authorization from Windows Domain, Novell and DCE Kerberos authenticators. We appreciated the fact that we could use readily available security providers to enhance the component management.

As distributed object technologies develop, having a core set of component services available that applications can build without recreating themselves, will become vitally important. Here DCOM has slightly more to offer out of the box, but it suffers from the same overall lack of s ervices that CORBA does. By this we mean services that are ready now, not simply drawn-up specifications waiting to be implemented.