VI: Case Studies

Understanding and Deploying LDAP Directory Services > 5. Defining Your Directory Needs > Determining and Prioritizing Application Needs

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053055078208056179128240001057051

Determining and Prioritizing Application Needs

It 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.

Data

All 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.

Performance

Most 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.

Availability

Availability 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 Service

Related 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.



Security

You 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:

  • Privacy requirements.   How secret is the data that is to be transferred between the application and the directory servers? Should encryption be used to protect the information? For information that needs protection, what strength of encryption is required?

  • Authentication requirements.   Are simple passwords sufficient? Should one-time passwords be used instead? Must public key-based certificates be used to authenticate applications and users? Or smart cards?

  • Access control requirements.   Does the application need to be able to restrict access to directory information? What special needs does the application have?

  • Auditing requirements.   Must a log of all directory activity be maintained so that a security audit can be performed? For how long must the activity log be kept?

These topics are covered in greater detail in Chapter 11, "Privacy and Security Design."

Prioritizing Application Needs

The 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:

  • Must have for the application to function

  • Would help the application do its job better

  • Nice to have, but not critical

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.



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

Index terms contained in this section

access control requirements
          application 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.



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