X500Standard.com

Object class concept

The X.500 directory has taken some of its terminology from the object oriented (OO) theory that was emerging at the time when the X.500 development began. However, directory has only little in common with the OO technology.

Anyway, there are some similarities with the object oriented (OO) theory such as the concept of object classes, the concept of inheritance and the concept of attribute types associated with an object class. There are also significant differences. An object in directory sense is outside the directory and not the target for any directory operation. A directory object is represented by a directory entry. All directory operations are on that entry. It is not part of an object class definition what kind of operations that can be performed on the corresponding entries. Further, the OO encapsulation concept is not applicable to directory. There are also some directory object concepts that have no counterparts in the OO theory, such as rules for placement of entries in the DIT.

An object represented in a directory is a reflection of certain aspects of some "real world" object. Examples of such real world object are countries, organizations, organizational persons, printer servers, etc. Different aspects of the same real world object can be viewed as different directory objects. As an example, a person can at the same time be an organizational person and a residential person.

Definition of object classes

An object class determines what attribute types must and may held by entries. An object class specification includes a list of what attributes shall and what attributes may be held by an entry of that object class, that is, the specification includes a list of mandatory and optional attributes.

An object class is defined using an ASN.1 information object class much in the same way as for attribute types. As for attribute type definitions, do not try to understand the sublime philosophy behind the specification, just consider it as a shorthand notation. An example of an object class definition is given below:

person OBJECT-CLASS ::= {
      SUBCLASS OF { top }
      KIND          structural
      MUST CONTAIN  { commonName | surname }
      MAY CONTAIN   { description |
                    telephoneNumber |
´                   userPassword |
                    seeAlso }
      ID            id-oc-person }

Example 1 - Object Class Definition

The label (the person in the example) is the identifier for the object class.

The SUBCLASS and the KIND specifications are explained later on this page.

The MUST CONTAIN specification is a list of mandatory attribute types that shall be present in an entry of the object class. The MAY CONTAIN specification is a list of optional attributes types that may or may not be present. A DSA implementation is required to ensure that when an entry is created or modified, it holds all mandatory attributes, but holds no additional attributes that are not in the optional list. However, optionality is only with respect to the content of the individual entry and not with respect to DSA capabilities. A DSA must be able to support also the optional attribute types.

An object class is like an attribute type identified by an object identifier. id-oc-person in above example is a reference to this object identifier value. An entry always contains an attribute called objectClass, which has as value the object identifier of the object class from which it is instantiated. (Why this attribute type is not in the mandatory list in the example above will be clear later.) A DUA can read this attribute and thereby implicitly know the characteristics of the entry.

Subclasses and Inheritance

To minimise redundant specifications, the OO concepts of subclassing and inheritance have been applied. Object class inheritance allows one object class to inherit attributes of one or more other object classes. This is illustrated in the figure above, where object class B is said to be a subclass of object class A. The concept of deriving subclasses can be extended to derive subclasses of subclasses to any depth. Object class C in the figure is a subclass of object class B as well as of object class A.

Object class A is a superclass of both object classes B and C. Object class B is also a superclass of object class C. Object class A is a direct superclass of object class B, and so is object class B of object class C.

The object class (type) hierarchy illustrated in the figure should not be confused with the entry (instance) hierarchy within the DIT.

The figure above further illustrates the concept of inheritance. Object class B is here a subclass of object class A. Object class B does not only include the mandatory and optional attributes listed as part of its specification, but also inherits those of the object class A specification not already part of the object class B specification. In case the object class B specification directly includes a particular attribute and inherits the same attribute from a superclass, this does not result in multiple occurrences of the same attribute type. A mandatory specification takes precedence as illustrated by Attr-3 in the figure above. The object class B to the right in figure shows the result of object class B being a subclass of object class A.

The following example is a specification of a subclass:

organizationalPerson OBJECT-CLASS ::= {
      SUBCLASS OF	{ person }
      MAY CONTAIN	{ LocaleAttributeSet |
                    PostalAttributeSet |
                    TelecommunicationAttributeSet |
                    organizationalUnitName |
                    title }
      ID            id-oc-organizationalPerson }

Example 2 - Definition of Subclass

The above is a specialisation of the person object class in example 1. It adds some attribute types to an entry, which are relevant for an organisational person in addition to those attributes type relevant for all types of persons.

The object class in example 1 is defined as a subclass of top. top is a so-called abstract object class, which in OO terms is a virtual object class that cannot be instantiated. It is used as superclass for other object classes. It has objectClass as a mandatory attribute type. All entries in the DIT must therefore hold an attribute of that type.

To summarise by referring to the first figure, an entry may be instantiated from any of the object classes A, B, and C. If it is from object class A, it has only the A-properties. If it is from object class C, it has the combined properties of A, B and C. In the latter case, the object identifiers of all the three object classes are values of the objectClass attribute of the entry.

The multiple inheritance concept is also part of the directory object model as illustrated in figure the figure below.

Multiple inheritance implies that an object class can have several direct superclasses. In the figure, object class D has three direct superclasses. Object class D therefore inherits all the attribute types specified for object classes A, B, and C.

Structural and auxiliary object classes

The directory object model has introduced the concept of auxiliary object classes. This concept is based on the following:

• The directory object model allows an entry to be instantiated from several object classes. This is illustrated in the figure below. Such an entry will have the combined characteristics of those entire object classes.
• The hierarchy of entries in the DIT should be regulated in some way by applying certain rules as to how entries of different object classes should be placed with respect to each other. An example of such a rule could be that an organizational person entry shall be just below either an organization entry or an organizational unit entry. Such rules are called structure rules. Clearly, only one of the object classes from which an entry is created can have an associated structure rule. This object class is called the structural object class while the other classes are called auxiliary object classes. This is also illustrated in the figure below.

The structural object class is the object class that actually represents the corresponding real world object, while auxiliary object classes, as the name indicates, do not in themselves represent a particular real world object, but only represents additional attributes that can be associated with some structural object class to supplement its specification. CEN/ISSS has defined some auxiliary object classes for general use.