NT 4.0’s Distributed Component Object Model

Distributing hidden power to object-based programming

One of the most exciting features in Windows NT 4.0 is also one ofthe least visible: Distributed Component Object Model (DCOM), formerly NetworkObject Linking and Embedding (OLE--I discuss NT 4.0 features of this facilityin, "Windows NT 4.0," in the April issue). This protocol lets softwarecomponents communicate directly with each other over a network in a securemanner. DCOM works in the background with NT's transport and calling mechanism,has no user interface besides a dialog for changing settings, and performsautomatically when a system administrator properly configures it. In fact,Microsoft designed DCOM to be transparent to users and application programs.

This protocol lets you build distributed applications using standardsoftware components from off-the-shelf or third-party vendor products or commondevelopment tools such as Microsoft's Visual C++ and Visual Basic (VB). DCOMworks under NT 4.0's Service Control Manager (SCM) and has its own configurationutility. If you're creating distributed applications, DCOM can provide analternative to VB's remote automation (RA). To help you get started developingwith DCOM, Microsoft includes some developer samples in the updated Win32software development kit (SDK).

Features
DCOM gives developers two main benefits: locationtransparency, the ability to distribute client applications without ties tolocal objects, and packaging transparency, the ability to implementin-process objects in DLLs or local or remote objects in executables (EXEs) oras Win32 services.

Despite being behind the scenes, DCOM provides some powerful features.Built on the Component Object Model (COM), an object-based programming model,DCOM adds several important extensions.

Free-Threaded Objects: DCOM enhances COM's threading support toinclude completely multithreaded (free-threaded) objects. This support is inaddition to DCOM's support for apartment-threaded and nonthreaded objects. Beaware that free-threaded objects support simultaneous calls by multiple clients,which is a key feature for developers creating scaleable server-sideapplications.

Activation/Launch Security: Using NT's access control lists (ACLs),you can specify which users can start specific object servers. Object serversinstantiate (create) in-process, local, and remote objects. By default, DCOMlets only machine administrators launch object servers from remote clients, butyou can change or override this default for individual object servers. Launchsecurity also applies to local (same machine) launch requests, which isimportant for Win32 services that typically run under the System Account. WithDCOM, if you have object servers that a remote client launches, you canconfigure them to run under a specific domain user account.

Call/Access Security: In addition to launch security, you canspecify which users can connect to the object servers. As with launch security,you can configure this feature as a machine default or on a per-server basis.This security feature also applies to local access requests. You can use accesssecurity with launch security to let a remote user access an object that theserver must launch.

Call-Level Security: DCOM supports putting security on specificproperties or methods of an object server. For example, each interface can haveits own remote procedure call (RPC) authentication, impersonation, orauthorization parameters.

