Directory Services Time Line

Understanding and Deploying LDAP Directory Services > 20. Developing New Applications > Reasons to Develop Directory-Enabled Applications

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012002230017025104003158006

Reasons to Develop Directory-Enabled Applications

You may already be aware from experience of many of the reasons it makes sense to integrate applications with your directory service. By creating LDAP directory-enabled applications you can do all of the following:

  • Lower your data management costs.   By avoiding 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 this is the creation of custom tools to streamline the directory management and application management tasks performed by various groups within your organization.

  • Save on application development, deployment, and maintenance costs.   LDAP applications are easy to develop, and, compared to a RDBMS data store, LDAP directories are cheaper to deploy and maintain.

  • Create entirely new kinds of applications.   By leveraging the directory infrastructure, applications that would normally be difficult to develop can be created with relative ease.

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 may 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. (Note that we use the phrase rendezvous point throughout this chapter as a general term to refer to a service, such as a directory, that supports access to the same data by a set of cooperating applications.)

Suppose you plan to develop a set of Web-based applications for automating a few 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 the use of a central directory service, each application might have its own database of information about employees , including user passwords and the names of their managers. This unhappy situation is shown in Figure 20.1.

Figure 20.1 Applications with redundant data stores.

A better approach is to write each application so that it uses 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; by storing all the shared information in your directory service, redundant data elements and the extra databases are eliminated. This approach is shown in Figure 20.2.

Figure 20.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 that different people in an organization 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 help desk employees is resetting user passwords. Although this simple task can be accomplished using any of the user and group management interfaces that directory vendors ship with their products, you may want to develop a more focused tool that fits your preferred way of handling password resets. Your new tool might, for example, generate a new random password to increase security (by avoiding the use of the same password over and over again by help desk employees). Such a custom password-setting tool might work as shown in Listing 20.1.

Listing 20.1 Using a custom password-resetting application

Using a custom password-resetting application % setpwd bjensen Contacting LDAP server Finding entry bjensen Modifying entry bjensen Password reset. bjensen's new password is: eMpress*stinkpot8 Don't forget to remind bjensen to reset his/her password right away!

Applications of this type range from small, focused utilities such as setpwd to large, complex applications that perform a variety of management tasks. (Sample code for a custom setpwd command-line utility is provided later in this chapter.)

Saving on Deployment and Maintenance Costs

After you have deployed a directory service, the incremental cost incurred to support 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 some kind of data store to function, you must often choose between using your directory service and using a traditional RDBMS such as an Oracle system. Directory servers are typically less expensive to purchase, deploy, and maintain than RDBMS servers. Through the use of replication, directories can also 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 to an RDBMS usually requires that the existing database be shut down and rebuilt using a special utility. This is a tedious , time-consuming process that requires database services to other applications to be disabled. In contrast, new schemas can be added to LDAP directories via LDAP itself at any time; there is no need to shut down the service.

Creating Entirely New Kinds of Applications

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

For example, in many organizations, a small army of departmental administrative assistants is responsible for creating and publishing organization charts. New charts are typically created using 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, an application that creates organization charts on demand can be easily developed. 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 20.3 shows Oblix's Corporate Directory application, a commercial package that includes, among other features, an interactive, dynamic organization chart viewer that leverages LDAP directory information.

Figure 20.3 Oblix's Corporate Directory application.

The convergence of LDAP, HTTP, HTML, and other Internet standards means that it's easier than ever before to build applications that pull together essential organizational 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," you learned what a directory service is and is not good for. Generally, applications that use only private data that does not need to be shared with other applications would not benefit from being directory-enabled. If the data is truly application-specific and never to be shared, there is no reason to store it in a directory service.

Tip

One exception to this guideline: There may be some benefit to storing private data in a centralized directory service if doing so reduces the pain of managing the data or allows new end user features such as location independence (also called roaming ). In the latter case, storing application-specific data in a shared, network-accessible directory instead of a local file system or registry allows the application to retrieve the information it needs no matter where on the network it is executed.



Another guideline is that applications whose data needs violate your directory data policy should not be directory-enabled (see Chapter 6, "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 for use with your directory service. For example, suppose your data policy stipulates that no private data such as date of birth, personal 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 private, application-specific databases.



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

Index terms contained in this section

applications
          developing 2nd
                    avoiding development 2nd 3rd
                    entirely new applications 2nd
                    lowering data management costs 2nd 3rd 4th
                    reducing deployment and maintenance costs 2nd 3rd
                    streamlining use 2nd
avoiding
          application development 2nd
                    policy violations
costs
         data management
                    lowering 2nd 3rd 4th
         deployment and maintenance
                    reducing 2nd 3rd
custom applications
          password-resetting program (listing) 2nd
data
         management
                    lowering costs 2nd 3rd 4th
deployment
         reducing costs
                    by developing applications 2nd 3rd
developing
          applications 2nd
                    avoiding development 2nd 3rd
                    entirely new applications 2nd
                    lowering data management costs 2nd 3rd 4th
                    reducing deployment and maintenance costs 2nd 3rd
                    streamlining use 2nd
directories
         applications
                    developing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
distributed applications
          developing
                    organization charts
leveraging
          applications 2nd
                    avoiding development 2nd 3rd
                    entirely new applications 2nd
                    lowering data management costs 2nd 3rd 4th
                    reducing deployment and maintenance costs 2nd 3rd
                    streamlining use 2nd
listings
          custom password-resetting application 2nd
maintenance
         reducing costs
                    by developing applications 2nd 3rd
organization charts
          developing applications
passwords
         custom resetting application
                    listing 2nd
reducing
         costs
                    deployment and maintenance 2nd 3rd
         data management costs
                    with application development 2nd 3rd 4th

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