Managing Attributes With Class of Service
The Class of Service (CoS) mechanism allows attributes to be shared between entries. Like the role mechanism, CoS generates virtual attributes on the entries as the entries are retrieved. CoS does not define membership, but it does allow related entries to share data for coherency and space considerations. CoS values are calculated dynamically when the values are requested. CoS functionality and the various types of CoS are described in detail in the Sun Java System Directory Server Enterprise Edition 6.3 Reference.
The following sections examine the ways in which you can use the CoS functionality as intended, while avoiding performance pitfalls:
Note –
CoS generation always impacts performance. Client applications that search for more attributes than they actually need can compound the problem.
If you can influence how client applications are written, remind developers that client applications perform much better when looking up only those attribute values that they actually need.
Using CoS When Many Entries Share the Same Value
CoS provides substantial benefits for relatively low cost when you need the same attribute value to appear on numerous entries in a subtree.
Imagine, for example, a directory for MyCompany, Inc. in which every user entry under ou=People has a companyName attribute. Contractors have real values for companyName attributes on their entries, but all regular employees have a single CoS-generated value, MyCompany, Inc., for companyName. The following figure demonstrates this example with pointer CoS. Notice that CoS generates companyName values for all permanent employees without overriding real, not CoS-generated, companyName values stored for contractor employees. The company name is generated only for those entries for which companyName is an allowed attribute.
Figure 4–3 Generating CompanyName With Pointer CoS
In cases where many entries share the same value, pointer CoS works particularly well. The ease of maintaining companyName for permanent employees offsets the additional processing cost of generating attribute values. Deep directory information trees (DITs) tend to bring together entries that share common characteristics. Pointer CoS can be used in deep DITs to generate common attribute values by placing CoS definitions at appropriate branches in the tree.
Using CoS When Entries Have Natural Relationships
CoS also provides substantial data administration benefits when directory data has natural relationships.
Consider an enterprise directory in which every employee has a manager. Every employee shares a mail stop and fax number with the nearest administrative assistant. Figure 4–4 demonstrates the use of indirect CoS to retrieve the department number from the manager entry. In Figure 4–5, the mail stop and fax number are retrieved from the administrative assistant entry.
Figure 4–4 Generating DepartmentNumber With Indirect CoS
In this implementation, the manager’s entry has a real value for departmentNumber, and this real value overrides any generated value. Directory Server does not generate attribute values from CoS-generated attribute values. Thus, in the Figure 4–4 example, the department number attribute value needs to be managed only on the manager's entry. Likewise, for the example shown in Figure 4–5, mail stop and fax number attributes need to be managed only on the administrative assistant’s entry.
Figure 4–5 Generating Mail Stop and Fax Number With Indirect CoS
A single CoS definition entry can be used to exploit relationships such as these for many different entries in the directory.
Another natural relationship is service level. Consider an Internet service provider that offers customers standard, silver, gold, and platinum packages. A customer’s disk quota, number of mailboxes, and rights to prepaid support levels depend on the service level purchased. The following figure demonstrates how a classic CoS scheme enables this functionality.
Figure 4–6 Generating Servic-Level Data With Classic CoS
One CoS definition might be associated with multiple CoS template entries.
Avoiding Excessive CoS Definitions
Directory Server optimizes CoS when one classic CoS definition entry is associated with multiple CoS template entries. Directory Server does not optimize CoS if many CoS definitions potentially apply. Instead, Directory Server checks each CoS definition to determine whether the definition applies. This behavior leads to performance problems if you have thousands of CoS definitions.
This situation can arise in a modified version of the example shown in Figure 4–6. Consider an Internet service provider that offers customers delegated administration of their customers’ service level. Each customer provides definition entries for standard, silver, gold, and platinum service levels. Ramping up to 1000 customers means creating 1000 classic CoS definitions. Directory Server performance would be affected as it runs through the list of 1000 CoS definitions to determine which apply. If you must use CoS in this sort of situation, consider indirect CoS. In indirect CoS, customers’ entries identify the entries that define their class of service allotments.
When you start approaching the limit of having different CoS schemes for every target entry or two, you are better off updating the real values. You then achieve better performance by reading real, not CoS-generated values.
- © 2010, Oracle Corporation and/or its affiliates