What Is LDAP?

Understanding and Deploying LDAP Directory Services > 21. Directory-Enabling ExistingApplications > Advice for Directory-Enabling Existing Applications

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012002234180114052099184180

Advice for Directory-Enabling Existing Applications

Adding LDAP support to an existing application may be better than creating a brand new LDAP application, but it can also be much more difficult. The degree of difficulty depends on the nature of the application you are modifying, the scope of the changes you need to make, and the level of LDAP expertise you expect the application's users to have. You can use the following techniques to ease the pain of development and increase the payoff when you are done (some choices conflict with others, and they won't all apply in all situations):

  • Hide the directory integration from users and systems that depend on the application.

  • Make the new directory capabilities visible to the users of the application to promote new features.

  • Use a protocol gateway to achieve integration.

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

  • Consider how the directory service will be affected, and inform those who run the service of any need for increased capacity and other modifications.

  • Plan for a 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 this section. Again, some of these ideas conflict with one another; you should use the ideas that make the most sense in your situation.

Hiding 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 by other systems that are difficult and expensive to modify.

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

Another example of hiding directory integration is to modify a client application that normally queries a proprietary directory to instead query an LDAP directory ”without changing the user interface. The proprietary directory can be eliminated, and users need not learn a new interface.

The general idea behind hiding directory integration from the people or systems that use an application is to reduce the cost and pain associated with the introduction of a directory service.

Making the New Directory Capabilities Visible

An alternative to hiding directory integration is to make the new directory capabilities visible to the users of the application. If you are truly adding new features ”or if you simply want to better promote your directory service ”exposing the new features to the application's users is a useful technique.

For example, suppose you have a Web-based workflow application that requires users to know a person's user ID to include them in a flow. Adding a directory feature that allows lookups of people based on name , phone number, and other criteria may be a great benefit to workflow users. To ensure that people notice the new feature, you may want to alter the interface of the workflow application by adding a new button to access the new feature. As a side benefit, users who appreciate the new feature will know that it is made possible by your directory service. This in turn will help promote your service.

A more subtle technique is to modify the application in some way to simply let people know that 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.

Using a Protocol Gateway to Achieve Integration

An application 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 by 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.

Suppose you have been using the CSO Nameserver software from the University of Illinois to provide a simple directory service for your users. CSO is similar to LDAP, but simpler. A number of clients for CSO exist, including one built in to the popular email client Eudora. By replacing your CSO Nameserver with a CSO-to-LDAP gateway, end users can be given access to your LDAP directory service in a fairly transparent manner (see Figure 21.5). A freely available gateway product called CX can be used as the gateway.

Figure 21.5 Using the CX CSO-to-LDAP gateway.

Another example is a building access system that consists of dozens of electronic card readers that communicate with a centralized building access database through a proprietary protocol (see Figure 21.6).

Figure 21.6 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. Due to high cost and lack of availability of such devices, a much cheaper and simpler approach might be to hide the directory integration from the card readers. This could be accomplished by building an intermediate server that acts as a gateway between the card readers' proprietary protocol and LDAP (see Figure 21.7).

Figure 21.7 A directory-enabled building access system.

By using an application protocol gateway to bring directory service to your users, no changes need to be made to the client software they already use. This means that you can deploy the directory capability more quickly and with less expense.

Avoiding 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. Each gateway also causes management headaches : It is one more piece of software to monitor and keep running.

In addition, gateways sometimes produce an imperfect directory experience for users of an application. A compromise must typically be made to fit any two protocols together, and if too much is lost in the translation, users may complain. For example, advanced features of LDAP aren't likely to be supported by an older protocol such a s PH (which the CSO Nameserver is based on). The list view extension, for example, allows users to efficiently browse tens of thousands of directory entries; however, people who access your directory service via PH will not be able to take advantage of the feature.

Integration schemes that make copies of directory data are also troublesome . Live access to directory data (via a gateway, for example) is generally preferred over accessing data that has been duplicated and placed in another data store; such synchronization between data stores is often difficult, resource- intensive , and fragile. You need to consider the tradeoff between high-performance access to data, which might be best achieved 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 22, "Directory Coexistence."

