Directory Software Options

Understanding and Deploying LDAP Directory Services > 6. Data Design > Maintaining Good Relationships with Other Data Sources

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078214171160062210085184228

Maintaining Good Relationships with Other Data Sources

It is important to put some thought into how the data held in your directory service relates to that stored in other data 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.

Most people encounter this problem on a personal level when they move and want to notify their company or school of their new home address. Often, there are four or five (or more) places where you must submit the new information so it reaches all the systems that have their own copy of your home address. Your directory service could help solve this problem, and you should certainly strive to avoid making the problem worse !

In the following sections we provide an overview of some techniques you can use to make your directory service a success in an environment where there are multiple data sources that hold the same data elements. Chapter 22 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, you should be able to use the built-in replication features to maintain consistent values for data elements across many servers. There is also third-party software that attempts to provide replication.

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 10, "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 between the data sources involved. Synchronization is typically done fairly 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, the Netscape Directory Server package includes a Windows NT Synchronization Service that provides two-way synchronization between Windows NT domain controllers and the Netscape Directory Server. 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 things to occur 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. This same event could also be used to trigger actions outside of 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 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 comes from yet another vendor. Clearly there is some system integration work to be done, but synchronization can be a good solution if you can overcome these issues.

Batch Updates

Batch updates are really a kind of "loosely coupled " synchronization. Typically, these are done less often (for example, once a month) and may involve the merging of data that comes from radically different sources. With very few exceptions, today 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 (see Chapter 24 for more information). 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 poor system administrator had to fix the data by hand or restart the entire munge process. This invariably created some very grumpy system administrators.

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 own 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. This is obviously more difficult than it sounds, but it is well worth spending some energy on. 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 electronic form, you will all be recognized as heroes.

It is also a good idea to make sure that the top people within your organization are aware of your directory project and 100% behind it. Gaining the support of your CEO or CIO will often spur other people to action, or at least break down political barriers that prevent you from making progress. The best way to get buy-in from decision makers is to put on your sales and marketing hat and produce a short document that lists the key benefits your service will provide. Share the document with the people you aim to convince and then arrange to meet with them to ensure that all their questions are answered and that they are behind the project.

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 who is trying to design and deploy the LDAP directory service (if you are not lucky enough to also own that task).



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

batch updates
          relationships between data sources 2nd
data
          sources 2nd
                    batch updates 2nd
                    political considerations 2nd 3rd
                    replication 2nd
                    synchronization 2nd 3rd 4th
directories
         data
                    sources 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
relationships
          between data sources 2nd
                    batch updates 2nd
                    political considerations 2nd 3rd
                    replications 2nd
                    synchronization 2nd 3rd 4th
replications
          relationships between data sources 2nd
sources
          data 2nd
                    batch updates 2nd
                    political considerations 2nd 3rd
                    replication 2nd
                    synchronization 2nd 3rd 4th
synchronization
          relationships between data sources 2nd 3rd 4th
updates
         batch
                    relationships between data sources 2nd

2002, O'Reilly & Associates, Inc.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net