Understanding and Deploying LDAP Directory Services > 5. Defining Your Directory Needs > Determining and Prioritizing Application Needs |
Determining and Prioritizing Application NeedsIt is important to focus first on LDAP-enabled applications when pondering your directory needs. This is because in most organizations one or possibly two important applications are the driving force behind the initial deployment of the directory service. If this is true in your organization, you can focus most of your energy on meeting the needs of these high-profile applications. If you succeed in deploying a directory service that makes these important applications look good, your co-workers , employees , and users will label the directory service a success as well. Note that you should avoid creating a directory service that is so focused on the needs of a small number of applications that it must be heavily redesigned later to accommodate other applications that come online. As you work through the various stages of designing your directory, remember to consider the broader, long- term picture. For example, you should favor general object classes over extremely specialized ones, assuming that the more general object classes meet the needs of your initial set of important directory applications. Applications' directory- related needs generally fall into one of these categories: data, performance, availability, level of service, security, and priorities. These are described in the following sections. DataAll directory-enabled applications access data that is stored in a directory service. For each application you plan to support, consider in general terms how it will use the directory and what data it requires to accomplish its mission. Does the application need to store a lot of data? A directory service may have limited capacity for data or may simply slow down as the number of entries and attributes stored in the service increases . It is important to understand the data-capacity needs of each application so you can plan appropriately. For example, a network printer location service may impose modest data scalability requirements; each printer entry will probably be small and most organizations do not own millions of printers. In contrast, a calendar or scheduling application that creates an entry for every meeting and task that appears on users' calendars may need to store a dozen or more attributes with each entry ”creating literally millions of entries in the directory. Meeting the needs of a scheduling application may require partitioning entries among several servers to achieve the required level of performance. How flexible is the application in terms of the schemas used in the directory? For example, a directory-enabled workflow system may require access to a lot of information about people and their organizational roles and relationships. Such an application may also use the directory for its security needs, so the directory may also be required to store passwords, public key-based certificates, and access-control information. Depending on how the workflow system is designed, it may be flexible or rigid about what schemas are used in the directory. Does the application have any special data needs such as storing unusual data that might require new syntaxes to be defined in the directory service? Is the information so dynamic that it does not necessarily need to be written to persistent storage? Special data needs may severely limit the choices of directory service software. PerformanceMost applications expect the directory service to meet certain standards for performance. Two aspects of directory performance are of special interest: latency and throughput. Latency refers to the elapsed time between when an application makes an LDAP request and when it receives the expected response. Typically, low latency is most important for applications that use the directory service as part of a larger task, or when an end user is waiting for a response. For example, telephone operators require very fast response time from a directory because they cannot move on to another call until they receive a response and pass it on to the current caller. Throughput refers to the total sustainable operation load that the directory can handle. It is possible for a directory service to have high latency (for example, each search takes two seconds to complete) and still have high throughput (for example, the server can process 1,500 searches every second). For applications that make heavy use of the directory, such as an email delivery system, throughput is the most important performance metric. You will need to think about how much work each application expects to be able to accomplish in a given time period. Be sure to distinguish read throughput requirements from write throughput requirements. An example of the throughput needs of a hypothetical email delivery system is shown in Figure 5.2. Figure 5.2 Throughput needs of a busy email service.Getting a handle on how well your directory service must perform will help produce a good design and ultimately result in a production directory service that enables the applications to perform well. It is always good to avoid a situation in which your directory service becomes a bottleneck for an important application. AvailabilityAvailability refers to the percentage of time the directory service is available for use by applications. This is another area in which different applications have different needs. If your mission is to support a telephone directory assistance service that is unavailable between midnight and five o'clock in the morning or on weekends, there is no need to design a directory service that is available 24 hours a day, 7 days a week (24 —7). You could schedule backups and system maintenance during nights and weekends, taking the entire system down during that time, if necessary. On the other hand, if the directory service is consulted by an application that controls access to a set of card-key activated doors within a hospital, 24 —7 availability may be crucial. Features such as the ability to perform backups and system maintenance while the directory service is running are essential to meet the need for 24 —7 availability. Level of ServiceRelated to availability is the level of service needed by an application. Level of service typically encompasses availability, robustness (that is, whether the directory data store is transactional and self-repairing), service monitoring, and disaster recovery procedures. If the application itself provides an experimental service that is not expected to always be available, it is acceptable to build the application on top of an experimental directory service. Much of the characterization of service level has to do with the expectations of the people who rely on a directory-enabled application. It is important to know what level of service each application expects so that you can design a service that meets this expectation. Tip Over time, your directory service will probably need to support a wide range of service levels, from experimental to production to mission-critical. You should keep this in mind as you define your needs, set requirements, and design your directory service. Sometimes it is difficult to raise the service level after a directory is deployed, so you need to make sure the software and hardware you select can meet your future needs. SecurityYou should consider the security requirements of your directory-enabled applications. Some application security requirements impose security requirements on your directory service as well. Consider these topics:
These topics are covered in greater detail in Chapter 11, "Privacy and Security Design." Prioritizing Application NeedsThe final step when examining any set of needs is to assign a set of priorities to each one. In principle this is a simple task, but if the applications your directory service is expected to support have a wide range of conflicting needs, setting priorities can be a challenge. A good technique is to make several passes through all the needs. In the first pass, just assign each application need to one of these three categories:
For example, the ability to customize the directory may be absolutely required in order to support an inflexible application. In contrast, extremely high directory throughput may help a heavily directory-dependent application work well, but there is probably some room for negotiation on the performance requirements. In the second pass, think about how important each application is and sort the needs within each category you assigned in the first pass. Because it is unlikely that you will be able to satisfy all the application requirements from the start, ordering the list of requirements is an important step that shows you where to focus your attention. Finally, make one more pass to check your work. This time, just look at the needs in the bottom half of your ordered priorities list and make sure none of them seem particularly important. If they do, move them up and reorder your list.
|
Index terms contained in this sectionaccess control requirementsapplication security needs applications directory needs 2nd availability data 2nd levels of service performance prioritizing security auditing requirements application security needs authentication requirements application security needs availability application needs data application needs 2nd defining directory needs application needs 2nd 3rd 4th 5th 6th 7th 8th 9th directories needs application needs levels of service application needs needs applications 2nd availability data 2nd levels of service performance prioritizing security directories application needs 2nd 3rd 4th 5th 6th 7th 8th 9th performance application needs latency throughput prioritizing application needs privacy requirements application security needs security application needs access control requirements auditing requirements authentication requirements privacy requirements standards performance application needs throughput application performance needs |
2002, O'Reilly & Associates, Inc. |