Skip Navigation Links | |
Exit Print View | |
Oracle Directory Server Enterprise Edition Reference 11 g Release 1 (11.1.1.5.0) |
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
4. Directory Server LDIF and Search Filters
6. Directory Server Monitoring
7. Directory Server Replication
8. Directory Server Data Caching
11. Directory Server Groups and Roles
12. Directory Server Class of Service
CoS Definition Entries and CoS Template Entries
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
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
The following types of CoS differ in how the template, and therefore the generated value, is selected:
Pointer CoS is the simplest type of CoS. The pointer CoS definition entry provides the DN of a specific template entry of the cosTemplate object class. All target entries have the same CoS attribute value, as defined by this template.
The following figure shows a pointer CoS that defines a common postal code for all of the entries stored under dc=example,dc=com. The CoS definition entry, CoS template entry and target entry are indicated.
Figure 12-2 Example of a Pointer CoS Definition and Template
The template entry is identified by its DN, cn=exampleUS,cn=data, in the CoS definition entry. Each time the postalCode attribute is queried on entries under dc=example,dc=com, Directory Server returns the value available in the template entry cn=exampleUS,cn=data. Therefore, the postal code will appear with the entry uid=wholiday,ou=people,dc=example,dc=com, but it is not stored there.
In a scenario where several shared attributes are generated by CoS for thousands or millions of entries, instead of existing as real attributes in each entry, the storage space savings and performance gains provided by CoS are considerable.
Indirect CoS allows any entry in the directory to be a template and provide the CoS value. The indirect CoS definition entry identifies an attribute, called the indirect specifier, whose value in a target entry determines the template used for that entry. The indirect specifier attribute in the target entry must contain a DN. With indirect CoS, each target entry may use a different template and thus have a different value for the CoS attribute.
For example, an indirect CoS that generates the departmentNumber attribute may use an employee’s manager as the specifier. When retrieving a target entry, the CoS mechanism will use the DN value of the manager attribute as the template. It will then generate the departmentNumber attribute for the employee using the same value as the manager’s department number.
Note - Because templates may be arbitrary entries anywhere in the directory tree, implementing access control for indirect CoS can become extremely complex. In deployments where performance is critical, you should also avoid overusing indirect CoS due to its resource intensive nature.
In many cases, results that are similar to those made possible by indirect CoS can be achieved by limiting the location of the target entries with classic CoS or using the less flexible pointer CoS mechanism.
The following figure shows an indirect CoS that uses the manager attribute of the target entry to identify the template entry. In this way, the CoS mechanism can generate the departmentNumber attribute of all employees to be the same as their manager’s, ensuring that it is always up to date.
Figure 12-3 Example of an Indirect CoS Definition and Template
The indirect CoS definition entry names the specifier attribute, which in this example, is the manager attribute. William Holiday’s entry is one of the target entries of this CoS, and his manager attribute contains the DN of uid=cfuentes,ou=people,dc=example,dc=com. Therefore, Carla Fuentes’s entry is the template, which in turn provides the departmentNumber attribute value of 318842.
Classic CoS combines the pointer and indirect CoS behavior. The classic CoS definition entry identifies the base DN of the template and a specifier attribute. The value of the specifier attribute in the target entries is then used to construct the DN of the template entry as follows:
cn=specifierValue, baseDN
The template containing the CoS values is determined by the combination of the RDN (relative distinguished name) value of the specifier attribute in the target entry and the template’s base DN.
Classic CoS templates are entries of the cosTemplate object class to avoid the performance issue associated with arbitrary indirect CoS templates.
The classic CoS mechanism determines the DN of the template from the base DN given in the definition entry and the specifier attribute in the target entry. The value of the specifier attribute is taken as the cn value in the template DN. Template DNs for classic CoS must therefore have the following structure:
cn=specifierValue,baseDN
The following figure shows a classic CoS definition that generates a value for the postal code attribute.
Figure 12-4 Example of a Classic CoS Definition and Template
In this example, the cosSpecifier attribute names the employeeType attribute. The combination of the cosSpecifier attribute and the template DN identifies the template entry as cn=sales,cn=exampleUS,cn=data. The template entry then provides the value of the postalCode attribute to the target entry.