Show Table of Contents
5.3. About Classes of Service
A class of service (CoS) shares attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.
For example, the directory contains thousands of entries that all share the common attribute
facsimileTelephoneNumber. Traditionally, to change the fax number required updating each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, the attribute value can be generated dynamically. The
facsimileTelephoneNumberattribute is stored in one location, and each entry retrieves its fax number attribute from that location. For the application, these attributes appear just like all other attributes, despite not actually being stored on the entries themselves.
Each CoS is comprised of the several entries in the directory:
The CoS definition entry and the template entry interact to provide attribute values to their target entries, the entries within their scope.The value they provide depends upon the following:
- The entry's DN (different portions of the directory tree might contain different CoS).
- A service class attribute value stored with the entry.The absence of a service class attribute can imply a specific default CoS.
- The attribute value stored in the CoS template entry.Each CoS template entry supplies the attribute value for a particular CoS.
- The object class of the entry.CoS attribute values are generated only when an entry contains an object class allowing the attribute when schema checking is turned on; otherwise, all attribute values are generated.
- The attribute stored in some particular entry in the directory tree.
Do not index attributes you use in in a CoS definition (
Roles and the classic CoS can be used together to provide role-based attributes. These attributes appear on an entry because it possesses a particular role with an associated CoS template. For example, use a role-based attribute to set the server look-through limit on a role-by-role basis.
5.3.1. About a Pointer CoS
A pointer CoS identifies the template entry using the template DN only. There may be only one template DN for each pointer CoS. A pointer CoS applies to all entries within the scope of the template entry.
For example, the pointer CoS in Figure 5.1, “Sample Pointer CoS” shares a common postal code with all of the entries stored under
Figure 5.1. Sample Pointer CoS
The template entry is identified by its DN,
cn=exampleUS,cn=data, in the CoS definition entry. Each time the
postalCodeattribute is queried on the entry
cn=wholiday,ou=people,dc=example,dc=com, the Directory Server returns the value available in the template entry
5.3.2. About an Indirect CoS
An indirect CoS identifies the template entry using the value of one of the target entry's attributes. The target entry's attribute must contain the DN of an existing entry.
Figure 5.2. Sample Indirect CoS
In this example, the target entry for William Holiday contains the indirect specifier, the
managerattribute. William's manager is Carla Fuentes, so the
managerattribute contains a pointer to the DN of the template entry,
cn=Carla Fuentes,ou=people,dc=example,dc=com. The template entry in turn provides the
departmentNumberattribute value of
5.3.3. About a Classic CoS
A classic CoS identifies the template entry by both its DN and the value of one of the target entry's attributes. Classic CoS can have multiple template entries, including a default CoS template to be applied to those entries that do not belong to any other CoS template.
Figure 5.3. Sample Classic CoS
In this example, the CoS definition entry's
cosSpecifierattribute specifies the
employeeTypeattribute. This attribute, in combination with the template DN, identify the template entry as
cn=sales,cn=exampleUS,cn=data. The template entry then provides the value of the
postalCodeattribute to the target entry.