Maintaining Good Relationships with Other Data Sources

As mentioned earlier, it is important to think about how the data held in your directory service relates to data stored in other sources within your organization. Many organizations today suffer from data redundancy problems in which data elements are stored in multiple, uncoordinated databases and directory systems. Your directory service could help solve this problem, and you should certainly strive to avoid making the problem worse !

The following sections provide an overview of some techniques you can use to make your directory service a success in an environment where multiple data sources hold the same data elements. Chapter 23, Directory Coexistence, includes a more extensive discussion on integrating with other data sources.

Replication

If you are working with directory products that come from the same vendor or use the same protocols for replication ”for example, the emerging LDAP Duplication/Replication/Update Protocol group Internet Engineering Task Force (LDUP IETF) standard ”you should be able to use the built-in replication features to maintain consistent values for data elements across many servers. Third-party software also provides LDAP-to-LDAP replication for servers that support some common LDAP extensions, such as the changelog mechanism.

Replication has many potential benefits, including the possibility of spreading your directory application load across many servers, providing for redundancy in the face of server failures, and so on. See Chapter 11, Replication Design, for more information on replication design considerations.

Synchronization

Synchronization is a process in which changes made in one system are propagated to another. It differs from replication in that the protocols, schema, and data formats may vary widely among the data sources involved. Synchronization is typically done frequently (every hour , day, or week), but consistency of the data is usually not as tight as with replication. Synchronization can be performed in one or both directions and between two or more data sources.

For example, if employee name changes are always handled by the Human Resources department, it may be appropriate to propagate those changes to your directory service ”a one-way synchronization. If you allow telephone numbers to be changed both in the human resources database and in your directory service, you may want to set up two-way synchronization between the systems. If two-way synchronization is used, you will need to carefully consider what the outcome is if the same data element is changed in two different systems.

Synchronization tools are available from a variety of vendors , either bundled with their directory products or as standalone tools. For example, Microsoft Metadirectory Services can synchronize data between Microsoft Active Directory and many other data sources, including other LDAP servers such as Netscape Directory Server, Microsoft Exchange Server, various relational databases, Lotus Notes, and flat files.

Note

As LDAP directory service products mature, you can expect more synchronization tools to become available from the major vendors because nearly all customers are asking for them.

Good synchronization tools allow you to hook into the synchronization process and cause other actions as a result of changes to data. For example, when a person is added to a human resources database, an entry might be created in your central directory service. The same event could also be used to trigger actions outside your directory service, such as creating operating system accounts or granting access to network devices such as printers and file servers.

If you do set up synchronization between data sources, be prepared for some bumps along the way. Often a lot of tuning and some in-house software development are needed to smooth over the differences between the data sources. In many cases, the synchronization software is produced by one vendor, the directory software by another, and database software used by other data sources by yet another vendor. Clearly there is some system integration work to be done, but synchronization is a good solution if you can overcome these issues.

Batch Updates

Batch updates are really a kind of "loosely coupled " synchronization. Typically, batch updates are done less often (for example, once a month) and may involve the merging of data that comes from radically different sources. With few exceptions, the data-merging process must be developed in-house. This can be an expensive prospect because it usually takes several iterations working with real data before all the bugs are worked out.

When the authors were at the University of Michigan, a complicated C language program called munge was developed to merge data from the human resources database, student database, and a central directory service. The actual " munging " was done once or twice a month and usually took about a day. During that time no modifications could be made to the data held in the directory service, and a system administrator typically had to keep a close eye on the munge process. If anything went wrong during the data-merging process, the system administrators had to fix the data by hand or restart the entire munge process. The poor system administrators were often grumpy.

The key to successful use of batch updates is to streamline the process and make it as automatic and foolproof as possible.

Political Considerations

As the new kid on the block, your directory service may be viewed by your colleagues as something that creates more work for them rather than as the liberating tool it can become. This attitude is especially common in large organizations in which the keepers of data sources have limited resources, are focused on their own problems, or are just set in their ways.

Hopefully this is not the situation with your organization, but if it is, the best solution is to convince your peers who maintain other important data sources that your directory service will help them in some way. For example, if by working together you can eliminate four or five redundant change-of-address forms and replace the entire collection with a single change-of-address Web page, you will all be recognized as heroes.

If you are one of the people who manage non-LDAP directories or databases, you have our congratulations; you have already proven yourself to be a forward-thinking individual by reading this book. Please try to be helpful and friendly to the person trying to design and deploy the LDAP directory service (if you are not lucky enough to own that task yourself).