|
|
|
|
|
 |
introduction |
|
|
|
Novell no longer maintains a vendor-accessible Directory OID/Prefix Registry to generate Class and an Attribute OIDs based on Novell’s address space. OIDs may be obtained from ANSI, IANA, or any other ISO Name Registration Authority.
The reason for registering schema extensions is to resolve the possibility of schema collisions caused by duplicate schema names with different definition structures, and to promote developers to create technology forums to define industry-standard schema to be considered for inclusion into the base schema. If schema registry recommendations are followed, porting applications to future schema architectures will be eased.
Novell recommends that you register an extension whenever you need to modify the Novell base schema. When you register, you select a unique prefix, and are assigned an ASN1 ID (or OID) that you can use. With these two elements, your extensions are assured of some important features.
- One, they won't be in conflict with other registered extensions
- and two, you are assured of a valid and unique OID
Assigned ANSI or IANA OIDs or some child of an ANSI or IANA OID may be associated with a name prefix. If application for an OID is in process, the OID field may be left blank on the application for a name prefix. Then when the OID is obtained, the OID can be associated with the name prefix. Once the prefix and subarc are recorded, you can create as many class and attribute extensions as needed.
Name prefix registration allows a developer to immediately design and implement schema extensions that are unique in Novell eDirectory with the current schema definitions. A name prefix may be up to 8 alpha-numeric characters. Name prefixes are requested by the registrar upon application (see attached name prefix application form,) but must be applicable to the name of your product, business, or technology forum. Previously registered name prefixes will generally be rejected so that name prefixes will not be registered to two different entities.
|
|
|
notes on schema extensions |
|
|
|
|
Schema changes are not always easily removed, and therefore design and experimentation should take place in a test environment, in case you want (or need) to start over. Attributes can only be removed if they are not used in a class definition. If you add attributes to Novell base classes, you will not be able to remove them. Classes can be removed as long as there are no objects instantiated of that class type. Novell base schema cannot be removed.
|
|
|
tools for extending the schema |
|
|
|
|
Classes and attributes can be added one at a time using the Schema Manager tool within ConsoleOne. There are also several methods for adding multiple extensions at once. It can be done programmatically using LDAP APIs (C or JAVA), JNDI (from NJCL or with the LDAP service provider), and eDirectory C APIs. It can also be done using an LDIF file and the Novell Import Convert Export utility, or with an ldapmodify utility. With eDirectory 8.5, Novell recommends using the command line version of the Novell Import Convert Export utility.
|
|
|
use existing schema whenever possible |
|
|
|
|
There are ways to avoid making unnecessary schema extensions. This is important, because the schema has to be synchronized throughout the directory tree, and performance can eventually be impacted if the schema becomes too large. Up-front design is very important when making schema extensions. Evaluate what classes and attributes will be needed. Then go through the base schema and see what is already in place that may meet your needs. There may be many attributes that could be used in custom classes. There is no limitation to how many classes can use any one attribute. Also check to see if there is a class that is similar to your needs, and either derive from that class, or use auxiliary classes to augment it to fulfill your class needs. The Novell schema documentation is available online for your reference.
|
|
|
auxiliary classes |
|
|
|
|
Auxiliary classes are newly implemented in eDirectory and are supported in LDAP. Novell recommends using auxiliary classes whenever possible, especially when adding attributes to base schema classes. An auxiliary class is a collection of attributes that does not require class inheritance. Auxiliary classes (or aux classes) are added to objects that are already created from existing classes, rather than adding the attributes directly to the class. If an attribute or multiple attributes need to be added to existing objects, but only on some objects of that class, rather than all objects of that class, then auxiliary classes are very useful.
|
|
|
hints |
|
|
|
|
When you add your schema extensions using a tool that reads from a file or through a small program, be sure you add the attributes first. Otherwise if you create your classes first, the add will fail because the attributes declared in the class definition aren't in the schema.
When you make revisions or additions to your product and you extend a class that you created to contain additional attributes, perform the addition of those attributes as a modify schema operation. DO NOT perform that operation as part of the original add that you did. Uf you are updating a tree that already has your schema extensions, the add will fail because the class already exists, but the definition you are giving it is not identical to what is already there, and then you will not get your new attributes added to the class. If you do your extensions as an add that is identical to your original add, and then a modify that adds your new attributes, the add will cover the cases that the product has not previously been installed, and then the new attributes will be added, too.
|
|
|
|
|
|
