| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Microsoft’s Directory Services

Microsoft’s current Directory services are provided by the Registry service. Microsoft, however, plans to replace the Registry with a more sophisticated Directory service in Windows NT version 5.0 (due 1998). This Directory is known as Active Directory.

In the next few sections, I will be describing the current Registry service and how it works, and then in the last sections of this chapter I will provide a little more detail of the Active Directory.

Microsoft’s Registry service

The Registry that Microsoft uses now is a host-specific file containing information on objects and their IDs, users, groups, applications, and preferences plus other information relevant to that host. It also contains security information user password and ACLs. It is supported on the NT and 95 platforms.

Thus, the current Registry is of the type file per machine that we saw above. The Registry is stored on disk and not in memory. If the disk on which the Registry is based fails, the contents are lost unless the administrator has set up backup procedures using striped or mirrored disks.

The Registry contains the server name, the classID, the type, and the address. We saw earlier that within DCOM, servers are programs which can be the container for a number of components. The server is thus the name of the Server containing that component, the ClassID is the identifier of the component, the type simply describes what sort of component it is—proxy, EXE, or DLL—and the Address is one of the following:

  • the pathname of the server DLL
  • the pathname of the server EXE
  • or the pathname to the object handle/proxy object’s DLL

Proxy objects were described in detail in the chapter on COM; however, one proxy object exists for every remote component that a client could invoke. It thus serves as a special client side component acting on behalf of the server side component (thus the name proxy—it is the server component’s proxy).

The Registry thus only contains information about components on that particular host. But, because of the existence of the proxy object, a sort of “index” exists to components on remote hosts. The proxy is a means of showing that that component does exist elsewhere (without actually giving its remote address).

One proxy exists per remote component, but there is nothing to stop a developer duplicating/copying the remote component and placing it on more than one host. Thus, because each Registry contains local data, it is possible using the current Registry architecture to place a component on more than one machine. In theory, it could also be placed in more than one server on the same machine. Thus, there is the potential for DCOM to support load balancing, as we saw in the chapter on MTS, as a request could be channeled to one or perhaps many copies of the same component scattered over the network.

When the server is installed, an application set up program for the server ensures the server itself creates entries in the Registry that point to the components. Components are thus generally registered when they are installed as part of the application setup program. Proxy objects also register themselves.

It is, however, possible to have a self-registering server. Where DLLs are used, the developer uses a special feature (HRESULT DIIRegisterServer), which updates the Registry with all the classes implemented. Where EXEs are used, the developer uses special command line flags. Clearly, in either case, the code has to be written so that the server doesn’t register itself over and over again, but even if it does, the only problem is the waste of processing; the Registry doesn’t end up with duplicate entries.

In effect, there are two ways in which entries are created in the Registry. The first way is used when the server is loaded as an executable and executing process. In this case, the server registers itself and its components using commands the programmer must add to his program. The second way is for the administrator to provide a setup program that registers the server, which, in turn, registers its components. In both cases some support is thus given for publish and subscribe type services, but this time applied to a file per machine type of Directory.

But, DCOM’s Registry is not self healing. If the component fails or is inadvertently removed, the administrator has to physically remove the entry from the Registry. So, although some features to help with reliability are built in, some problems with reliability may ensue, if the administrator forgets to keep the information up to date.

Either way, the administrator does not have to set up the Implementation Repository used in CORBA ORB types of products. Even where triggering is used, the setup program can be used to set up the information in the Registry.

All security information must be set up manually on each host.

The Registry contains information about what servers exist on the machine—but these will be servers in the library, not running instances of the server. The table used to hold details of the running servers is called the Class Table or Running Object Table.

Previous | Table of Contents | Next