One of the most exciting features in Windows NT 4.0 is also one of the least visible: Distributed Component Object Model (DCOM), formerly Network Object Linking and Embedding (OLE--I discuss NT 4.0 features of this facility in, "Windows NT 4.0," in the April issue). This protocol lets software components communicate directly with each other over a network in a secure manner. DCOM works in the background with NT's transport and calling mechanism, has no user interface besides a dialog for changing settings, and performs automatically 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 standard software components from off-the-shelf or third-party vendor products or common development tools such as Microsoft's Visual C++ and Visual Basic (VB). DCOM works under NT 4.0's Service Control Manager (SCM) and has its own configuration utility. If you're creating distributed applications, DCOM can provide an alternative to VB's remote automation (RA). To help you get started developing with DCOM, Microsoft includes some developer samples in the updated Win32 software development kit (SDK).
DCOM gives developers two main benefits: location transparency, the ability to distribute client applications without ties to local objects, and packaging transparency, the ability to implement in-process objects in DLLs or local or remote objects in executables (EXEs) or as 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 to include completely multithreaded (free-threaded) objects. This support is in addition to DCOM's support for apartment-threaded and nonthreaded objects. Be aware that free-threaded objects support simultaneous calls by multiple clients, which is a key feature for developers creating scaleable server-side applications.
Activation/Launch Security: Using NT's access control lists (ACLs), you can specify which users can start specific object servers. Object servers instantiate (create) in-process, local, and remote objects. By default, DCOM lets only machine administrators launch object servers from remote clients, but you can change or override this default for individual object servers. Launch security also applies to local (same machine) launch requests, which is important for Win32 services that typically run under the System Account. With DCOM, if you have object servers that a remote client launches, you can configure them to run under a specific domain user account.
Call/Access Security: In addition to launch security, you can specify 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 access security with launch security to let a remote user access an object that the server must launch.
Call-Level Security: DCOM supports putting security on specific properties or methods of an object server. For example, each interface can have its own remote procedure call (RPC) authentication, impersonation, or authorization parameters.
SCM and Services
DCOM is available for NT 4.0 and will ship with the Nashville update of Windows 95 this fall. For DCOM to work, it must run under an OS with SCM (affectionately, the scum) that starts, stops, and interrupts services (system applications that launch at startup--Win95 doesn't support services). The Services applet in the NT Control Panel controls the SCM.
Support for running as a service gives an application or component several advantages over traditional EXEs. First, services run before a user logs on and continue running as other users log on and off the system. Second, you can locally and remotely start, stop, pause, and restart services. Third, you can configure a service to automatically run when the machine boots or to launch when a client application requests it. Finally, you can run a service under a specific user account, and the service can interact with the desktop.
This last advantage (letting a service interact with the desktop to create a visible user interface and interact with a user) is complicated and a frequent source of confusion. In NT, a service can log on using the LocalSystem account or an NT domain account. A logged-on user, any service running under LocalSystem, or any service logged on as a specific user runs in a separate window station and hence on separate desktops.
The reason NT uses separate window stations and desktops involves the Windows architecture and its legacy. The Windows core consists of three major libraries: KERNEL, which manages memory and internal objects such as processes, threads, files, and communications ports; GDI, which manages graphical objects such as bitmaps and metafiles; and USER, which manages the user interface, the most obvious pieces being the actual windows and the underlying Windows messaging 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 objects don't (Microsoft figured the added security would break too many applications).
Because of this lack of object-level security, Microsoft encapsulated the user interface into separate desktops and window stations. This limitation prohibits a Win32 service from sending messages back and forth to the interactive desktop.
Because COM makes extensive use of USER and relies on Windows messages, you can't use COM to communicate between OLE service objects and interactive desktop objects. Even if you could use COM, Windows would still need to switch desktops like crazy, which would seriously degrade system performance. In retrospect, Microsoft should have moved COM into the KERNEL early on and eliminated COM's message-based architecture.
This situation changes with DCOM, which uses RPC transport instead of Windows messages for over-the-wire network communication and communication between desktops. Locally, services running in any account other than the LocalSystem account can impersonate a domain user, and this impersonation mechanism lets a COM object run with specific security on remote machines. Although you can configure services to interact with the desktop, they always run in a desktop and window station separate from the interactive user. This approach prevents termination when the interactive user logs off. Services don't offer any built-in performance advantages over traditional EXEs. However, you'll see developers creating more components specifically for servers and operating on remote machines so that they can take advantage of DCOM's benefits.
When you're developing remote applications to use services, consider some design points. Although one advantage a service has over a traditional EXE is the ability to interact with the desktop, you don't want to make services interactive. If you do, you'll run into several ugly design issues: What do you do 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 on simultaneously?
In fact, Microsoft is considering removing service interactivity completely from future versions of NT. If you need to output monitoring information from a service, build it to write to the system Event Log. Other than the interactivity issue, the only restriction on Win32 services is that you can run only one instance of a service at a time on a particular machine.
You can configure individual object server settings in the Win32 system Registry or by passing these settings into an application dynamically--through a coserverinfo structure--when you instantiate an object through code. You can manually configure Registry settings with NT 4.0's dcomcnfg utility, as in Screen 1.
NT's Setup doesn't configure access to this utility, but you can find dcomcnfg in the \system32 subdirectory and start it directly. (I added a shortcut to my Start Menu.) dcomcnfg lets you configure default security and configuration properties for all DCOM-controlled objects and configure these properties for individual object servers.
If you use RegEdit to look at Registry settings for object servers, you need to be aware of DCOM's new Application ID (AppID) keys. These keys group DCOM object configuration options in the Registry to simplify the management of common settings.
In contrast to ProgID and CLSID keys, where each possible class has its own key, AppID groups an EXE's DCOM objects under one key for use during activation and to obtain the default access permissions. DCOM then uses the corresponding CLSID key to map the AppID keys to EXEs.
DCOM and the VB RA
Both the RA feature in VB 4.0 Enterprise Edition 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 require additional software or licensing as VB's RA does, and DCOM has substantially more security and configuration options than VB's RA. One implication of having the operating system provide DCOM is that a 16-bit version of DCOM doesn't exist--VB's RA includes a 16-bit client, so businesses with legacy Windows 3.x systems that build distributed applications need to use RA at least until the applications can talk to systems running 32-bit versions of Windows.
Although RA uses the Registry to configure settings, Microsoft strongly encourages VB developers not to touch these entries directly and instead access them through the racreg32 object server. In fact, Microsoft followed its own advice when it created the racmgr32 configuration utility. Developers who follow Microsoft's advice will be pleased to know that NT 4.0 includes updated versions of racrec32 and racman32 that support access to RA and DCOM settings. One final, important difference between RA and DCOM is that although RA requires machine names such as myserver, DCOM lets you specify the machine name in a valid universal naming convention (UNC) format, such as myserver or \\myserver, or in a Domain Name System (DNS) format, such as www.server.com or 220.127.116.11.
Microsoft hasn't yet provided much documentation explaining how DCOM works. Developers who want to use DCOM with existing object servers and static configurations might have to simply use the dcomcnfg or racreg32 configuration utilities to configure their files.
To directly access all DCOM features, however, developers need to write new code. The code samples that Microsoft provides with the updated Win32 SDK will help developers get started.
In particular, Lesson 16 of the OLE Tutorial includes building a DCOM remote client. Another DCOM sample with client and server pieces identifies the minimum requirements for using DCOM on the same or a remote machine. FreServe and FreClien samples illustrate building free-threaded server and client components, and a security sample with client and server pieces demonstrates client- and server-side security in a DCOM application. The server component also illustrates several configuration options: a free-threaded service and free-threaded server and apartment-threaded standard EXEs.
Despite its lack of documentation, DCOM is a powerful new tool for developers and system administrators to add to their toolbox. Expect to see many distributed applications based on DCOM.