Définition d’objets : objets classSchema

classe parent de la classe, appelée superclasse)
3/ les relations entre les attributs et les objets classSchema (les attributs obligatoires et facultatifs de la classe, par exemple)

  Le tableau 1, montre les attributs obligatoires et facultatifs qu’AD utilise normalement pour créer un objet classSchema. (Pour obtenir la liste complète des attributs disponibles, visiter le Microsoft Developer Network – MSDN – à  http://msdn.microsoft.com/library/psdk/asdi/glschema3_88fn.htm). Chaque objet classSchema appartient à  l’une des trois catégories de classes : abstract, auxiliary et structural.

  Classe abstract. Les objets classSchema (c’est-à -dire les classes) qui appartiennent à  la catégorie abstract servent comme occupants de place (placeholders) ; on ne peut pas utiliser ces classes pour créer une instance d’objet dans un autre AD NC. AD utilise les classes abstract principalement comme classes parentes, ou superclasses, pour les autres classes, afin que l’on puisse créer une structure hiérarchique des classes objet et définir un système d’héritage d’attributs entre les classes. (Un attribut subClassOf de classe nomme sa superclasse.) Les classes abstract ne sont pas dédiées à  l’héritage, mais c’est leur principal objectif. Les objets classSchema d’abstract ont une valeur d’attribut objectClassCategory de 2.

  Classe Auxiliary. Les objets classSchema auxiliary sont semblables aux classes abstract en ce qu’on ne peut pas utiliser ces classes pour créer des instances d’objet AD. Les classes auxiliary sont semblables à  des fichiers include ou header : on peut utiliser cette catégorie de classes pour inclure un ensemble d’attributs multiples dans la définition d’une autre classe. (Les attributs systemAuxiliaryClass et auxiliaryClass sont des attributs multivaleurs ; autrement dit, il peut exister de nombreuses classes auxiliary pour un objet classSchema. Un attribut monovaleur ne peut contenir qu’une valeur ; un attribut multivaleur peut en contenir plusieurs.)

   Quand on installe Exchange 2000 dans une forêt AD, l’Exchange 2000 Setup ajoute de nombreuses classes au schéma AD. Certaines d’entre elles appartiennent à  la catégorie auxiliary et définissent des attributs qui sont propres à  Exchange 2000. Les attributs systemAuxiliaryClass ou auxiliaryClass d’un objet classSchema définissent n’importe quel objet de classe auxiliary applicable. Les classes auxiliary ont une valeur d’attribut objectClassCategory de 3.

  Classe structural. La classe structural est le seul type de classe que l’on peut utiliser pour créer des instances d’objets dans d’autres AD NC. Les objets classSchema de structural utilisent les attributs systemPossSuperiors et possSuperiors pour définir la classe sous laquelle une instance créée de la classe peut résider. (Par exemple, l’attribut systemPossSuperiors de la classe user définit la classe organizationalUnit comme un conteneur possible pour des instances de la classe user, et donc on peut créer un objet User dans une instance de la classe organizationalUnit.) Ces définitions sont connues en tant que règles d’instanciation. La valeur de l’attribut objectClassCategory de l’objet classSchema structural est de 1.

   La figure 4 montre comment les trois types de classes travaillent ensemble. Top est un objet classChema abstrait qui sert comme superclasse de l’objet classSchema abstrait Person. Person, à  son tour, sert de superclasse à  l’objet classSchema abstrait organizationalPerson. Cet objet sert comme la superclasse de la classe user (c’est-à -dire, l’objet classSchema user). L’objet classSchema user est un objet de classe structural qui définit User objects (c’est-à -dire des instances de la classe user).

   Comme le montre la figure 4, la classe user hérite des attributs de ses superclasses et de diverses classes auxiliary. Tous les objets ont un jeu d’attributs obligatoires et un jeu d’attributs facultatifs. Les attributs systemMustContain et mustContain d’un objet classSchema définissent ces attributs obligatoires ; les attributs systemMayContain et mayContain d’un objet classSchema définissent les attributs facultatifs de l’objet. ADSI Edit ne montre aucune valeur définie pour les attributs systemMustContain et mustContain de la classe user. Cela ne signifie pas que la classe user n’ait pas d’attributs obligatoires. Bien au contraire, la classe user hérite des attributs obligatoires de ses superclasses (Person, par exemple) et de ses classes auxiliary (mailRecipient, par exemple).