Is DCOM Truly The Object Of Middleware's Desire? By Anthony Frey   Distributed object technology is, without a doubt, the shape of middleware in the days to come. It provides the communications bus that enables plug-and-play interoperation of distributed components across diverse networks and operating systems, allowing them to be easily assembled, reused and managed. While the rest of the industry continues to back Common Object Request Broker Architecture (COR BA) as the standard object bus, Microsoft wants to define that shape with its Distributed Component Object Model (DCOM). We recently tested five of the latest CORBA-based Object Request Brokers (ORBs) (see "Into ORBit," March 1, page 51), and at the time, we intentionally omitted DCOM because it didn't follow the same object model. Testing it then would have clouded the differences among ORB products, and biased DCOM toward fitting the CORBA model. It's now time to look at DCOM on its own while making comparisons to CORBA products where appropriate. To view the Report card. We tested Microsoft Corp.'s DCOM for Windows NT and Windows95 at Network Computing's University of Wisconsin lab in Madison. To make it even more interesting, we also took an early look at Software AG's DCOM port. Using our Test TCP (TTCP), an application rewritten for the Component Object Model (COM), we cross-tested these versions of DCOM for interoperability and management. We found that Microsoft has taken the bull by the horns to produce an extremely effective and practical distributed object technology implementation. Cross-platform support is still limited, but by focusing on easy-to-use management tools while basing the transport and security mechanisms on familiar Distributed Computing Environment (DCE) standards, Microsoft has made the technology accessible to network use. When compared to our ORB testing criteria, Microsoft DCOM places in the middle of the pack if you factor in CORBA 2.0 compliance. However, if you remove this category--which truly doesn't apply to DCOM--then it positively shines; especially in the areas of ease of use, management and security. Microsoft Corp. Distributed Component Object Model With j ust a few key tools, Microsoft's DCOM makes managing distributed components much less of a challenge. Unlike simple service daemons, distributed components require numerous options, such as invocation policy and threading model to be configured for defining the operating environment. These options can't be maintained in the file system because the information needs to be dynamically available for client calls. We bega n our testing of DCOM on Windows NT Server 4.0 and found that a large part of its management involves the configuration of actual components. Microsoft's primary tool for this task is called DCOMCNFG.EXE. Using DCOMCNFG, we were presented with a list of components that were preregistered (during the installation of various Microsoft products), such as Object Linking and Embedding (OLE) servers. Additional tabs let us enable or disable DCOM on the host and set Access, Launch and Configuration permissions for each user. DCOMCNFG would be more useful if it allowed remote configuration of D COM settings on other hosts by selecting the host from the domain, similar to the functionality offered by the Windows Registry Editor. On Windows95, the configuration tool requires user-level security to be enabled, which subsequently requires Windows95 clients to be authenticated on a Windows NT Server or Domain. The Windows95 version doesn't let you set launch or default configuration permission, but essentially, it's the same tool.

DCOM And Microsoft Transaction Server Updated July 10, 1997