Advice for Directory-Enabling Existing Applications

Although adding LDAP support to an existing application is often better than creating a brand-new LDAP application, it can also be more difficult. The degree of difficulty depends on the nature of the application you're modifying, the scope of the changes you need to make, and the level of LDAP expertise you expect the application's users to have. The following techniques should ease the pain of development and increase the payoff when you are done. Note that some choices conflict with others, so not all of these techniques will apply in all situations:

• To reduce barriers to deployment, hide the directory integration from users and systems that depend on the application.

• Promote your new features by making the new directory capabilities visible to the users of the application.

• Use a protocol gateway to achieve integration and reduce barriers to deployment.

• Avoid problematic architectural choices that adversely affect performance, involve the duplication of data, and so on.

• Consider how the directory service will be affected, and inform those who run the service if additional capacity or any other modifications are required.

• Plan for a smooth transition from the existing application to the new directory-enabled version.

• Be creative, and consider all your options.

Each idea is discussed in greater detail in the following sections.

Hide the Directory Integration

Depending on the kind of directory-enabling you do, it may make sense to try to hide the changes from the users of the application as much as possible. This can be especially important if the application is used widely or is used by other systems that are difficult and expensive to modify.

For example, suppose you have an e-mail delivery system that uses five servers, each with its own local database of information about users and mailing lists. You want to reduce your system management costs by directory-enabling the e-mail servers so that they all share a common directory of information about users and mailing lists. You may be able to hide this change from users of the e-mail service by doing all the directory integration on the back end (that is, in the e-mail servers themselves ). This way, you avoid deploying new e-mail clients , and your users do not need to learn anything new.

Another example of hiding directory integration is to modify a set of Web-based applications that each use a proprietary database for access control and authorization so that instead they use an LDAP directory ”without changing the user interface of any of the applications. You can eliminate the proprietary databases without requiring that visitors to your Web site learn a new interface.

Hiding directory integration from the people or systems that use an application provides the benefits of a shared directory service while minimizing the associated deployment costs.

Make the New Directory Capabilities Visible

The alternative to hiding directory integration is, logically enough, to make the new directory capabilities visible to the application users. If you are truly adding new features ”or if you simply want to promote your directory service ”exposing the new features is helpful.

For example, suppose you have a Web-based workflow application that requires users to know a person's user ID to include that person in a flow. Adding a feature that allows directory lookups of people based on name , telephone number, and other criteria may be a great benefit to workflow users. To ensure that people notice the new feature, you could, for example, add a new Directory Lookup button to the workflow application's interface. As a side benefit, users who appreciate the new feature will know that it is made possible by a directory service, which will help promote the service and ensure future funding.

Another promotional technique is to modify the application to let people know they are using a directory service. For example, you might add a banner that reads "Directory-Enabled finger Service" to the output returned by an LDAP-aware Unix finger server.

Use a Protocol Gateway to Achieve Integration

Developing a gateway that translates between an existing protocol and LDAP is often an effective way to directory-enable an existing, widely used application. A gateway is a server application that accepts a request using one application protocol, translates it to another protocol such as LDAP, and passes it to another server. A similar translation procedure is performed in the reverse direction on information returned from the directory server.

For example, Figure 22.5 shows a building access system that consists of dozens of electronic card readers that communicate with a centralized building access database through a proprietary HTTP- and XML-based protocol.

Figure 22.5. A Building Access System before Directory-Enabling

Let's assume that the building access database contains redundant information about people, so you decide to replace it with your directory service. One approach would be to upgrade to card readers that speak LDAP directly. Because of the high cost and lack of availability of such devices, however, that may not be a cost-effective option. A cheaper and simpler approach might be to hide the directory integration from the card readers by building an intermediate server that acts as a gateway between the card readers' proprietary protocol and LDAP. Figure 22.6 shows the new deployment architecture.

Figure 22.6. A Directory-Enabled Building Access System

The success of an approach that uses a protocol gateway depends greatly on how easy it is to bridge the gap between the existing protocol and your directory service, and also on whether the existing protocol is well specified. Assuming you can pull it off, using an application protocol gateway to bring the directory service to your users allows you to deploy the new directory-integrated solution more quickly and with less expense.

Avoid Problematic Architectural Choices

For all their good points, gateways have some problematic characteristics as well. Using a gateway sometimes leads to unacceptable performance, introducing delay and consuming additional system resources to translate from one protocol to another. Using gateways also causes management headaches : The gateway is one more piece of software to monitor and keep running.

