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

Previous Table of Contents Next


Active Directory

Microsoft fully realizes that the current Registry is limited, and as such their plans are for the Active Directory—a far more ambitious and extensive Directory service. The Active Directory is to be provided with Windows NT version 5.0; however, it is worth mentioning that many of the new features to be released as part of Windows NT 5.0 were provided to developers on a CD at the Microsoft Developer’s conference in Los Angeles towards the end of 1996.

Replication-Active Directory will be based on replicated files. A master copy will contain the information, and this information will then be replicated across all the nodes in the network. This contrasts with the approach used now for the Registry, where each host has its own unique table of data relevant to that host. This master file is planned to support “10 million entries.”

Active Directory is due to be based on a “high performance storage engine.” Note that Active Directory will initially only cover Windows systems; it will not be extended to other Unix or mainframe hosts, but other companies are planning to support it.

Contents-The Active Directory will contain far more information than the Registry—networks, users, devices, domain names, database files, security information, e-mail addresses, and so on. It will also support versioning of information and is due to be extensible. It will act as the master database for runtime information for most of Microsoft’s products.

Microsoft is merging the functions of the numerous directories they now have—the ones used in Back Office, Exchange, the Registry, and so on. In effect, all these products will be adapted to support the one Active Directory, including DCOM.

Perhaps equally interesting is that Microsoft has started to gain support from a number of third-party vendors, all of whom look like they will use the Active Directory to store the data they need for their products, or reuse the data already stored on it. Bay Networks and Cisco Systems have both expressed support for the Active Directory. Bay Networks already had a close relationship with Microsoft, and their routing software was included in Steel-head—the project that places routing functionality within Windows NT. Cisco has licensed Microsoft’s Active Directory and intends to port it to other Unix platforms as well as use it in its router software.

ADSI-In the future, Active Directory will be accessed by an interface—known as the Active Directory Server Interface (ADSI) and formerly known as ODSI (Open Directory Service Interface). ADSI has already been released with an SDK as an add-on to Windows NT Server version 4.0. ADSI not only provides the interface to Active Directory, it also provides the interface to the Registry in Windows NT 4, and is intended to support NetWare DS and 3x binderies, LDAP 2.0, HTTP, and DNS Internet services as well as X.500.

This is where the Translation service in the diagram marked “Directory” comes in. Microsoft in effect is providing or intending to provide drivers/translation software, which converts the ADSI calls into the native calls of these other Directory services—providing support for “legacy” or existing directories. Note that ADSI does not remove the administration nightmare that comes from having this number of Directories, nor does it solve the problem caused by the fact that all these directories may contain different information, but it does ease things a little from a developer’s viewpoint and also makes it possible for the administrator to gradually ease away (where possible) from using third-party directory services towards using just Active Directory. By using ADSI, the developer should be able to provide users with single logon across multiple directories, as well as products such as RACF.

LDAP-Lightweight Directory Access Protocol is an important part to this interface because by supporting LDAP Microsoft also provides the developer with access to any Directory system that itself supports LDAP as well as access to its own Directory over the Web. Netscape, Novell, Lotus, and Banyan have all pledged support for the protocol, and DCE is also getting an LDAP interface. LDAP is complementary to and a strict subset of the DAP (Directory Access protocol) developed for access to X.500 directory systems.

LDAP also provides access to X.500 Directories but reduces the resource requirements typically associated with DAP. LDAP is targeted at simple applications or tools such as Web browsers. It is carried directly over TCP (reliable transport), uses a lightweight BER encoding scheme, and supports asynchronous communication.

Again, it is important to emphasise the difference between the protocol, used to access the directory and the content of the directory, which remains the preserve of each vendor. Harmonization of the protocol for accessing a directory doesn’t prevent the developer’s having to know its contents.

Microsoft plans to support a number of leading naming conventions in Active Directory:

  HTTP URLs (universal resource locators)
  X.500 naming conventions
  LDAP URLs
  RFC833 names
  RFC1779 distinguished names
  UNCs

Active Directory and the Repository-In a wider context, it is interesting to note that with the arrival of Active Directory, Microsoft will have two “repositories.”

Active Directory is effectively Microsoft’s runtime repository containing information about things used at runtime by its software products and the applications. Microsoft’s other “repository,” called the Microsoft Repository, is the repository used to store development information. Given that a considerable amount of information about “things” used during development is often used at runtime—objects, versions, users, groups, programs, machines/devices, and so on—I wonder why they didn’t combine the two from the start. If the administrator decides to use these repositories, he or she still has the problem of duplication to contend with. Microsoft did state, however, that the intention was to combine the two long term.

Microsoft’s repository was released towards the end of 1996. It was a joint development with Texas Instruments and uses Unified Modeling Language (a language developed by Rational) to access the contents. Microsoft’s repository is now part of Visual Studio, and a tool called Visual Modeler is used to generate data for the repository. Source Safe is used for management of the contents.

Thus, the tools supporting DCOM that we mention in the development section—Professional and Enterprise Editions of Visual Basic 5, as well as Visual Studio—use or are planning to use the repository. Popkin, Rational, Select, TI, and LogicWorks are also committed to supporting UML and the repository.


Previous Table of Contents Next