JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Directory Server Enterprise Edition Reference 11 g Release 1 (
search filter icon
search icon

Document Information


1.  Directory Server Enterprise Edition File Reference

Software Layout for Directory Server Enterprise Edition

Directory Server Instance Default Layout

Directory Proxy Server Instance Default Layout

Part I Directory Server Reference

2.  Directory Server Overview

3.  Directory Server LDAP URLs

4.  Directory Server LDIF and Search Filters

5.  Directory Server Security

6.  Directory Server Monitoring

7.  Directory Server Replication

8.  Directory Server Data Caching

9.  Directory Server Indexing

10.  Directory Server Logging

11.  Directory Server Groups and Roles

12.  Directory Server Class of Service

About CoS

CoS Definition Entries and CoS Template Entries

CoS Definition Entry

CoS Template Entry

Pointer CoS, Indirect CoS, and Classic CoS

Pointer CoS

Indirect CoS

Classic CoS

Managing Attributes With Class of Service

Using CoS When Many Entries Share the Same Value

Using CoS When Entries Have Natural Relationships

Avoiding Excessive CoS Definitions

CoS Priorities

CoS Limitations

13.  Directory Server DSMLv2

14.  Directory Server Internationalization Support

Part II Directory Proxy Server Reference

15.  Directory Proxy Server Overview

16.  Directory Proxy Server Load Balancing and Client Affinity

17.  Directory Proxy Server Distribution

18.  Directory Proxy Server Virtualization

19.  Connections Between Directory Proxy Server and Backend LDAP Servers

20.  Connections Between Clients and Directory Proxy Server

21.  Directory Proxy Server Client Authentication

22.  Security in Directory Proxy Server

23.  Directory Proxy Server Logging

24.  Directory Proxy Server Alerts and Monitoring


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 Oracle Directory Server Enterprise Edition 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 12-5 Generating CompanyName With Pointer CoS

image:Figure shows the CompanyName attribute generated 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 12-6 demonstrates the use of indirect CoS to retrieve the department number from the manager entry. In Figure 12-7, the mail stop and fax number are retrieved from the administrative assistant entry.

Figure 12-6 Generating DepartmentNumber With Indirect CoS

image:Figure shows the DepartmentNumber attribute generated 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 12-6 example, the department number attribute value needs to be managed only on the manager's entry. Likewise, for the example shown in Figure 12-7, mail stop and fax number attributes need to be managed only on the administrative assistant’s entry.

Figure 12-7 Generating Mail Stop and Fax Number With Indirect CoS

image:Figure shows Mail Stop and Fax Number attributes generated 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 12-8 Generating Service-Level Data With Classic CoS

image:Figure shows service level data generated 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 12-8. 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.