In addition, gateways sometimes produce an imperfect directory experience for users. Typically, compromises must be made when any two protocols are being fitted together, and if too much is lost in the translation, users may complain. For example, advanced features of LDAP such as the Virtual List View (VLV) control are not supported by older protocols such as the Unix finger protocol. VLV allows users to browse tens of thousands of directory entries efficiently ; however, people who access your directory service via a finger gateway will not be able to use VLV to do so.

Integration schemes that make copies of directory data are also troublesome . Accessing live directory data is generally preferred over accessing data that has been duplicated and placed in another data store. Synchronization between data stores is often difficult, resource intensive , and fragile. Consider the trade-off between high-performance access to data, which you might achieve best by copying the data, and timely access to changing data. More information on integrating other data sources with your directory service can be found in Chapter 23, Directory Coexistence.

Consider How the Directory Service Will Be Affected

When you are directory-enabling an application, always consider how the application uses the directory service. The people who run the directory need to know in advance what kind of demands the new directory-enabled version of the application will place on their service. The application may generate additional load in the form of LDAP read and update operations. Changes to the directory schema may be required to accommodate the application. Sometimes an application requires an LDAP protocol feature that is not supported by the directory server software, so an upgrade may be necessary, or you may need to pursue a different strategy to accomplish the directory integration.

For example, the directory-enabled version of the building access system described earlier would increase the load on the directory service. The number of card key accesses performed weekly with the existing, non-LDAP building access database can be used to easily calculate the amount of the increase. Suppose this number is 70,000. The new directory-enabled system might use two LDAP operations when deciding whether to grant access: one to find the user associated with a card (a subtree search) and one to check whether the user is in a group that has access to a given building (a compare operation to check group or role membership). The total load imposed on the directory service by the new system would thus be 140,000 operations per week.

In addition, each operation needs to be completed fairly quickly because people will not tolerate long delays while waiting for a door to be unlocked (in fact, they may become impatient and try again, therefore generating even more load). You should also take into account peak load: An application may be used more often at certain times of the day or on certain days of the week. For example, most card key accesses will probably occur when people arrive for work, which might be between 8:00 and 10:30 A.M. on weekdays.

If you provide detailed information about how your directory-enabled application will affect the directory service, those responsible for the service can make plans to accommodate the application. More advice on communicating the needs of your application to those who maintain a directory service can be found in Chapter 21, Developing New Applications.

Plan for a Smooth Transition

You should plan an orderly transition from the existing application to the new directory-enabled version. By introducing the new directory capabilities in a controlled way, you reduce the risk associated with the change. To transition smoothly, you must continue to support the old application for a period of time while users and dependent systems switch and adjust to the new version.

Try to adopt an incremental approach in which you pilot the new version of the application before fully rolling it out. For most applications, you can do this by announcing the new directory-enabled version to a small number of users, extracting and incorporating their feedback, and then rolling it out to your entire user base in phases. If the application you modify is used primarily by other systems, you may be able to limit how many systems you initially switch over to use the directory-enabled version of the application. Another approach is to test the modified application with the dependent systems during off-hours, so that your business is not affected as severely if problems occur.

Be Creative, and Consider All Your Options

As you consider how best to directory-enable an existing application, be creative. The most obvious and straightforward approach is not always the best one. Consider all the possible techniques presented in this chapter to determine which approach is best for your application.

When considering the alternatives, think about what you want to accomplish by directory-enabling the application. Do you want to provide completely new capabilities to end users? Are you trying to save system maintenance costs by decommissioning a redundant data store? Do you want to introduce the directory-enabled application quietly , or do you want to make a big splash? Your approach should be influenced by the answers to these and many other questions.

For example, when adding LDAP support to a widely used application such as an e-mail client, adopting an address book metaphor for the interface to the new LDAP features may increase the rate of adoption and reduce the learning curve for your users. On the other hand, introducing an entirely new user interface paradigm, such as a Search LDAP screen, allows more flexibility in exposing LDAP-specific features such as compound Boolean search filters or advanced features such as VLV. With some creative thinking, you can design your application to provide power users with access to advanced LDAP capabilities but preserve a familiar address book interface for novices. A possible approach could be to present a search field that accepts simple strings (for novices) as well as raw LDAP search filters (for advanced users).

As another example, consider a legacy application with a proprietary data store that you want to LDAP-enable. If performance is a key requirement, it may be appropriate to modify the application to speak LDAP natively. But suppose the primary goal of your LDAP integration effort is to eliminate the database system used by the application and reduce your data store maintenance costs. Then the best approach for integration might involve a protocol or API-level gateway that looks to the application like its old data store but accesses data from an LDAP directory. The gateway approach may be easier to develop and deploy, thereby allowing you to achieve your primary goal of decommissioning the legacy data store more quickly.