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

Previous Table of Contents Next


Chapter 17
Directory Services

  Directory services are key to the operation of all middleware, not just DCOM.
  Type of Directory include the single file, host-based file, replicated file, replicated file with publish/subscribe, and the “no Directory” approach
  Microsoft’s current offering is the Registry—a host-based file
  Future plans are for the Active Directory—a replicated file
  The Active Directory should provide a secure, reliable, available, and moderately high performance best on which to build applications.

A Directory is a key service provided by all middleware, but one the developer rarely sees or uses directly. In fact, although the developer may never actually see the Directory, its design and the way it is configured is key to the reliability, availability, and performance of the application he or she builds. A poor Directory can result in system downtime, slow response, and may involve the administrator in a considerable amount of work. We will be looking at the Directory service in general in this chapter and then comparing the approaches that could be used with that used by Microsoft in DCOM.

What Is a Directory?

Most developers are familiar with the concept of databases. A database is an organized file of structured data that contains information used by an application at runtime. Thus, for example, an Order Processing application may use a database with information about Orders, Products, Customers, Deliveries, Stock, and so on.


Figure 17.1  DCOM Directory services

A Directory is the developer’s runtime database. It contains (or should contain) all the information the system software that his application uses (network software, middleware, DBMS, System Management Software, e-mail, and so on) and needs at runtime. Thus it could contain information on users, the user groups, their security information (passwords, access control lists), network addresses, processes/components found at each address, mail addresses, data found at the address, queues found at each address and their characteristics, performance data and statistics collected at runtime on the applications and data usage, machines, lines and their characteristics, data used in load balancing such as queue length and current loading at nodes, and so on.

A Directory should be a database shared by all the system software. There should be no need to set up one database for the middleware, yet another for the SMS, another for the network management software, another for the e-mail, yet another for the network software, and so on. As we all know, however, what should happen and what does happen in practice are somewhat different. Overall we find that each product, because each tends to be supplied by different vendors, has its own “database,” requiring extra effort on the part of the administrator to set up, incurring extra storage costs as information is duplicated, and, in addition, adding to the risk that the information in each one is inconsistent.

Just like application development where data sharing has rarely been achieved in practice, the software providers have also not learned how to share data.

Interestingly, tool vendors have not managed to share data during development either. Remember the Repository concept? A Repository was to be a single shared database of data used and created by the developer when he or she actually built the application. It was to contain data on screens/windows, data models, database designs, system designs, programs, tests and test data, project plans, machines and their configuration, users, and their organization.

Whereas a Directory is the database used at runtime by the system software used to run the applications, a Repository was to contain information used by developers while they were building the applications. Of course, much of the information generated during development is used during runtime, so in reality the distinction between Directory and Repository is a bit blurred, but the thinking was that the two should be kept separate for performance reasons. But no one could agree on what should go into a Repository, so initiatives like AD/Cycle from IBM failed.

In the same way, no one seems to be able to agree on what should go into a Directory, and many of the standards initiatives to define a Directory service specification and content description have failed. Instead, single vendors—such as Computer Associates and Platinum Technology with multiple system software products that use Directories—have taken steps to merge the Directories of their products.

Platinum Technologies, for example, has a strategy called POEMS (PLATINUM Open Enterprise Management System), the key feature of which is the PLATINUM repository. PLATINUM acquired not just one but two repository companies—Reltech and Brownstone—to provide the basis of its repository.

PLATINUM wants to integrate the tools they have acquired via the repository, not by building interfaces between the tools. Not only will the repository hold information from the application development tools, but it will also be used to hold systems management type data, events, policies to handle events, escalation procedures, and so on.

So, the ideal of a single Directory and Repository that can be used to store the data of multiple tools and system software products is a feature we are more likely to see being delivered by a vendor of multiple products—and one with the money to develop what is essentially a very complex piece of technology. Microsoft is clearly in this position, and we will be seeing whether their Directory service matches this ideal later in this chapter.


Previous Table of Contents Next