Exit Print View

Sun OpenDS Standard Edition 2.0 Architectural Reference

Get PDF Book Print View

Document Information

The Directory Server Access Control Model

Understanding the Directory Server Schema

Understanding Matching Rules

Matching Rule Description Format

Commonly Used Matching Rules

Value Normalization

Understanding Attribute Syntaxes

The Attribute Syntax Description Format

Commonly Used Attribute Syntaxes

Understanding Attribute Types

Attribute Type Description Format

Attribute Type Inheritance

Attribute Type Implementation

Understanding Object Classes

Object Class Description Format

Object Class Kinds

Object Class Inheritance

Directory Server Object Class Implementation

Understanding Name Forms

Name Form Description Format

Name Form Implementation

Understanding DIT Content Rules

DIT Content Rule Description Format

DIT Content Rule Implementation

Understanding DIT Structure Rules

DIT Structure Rule Description Format

DIT Structure Rules and Multiple Schemas

DIT Structure Rule Implementation

Understanding Matching Rule Uses

Matching Rule Use Implementation

Index Databases

Understanding Directory Server Plug-Ins

Directory Server Replication

Root Users and the Privilege Subsystem

Supported Controls and Operations

Object Class Kinds

As described in Object Class Description Format, all object classes must have a kind of either ABSTRACT, STRUCTURAL, or AUXILIARY:

The model represented by object class kinds translates very neatly to the model used by the Java programming language. Abstract LDAP object classes map directly to Java abstract classes, auxiliary LDAP object classes map directly to Java interfaces, and structural LDAP object classes map directly to Java concrete (non-abstract) classes. Just as Java classes must extend exactly one superclass but can implement any number of interfaces, so must LDAP entries contain exactly one structural class chain but can include any number of auxiliary class chains. Similarly, just as it is not possible to directly instantiate an abstract Java class, it is also not possible to create an LDAP entry containing only abstract object classes.

The Sun Java System directory server has never enforced many of the restrictions noted here around object class kinds. In particular, it would allow the creation of entries that did not contain any structural object class chain and would also allow the creation of entries containing multiple structural object class chains. This means that deployments using the Sun Java System directory server can contain entries that violate this constraint. The directory server does not allow this behavior by default, but for the sake of compatibility with existing Sun Java System directory server deployments, it is possible to configure the directory server to allow entries to violate this constraint, optionally writing a message to the directory server's error log each time this condition is detected. However, if there are entries that do not contain exactly one structural object class, then some schema elements like name forms and DIT content rules that depend on this constraint might not work as expected in all cases.