Considering How the Directory Service Will Be Affected

When directory-enabling any application, it is important to consider how the application will use the directory service. The people who run the directory service need to know what kind of load the new directory-enabled version of the application will place on their service. 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 in use. An upgrade may be necessary, or a different strategy may need to be chosen 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 amount of the increase can easily be calculated using the number of card key accesses performed weekly using the existing, non-LDAP building access database. Suppose this number is 70,000. The new directory-enabled system might use two LDAP search operations when deciding whether to grant access: one to find the user associated with a card and one to check whether the user is in a group that has access to a given building. The total load imposed on the directory service by the new system would thus be 140,000 searches per week. Each search needs to be answered fairly quickly because people will not tolerate long delays while waiting for a door to be unlocked. 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, it is likely that a majority of the card key accesses occur between the hours of 8:00 and 10:30 a.m. on weekdays, when most people arrive for work.

By providing detailed information about how your directory-enabled application will affect the directory service, those responsible for the service can plan to accommodate the load or new service features introduced by your application. More advice on communicating the needs of your application to those who maintain a directory service can be found in Chapter 20.

Planning for a Transition

Try to 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 use an incremental approach in which you pilot the new version of the application before fully rolling it out. For most applications, this can be done 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. If the application you modify is primarily used 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, when any resulting problems have less of an effect on your organization.

Being Creative and Considering 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 we have discussed and others to determine what makes the most sense for the application you are directory-enabling.

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 quietly introduce the directory-enabled application, or do you want to make a big splash and generate publicity for your directory service? The best choice is influenced by the answers to these and many other questions.

For example, when adding LDAP support to a widely used application such as an email 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. With some creative thinking, you can design your application to provide access to advanced address book capabilities for power users but preserve a familiar address book interface for novices. A possible approach could be to allow power users to type LDAP search filters in a search field that accepts simple text strings.

Another example of creative thinking might arise when considering how best to integrate an LDAP directory service with a legacy application that has a proprietary data store. If performance is a key requirement, it may be appropriate to modify the application to speak LDAP natively. But suppose your primary goal of LDAP integration is to eliminate the database system used by the application and reduce your data store maintenance costs. Then the more appropriate approach to 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.



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

Index terms contained in this section

applications
          directory-enabling 2nd
                    creativity 2nd 3rd 4th
                    effects to directory service 2nd 3rd
                    exposing new features to users 2nd
                    gateway problems 2nd 3rd
                    hiding directory integration 2nd 3rd
                    protocol gateways 2nd 3rd 4th
                    transition planning 2nd
directories
          enabling applications 2nd
                    creativity 2nd 3rd 4th
                    effects to directory service 2nd 3rd
                    exposing new features to users 2nd
                    gateway problems 2nd 3rd
                    hiding directory integration 2nd 3rd
                    protocol gateways 2nd 3rd 4th
                    transition planning 2nd
enabling
          applications 2nd
                    creativity 2nd 3rd 4th
                    effects to directory service 2nd 3rd
                    exposing new features to users 2nd
                    gateway problems 2nd 3rd
                    hiding directory integration 2nd 3rd
                    protocol gateways 2nd 3rd 4th
                    transition planning 2nd
existing applications
          directory-enabling 2nd
                    creativity 2nd 3rd 4th
                    effects to directory service 2nd 3rd
                    exposing new features to users 2nd
                    gateway problems 2nd 3rd
                    hiding directory integration 2nd 3rd
                    protocol gateways 2nd 3rd 4th
                    transition planning 2nd
gateways
         protocol
                    directory-enabling applications 2nd 3rd 4th
                    troubleshooting 2nd 3rd
hiding
          directory integration 2nd 3rd
integration
         directory
                    hiding 2nd 3rd
planning
         transition
                    directory-enabling applications 2nd
protocols
         gateways
                    directory-enabling applications 2nd 3rd 4th
                    troubleshooting 2nd 3rd
transition planning
          directory-enabling applications 2nd
troubleshooting
         gateways
                    directory-enabling applications 2nd 3rd
users
         exposing new features to
                    directory-enabling applications 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