Reasons to Develop Directory-Enabled Applications

   

Reasons to Develop Directory-Enabled Applications

Creating LDAP directory-enabled applications enables you to

  • Lower your data management costs . By using a shared directory to avoid use of application-specific data stores, your organization saves money that would otherwise be spent maintaining redundant data.

  • Adapt the directory to fit your organization . One example of such adaptation is the creation of custom tools to streamline various directory management and application management tasks .

  • Save on application development, deployment, and maintenance costs . LDAP applications are easy to develop, and compared to a relational database management system (RDBMS) data store, LDAP directories are often cheaper to deploy and maintain. LDAP applications are also very portable: If written correctly, they will work with a variety of standards-compliant directory servers. In addition, the value of many kinds of applications is enhanced if they can easily access the timely , accurate data that is often stored in a directory service.

  • Create entirely new kinds of applications . By leveraging the directory infrastructure, you can relatively easily create applications that would normally be difficult to develop.

Each of these benefits is discussed further in the following sections. After that, we provide a few reasons why it may not make sense to directory-enable an application.

Lowering Your Data Management Costs

If the application being developed needs access to data already stored in your directory, or if the data it uses must be shared with other applications, using a private data store is an expensive mistake. By leveraging your deployed directory service, you avoid creating a new data store that must be designed, deployed, and maintained . By using your directory service as a rendezvous point for applications that share data elements, you avoid the need for troublesome data synchronization between data stores.

Suppose you plan to develop a set of Web-based applications to automate common employee tasks such as requesting time off, registering car license plate numbers for use by the security office, and providing feedback about manager performance. Without a central directory service, each application might have its own database of information about employees , including user passwords and the names of their managers. Figure 21.1 illustrates this unhappy situation.

Figure 21.1. Applications with Redundant Data Stores

A better approach is to design each application to use your directory service. The time-off request and manager feedback applications both need access to the manager's name , and all the applications need to authenticate employees with user IDs and passwords. Storing all the shared information in your directory service eliminates redundant data elements and extra databases. Figure 21.2 shows the revised approach.

Figure 21.2. Applications That Share a Directory Service

The picture is much simpler now, and in this case a simpler architecture translates directly into reduced data maintenance costs.

Adapting the Directory to Fit Your Organization

It is rare to find a perfect fit between the way different people want to work and available off-the-shelf directory tools. You'll most likely want to develop new LDAP applications yourself to help streamline maintenance and everyday use of your directory service.

For example, a common task for a Help Desk is resetting user passwords. Help Desk employees can accomplish this simple task by using any of the user and group management interfaces that directory vendors ship with their products. However, you may want to develop a more focused tool that fits your preferred way of handling password resets. For example, your new tool might generate a new random password to increase security (by avoiding repeated use of the same password by Help Desk employees).

Such a custom password-resetting tool might work as shown in Listing 21.1. Here the Help Desk employee identified as kvaughan resets the password for the user identified as bjensen . Source code for the setpwd utility is provided later in this chapter. Custom applications of this kind range from small, focused utilities such as setpwd to large, complex applications that perform a variety of management tasks.

Listing 21.1 Using a Custom Password-Resetting Application
  setpwd bjensen  Password for kvaughan:  secret  Contacting LDAP server... Finding bjensen's entry... Modifying bjensen's entry... Password reset.  bjensen's new password is: scroll.insofar7. Don't forget to remind bjensen to reset his/her password right away! 

Saving on Deployment and Maintenance Costs

After you have deployed a directory service, the incremental cost of supporting additional applications is quite low. There is no need to discard what you have already done and start over. Most of the directory design, maintenance, and support infrastructure already in place can be expanded incrementally to accommodate new applications. For applications that require a data store of some kind, you must often choose between using your directory service and using a traditional RDBMS such as an Oracle or IBM DB2 system. Directory servers are typically less expensive to purchase, deploy, and maintain than RDBMS servers. Through the use of replication, directories can scale up to provide high-performance access for many applications. Directories are flexible and therefore easy to change to support the needs of new applications.

For example, adding new schema elements ( columns ) to an RDBMS table usually requires that the existing database be shut down and rebuilt with a special utility. This is a tedious , time-consuming process that may disrupt database service for existing applications. In contrast, new schema elements (object classes and attribute types) can be added to most LDAP directories at any time; there is no need to shut down the service.

Another important factor is that often a lot of effort is invested in deploying a directory service that contains timely, accurate data. Applications that need access to that kind of data will be simpler to create and will work better if they use such a directory service. For example, many companies require that their critical customer support employees carry pagers , and they use a scheme in which different employees are on call (eligible to be paged) during different portions of the day. If a directory service contains accurate information about which employees are on call, then all software that automatically pages employees should access the directory to determine where to direct a page. This sounds simple and obvious ”and it is ”but many systems have been deployed in which each software application that sends pages has its own database of pager numbers and other information that must be maintained independently or synchronized with a directory service.

Creating Entirely New Kinds of Applications

An open , standards-based directory provides a great rendezvous point for distributed applications. It also frees information that was previously locked away inside proprietary data stores for use by innovative application developers. You may discover that some kinds of applications that were impossible or very difficult to create without a central directory service are now easy to create.

In many organizations, for example, a small army of departmental administrative assistants is responsible for creating and publishing organization charts. New charts are typically created through a manual process and then published inside the company about once a month and distributed in paper form. By leveraging a directory service that contains basic information about employee relationships, you can develop an application that creates organization charts on demand. Advantages of such an application include reduced costs for maintenance of the data, elimination of distribution costs, and access to more up-to-date organization charts . Figure 25.10, which is part of Chapter 25, Case Study: A Large Multinational Enterprise, shows a prototype of a directory-based organizational chart application.

The convergence of LDAP, HTTP, HTML, XML, and other Internet standards means that it's easier than ever before to build applications that pull together information and make it available to wide audiences at low cost.

When It Does Not Make Sense to Directory-Enable

It doesn't make sense to integrate every new application with your LDAP directory service. In Chapter 1, Directory Services Overview and History, you learned what a directory service is and is not good for. Generally, the kind of applications that would not benefit from being directory-enabled are those that use only private, application-specific data that does not need to be shared with other applications.

Tip

In a few cases there may be some benefit to storing private data in a centralized or private directory service ”that is, if doing so reduces the pain of managing the data, allows new end-user features to be provided, or is more convenient for other reasons. For example, by storing data in a directory service instead of on a local PC, applications can provide location independence for users (also called roaming ). Storing application-specific data in a shared, network-accessible directory instead of in a local file system allows an application to retrieve the information regardless of where on the network it executes. And it may occasionally be advantageous to use a private, application-specific directory service based on LDAP because of LDAP's rich data model and the availability of good tools, SDKs, and servers.


Another guideline is that applications whose data- related requirements violate your data policy should not be directory-enabled (see Chapter 7, Data Design, for information on creating a data policy). Unless you are willing to change your policy, it makes no sense to go through the trouble of writing the application so that it can use your directory service. For example, suppose your data policy stipulates that no private data such as a person's date of birth, photograph, or U.S. Social Security number should be stored in your directory. In that case, you shouldn't bother directory-enabling any applications that need to store Social Security numbers. That data should instead be stored in secure, private, application-specific databases.

   


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

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