Understanding and Deploying LDAP Directory Services > 20. Developing New Applications > Advice for LDAP Application Developers |
Advice for LDAP Application DevelopersAs with most kinds of applications, the process of developing an LDAP directory-enabled application is filled with many choices. By planning ahead a bit and thinking about how your application will interact with the directory service and other applications, you can save yourself a lot of grief . In this section, we present some advice to help you develop good LDAP applications. (Additional information on data- related design considerations can be found in Chapter 17, "Maintaining Data." ) Striving to Fit InA common mistake for new LDAP application developers is to treat the directory as a private application-specific store. Although in some rare cases this might be a valid practice, the focus of most LDAP directories is on sharing information among applications, end users, and administrators. Also, keep in mind that the design of the directory may be altered in the future to meet the needs of other applications or to accommodate organizational changes. You should design and write your application so that it assumes as little as possible about the directory design and can coexist with other applications ”including ones that have not yet been written. To accomplish this, follow these guidelines when designing and implementing your application:
The challenge in developing an application that fits well with other applications and can survive directory design changes is knowing when it is okay to make assumptions. For example, it is probably unacceptable to assume much about how the people and group entries are arranged in the directory information tree (DIT). On the other hand, it is probably okay for your application to dictate the DIT structure within a portion of the directory namespace that it uses to store its own application-specific configuration information. Tip Make your application as configurable as possible with respect to how it uses the directory service. Do not hardwire knowledge of the DIT structure, access control rules, or other key parts of the directory design into your application. If you do not expect certain things to change, it is okay to make them somewhat difficult to reconfigure. However, it is important to ensure that there is some way to change the configuration without rewriting the application. Otherwise, you would need to modify the application and distribute new copies everywhere if a critical directory-related assumption you made ceased to hold true. Examples of techniques you can use to build a flexible application include using configuration files or templates for directory-related settings and writing your application so that it reads schema information from the directory service itself. Communicating Your Application's Directory NeedsAs part of your application design process, document how the application interacts with the directory service. Share this information with the people responsible for the design and deployment of the directory service. In many cases, deployment of a new application requires the directory design to be modified or software upgrades to be performed, both of which may be perfectly acceptable to directory administrators if known in advance. It is important for everyone to be aware of any necessary changes as soon as possible so that the required planning and deployment tasks can be handled before your application is deployed. These are some of the things you should communicate to those responsible for running the directory:
Designing for Good Performance and ScalabilityActual performance and scalability requirements vary from application to application and site to site. It is true, however, that the use of computing services and networks is rapidly increasing in most organizations. To be safe, you should design your application to perform well and accommodate a much larger number of directory entries than are currently stored in your directory service. By considering performance and scalability of the directory-related aspects of your application up front, you may avoid a costly redesign later. When designing and writing your application, avoid architectural choices that limit performance, require you to open a large number of connections to the directory service, or make it difficult to use performance-enhancing techniques such as caching. If your application uses LDAP heavily, you may want to implement a shared pool of connections to the directory service (see Figure 20.12). Figure 20.12 LDAP connection pool architecture.There are several advantages to having a shared pool of connections:
Although you may not need something as complex as a shared connection pool, it is worth considering what kind of architecture will help your application use the directory service efficiently and perform well. Tip One danger in using any abstraction layer, including something like the LDAP connection pool just described, is that you typically sacrifice some fidelity and lose the ability to take full advantage of all the LDAP features provided by the LDAP SDK. For example, suppose you implement a connection pool that does not allow you to use arbitrary LDAPv3 controls; if you later find that your application would work better if it used an LDAPv3 extension that requires you to send a control to the server, you would need to redesign your abstraction layer. Plan ahead, and use abstraction layers only when there is a clear advantage in doing so. All LDAP applications perform better if they avoid issuing extraneous operations and if they use simple operations as much as possible. By minimizing your application's impact on CPU, disk, memory, and other directory server resources, you improve the performance of all applications. When searching and reading entries, ask for only the attributes you need; do not retrieve all attributes from every entry. When modifying an entry, compare the new values with the ones already present in the entry and avoid sending unnecessary modify requests to the directory server. Use simple search filters whenever possible; for example, use an exact filter first, and then try a substring filter only if no entries are returned. Avoid building into your application assumptions about the total number of entries or the shape of the directory tree (e.g., flat or deep). If you expect a lot of entries to sometimes be returned from a search operation, take advantage of the LDAPv3 virtual list view extension to build a scalable user interface and allow you to process the entries in manageable chunks . Think carefully before you create an application that relies on being able to find all the entries in the directory at once. If your application includes a user interface for selecting directory entries, make sure it supports a search-based interface instead of (or in addition to) a list-based interface. Using these techniques will help your application handle thousands of entries and scale up gracefully as the directory service itself scales up. Developing a Prototype and Conducting a PilotOne of the best ways to prove your design and try out alternatives is to develop a working prototype. The prototype does not have to be complete or have the prettiest interface. A prototype can be created using scripting tools or other rapid application development (RAD) techniques, even if you plan to use different development tools for building the final application. In order to learn from it, your prototype should work and interact with other systems (including the directory service) in the same way you expect the final version of your application to do so. As soon as a working application exists, conduct a pilot test to solicit feedback and learn about any problems that should be fixed before you put the application into production service. The pilot should be done in an environment as similar as possible to the actual environment the application will be used in. Test your application's features, measure its performance, and solicit feedback from beta testers. Capture log files and other performance information and use them to conduct scaling tests to estimate the load your application will eventually place on the production directory service. Use the results of the pilot to improve your application, including how it interacts with the directory service. If you make substantial changes to your application after it is deployed, you may want to conduct another pilot. Leveraging Existing CodeIn many cases the applications you create will be similar to others for which the source code is readily available. Most SDKs come with sample code, and vendors such as Netscape and Microsoft make additional sample code available informally in newsgroups, in developer newsletters, and on developer CD-ROMs. The Internet at large is a great resource for locating complete directory-enabled applications; applications with freely available source code include LDAP-enabled mail transport agents (MTAs), several HTTP-to-LDAP gateways, and LDAP-enabled email clients . Within your own organization you may want to create a Web site to publish LDAP-related source code so that it can be reused by anyone creating a new LDAP application. Code modules explicitly designed to be reusable should be distributed in binary form as shared libraries or Java class files. Over time, try to build up a large collection of code to serve as the starting point for new applications. You should, of course, ensure that any code promoted for reuse is of good quality and demonstrates appropriate use of the directory service. Avoiding Common MistakesAs when writing applications for any service that provides a lot of flexibility and functionality, the process of writing LDAP applications has some pitfalls. Many newcomers to LDAP application development make the same mistakes as those who came before them. Here are some common mistakes you should avoid:
|
Index terms contained in this sectionabstraction layersapplication development abusive searches allowing application development mistakes access controls applications development needs applications developing common mistakes 2nd 3rd 4th 5th 6th 7th 8th communicating needs 2nd 3rd leveraging existing code 2nd performance and scalability 2nd 3rd 4th 5th 6th 7th pilots 2nd 3rd versatility 2nd 3rd 4th 5th 6th attributes mandatory avoiding (application development) communicating needs application development 2nd 3rd configurability application development developing applications common mistakes 2nd 3rd 4th 5th 6th 7th 8th communicating needs 2nd 3rd leveraging existing code 2nd performance and scalability 2nd 3rd 4th 5th 6th 7th pilots 2nd 3rd versatility 2nd 3rd 4th 5th 6th directories applications developing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th extending schema application development extensions schema application development needs extraneous operations avoiding application development leveraging applications existing code 2nd mandatory attributes avoiding application development mistakes application development allowing abusive searches improper zero-length password handling missing client-side size and time limits multiple value attribute storage as ordered lists storing large entries applications improper LDAP referral support patience with entry updates needs application development communicating 2nd 3rd password zero-length improper handling performance application development 2nd abstraction layers avoiding extraneous operations numbers of entries shared pool of connections 2nd piloting applications 2nd 3rd pool of connections shared application development 2nd privacy application development needs prototypes application development 2nd 3rd referrals improper support application development scalability application development 2nd abstraction layers avoiding extraneous operations numbers of entries shared pool of connections 2nd schema application development extending versatility extensions application development needs searches abusive application development mistakes security applications development needs privacy application development needs shared pool of connections application development 2nd storage directory service large entries versatility developing applications avoiding madatory attributes configurability extending schema making assumption using standard schema zero-length passwords improper handling |
2002, O'Reilly & Associates, Inc. |