SCM and Services
DCOM is available for NT 4.0 and will ship withthe Nashville update of Windows 95 this fall. For DCOM to work, it must rununder an OS with SCM (affectionately, the scum) that starts, stops, andinterrupts services (system applications that launch at startup--Win95 doesn'tsupport services). The Services applet in the NT Control Panel controls the SCM.

Support for running as a service gives an application or component severaladvantages over traditional EXEs. First, services run before a user logson and continue running as other users log on and off the system. Second, youcan locally and remotely start, stop, pause, and restart services.Third, you can configure a service to automatically run when the machine bootsor to launch when a client application requests it. Finally, you can run aservice under a specific user account, and the service can interact with thedesktop.

This last advantage (letting a service interact with the desktop to createa visible user interface and interact with a user) is complicated and a frequentsource of confusion. In NT, a service can log on using the LocalSystem accountor an NT domain account. A logged-on user, any service running underLocalSystem, or any service logged on as a specific user runs in a separatewindow station and hence on separate desktops.

The reason NT uses separate window stations and desktops involves theWindows architecture and its legacy. The Windows core consists of three majorlibraries: KERNEL, which manages memory and internal objects such as processes,threads, files, and communications ports; GDI, which manages graphical objectssuch as bitmaps and metafiles; and USER, which manages the user interface, themost obvious pieces being the actual windows and the underlying Windowsmessaging system. In 16-bit Windows, the concept of OS security doesn't exist.In 32-bit Windows, all KERNEL objects have security, but USER and GDI objectsdon't (Microsoft figured the added security would break too many applications).

Because of this lack of object-level security, Microsoft encapsulated theuser interface into separate desktops and window stations. This limitationprohibits a Win32 service from sending messages back and forth to theinteractive desktop.

Because COM makes extensive use of USER and relies on Windows messages, youcan't use COM to communicate between OLE service objects and interactive desktopobjects. Even if you could use COM, Windows would still need to switch desktopslike crazy, which would seriously degrade system performance. In retrospect,Microsoft should have moved COM into the KERNEL early on and eliminated COM'smessage-based architecture.

This situation changes with DCOM, which uses RPC transport instead ofWindows messages for over-the-wire network communication and communicationbetween desktops. Locally, services running in any account other than theLocalSystem account can impersonate a domain user, and this impersonationmechanism lets a COM object run with specific security on remote machines.Although you can configure services to interact with the desktop, they alwaysrun in a desktop and window station separate from the interactive user. Thisapproach prevents termination when the interactive user logs off. Services don'toffer any built-in performance advantages over traditional EXEs. However, you'llsee developers creating more components specifically for servers and operatingon remote machines so that they can take advantage of DCOM's benefits.

When you're developing remote applications to use services, consider somedesign points. Although one advantage a service has over a traditional EXE isthe ability to interact with the desktop, you don't want to make servicesinteractive. If you do, you'll run into several ugly design issues: What do youdo when nobody is logged on? What about when a secure screen saver is running?What if Microsoft adds the ability to have multiple users logged onsimultaneously?

In fact, Microsoft is considering removing service interactivity completelyfrom future versions of NT. If you need to output monitoring information from aservice, build it to write to the system Event Log. Other than the interactivityissue, the only restriction on Win32 services is that you can run only oneinstance of a service at a time on a particular machine.

Configuration Utility
You can configure individual object serversettings in the Win32 system Registry or by passing these settings into anapplication dynamically--through a coserverinfo structure--when you instantiatean object through code. You can manually configure Registry settings with NT4.0's dcomcnfg utility, as in Screen 1.

NT's Setup doesn't configure access to this utility, but you can finddcomcnfg in the system32 subdirectory and start it directly. (I added ashortcut to my Start Menu.) dcomcnfg lets you configure default security andconfiguration properties for all DCOM-controlled objects and configure theseproperties for individual object servers.

If you use RegEdit to look at Registry settings for object servers, youneed to be aware of DCOM's new Application ID (AppID) keys. These keys groupDCOM object configuration options in the Registry to simplify the management ofcommon settings.

In contrast to ProgID and CLSID keys, where each possible class has its ownkey, AppID groups an EXE's DCOM objects under one key for use during activationand to obtain the default access permissions. DCOM then uses the correspondingCLSID key to map the AppID keys to EXEs.

DCOM and the VB RA
Both the RA feature in VB 4.0 EnterpriseEdition and DCOM can instantiate COM object servers on remote machines. However,the similarities between DCOM and RA end there.

DCOM comes directly from the operating system, so DCOM doesn't requireadditional software or licensing as VB's RA does, and DCOM has substantiallymore security and configuration options than VB's RA. One implication of havingthe operating system provide DCOM is that a 16-bit version of DCOM doesn'texist--VB's RA includes a 16-bit client, so businesses with legacy Windows 3.xsystems that build distributed applications need to use RA at least until theapplications can talk to systems running 32-bit versions of Windows.

Although RA uses the Registry to configure settings, Microsoft stronglyencourages VB developers not to touch these entries directly and instead accessthem through the racreg32 object server. In fact, Microsoft followed its ownadvice when it created the racmgr32 configuration utility. Developers who followMicrosoft's advice will be pleased to know that NT 4.0 includes updated versionsof racrec32 and racman32 that support access to RA and DCOM settings.One final, important difference between RA and DCOM is that although RA requiresmachine names such as myserver, DCOM lets you specify the machine name in avalid universal naming convention (UNC) format, such as myserver or \myserver,or in a Domain Name System (DNS) format, such as www.server.com or135.198.33.1.

Developer Samples
Microsoft hasn't yet provided muchdocumentation explaining how DCOM works. Developers who want to use DCOM withexisting object servers and static configurations might have to simply use thedcomcnfg or racreg32 configuration utilities to configure their files.

To directly access all DCOM features, however, developers need to write newcode. The code samples that Microsoft provides with the updated Win32 SDK willhelp developers get started.

In particular, Lesson 16 of the OLE Tutorial includes building a DCOMremote client. Another DCOM sample with client and server pieces identifies theminimum requirements for using DCOM on the same or a remote machine. FreServeand FreClien samples illustrate building free-threaded server and clientcomponents, and a security sample with client and server pieces demonstratesclient- and server-side security in a DCOM application. The server componentalso illustrates several configuration options: a free-threaded service andfree-threaded server and apartment-threaded standard EXEs.

Despite its lack of documentation, DCOM is a powerful new tool fordevelopers and system administrators to add to their toolbox. Expect to see manydistributed applications based on DCOM.