NT 4.0’s Distributed Component Object Model

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).

Features
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.