...
| Section |
|---|
| Column |
|---|
| Purpose| Wiki Markup |
|---|
This document is a functional specification (at least that was what it was intended to be at it's onset) for a new schema subsystem design. The new design will enable dynamic yet persistent updates to schema elements within the server. Furthermore, entire collections of schema elements referred to as "*a schema*" will be \[un\]loadable on the fly. This new mechanism will also expose a new (always present) persistent partition attached to the namespace from the ou=schema naming context. It will contain a well structured entry based view of schema objects managed by the server with better search and administration capabilities. This is all in addition to the schemaSubentry demanded by the LDAP protocol with attribute based descriptions of all schema elements. |
Such a new schema subsystem will make it easier to use the server and manage the schema maintained within it. Furthermore it will greatly facilitate replication since schema elements will simply be entries within the server. |
| Column |
|---|
| Document TODO- Provide in-server execution flow diagrams for schema loading, schema discovery, schema information reading, etc.
- Consider warnings, information attached by Ersin and merge them into the document.
|
|
...
In the new design, two separate views will be provided for describing and interacting with schema information stored within the server. One view is virtual and uses a single entry, the schemaSubentrysubschemaSubentry (SSSE), as required by the protocol to describe schema elements within attribute values. The other view is non-virtual and not specified by the LDAP protocol.
...
What is called "schemaEntry" above is called as "subschemaSubentry" in the standard (RFC4512, 4.2). |
| Info |
|---|
| title | RFC4512, 4.2. Subschema Subentries |
|---|
|
| No Format |
|---|
Subschema (sub)entries are used for administering information about
the directory schema. A single subschema (sub)entry contains all
schema definitions (see Section 4.1) used by entries in a particular
part of the directory tree.
Servers that follow X.500(93) models SHOULD implement subschema using
the X.500 subschema mechanisms (as detailed in Section 12 of
[X.501]), so these are not ordinary object entries but subentries
(see Section 3.2). LDAP clients SHOULD NOT assume that servers
implement any of the other aspects of X.500 subschema.
Servers MAY allow subschema modification. Procedures for subschema
modification are discussed in Section 14.5 of [X.501].
A server that masters entries and permits clients to modify these
entries SHALL implement and provide access to these subschema
(sub)entries including providing a 'subschemaSubentry' attribute in
each modifiable entry. This is so clients may discover the
attributes and object classes that are permitted to be present. It
is strongly RECOMMENDED that all other servers implement this as
well.
The value of the 'subschemaSubentry' attribute is the name of the
subschema (sub)entry holding the subschema controlling the entry.
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The 'distinguishedNameMatch' matching rule and the DistinguishedName
(1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
Subschema is held in (sub)entries belonging to the subschema
auxiliary object class.
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
The 'ldapSyntaxes' operational attribute may also be present in
subschema entries.
Servers MAY provide additional attributes (described in other
documents) in subschema (sub)entries.
Servers SHOULD provide the attributes 'createTimestamp' and
'modifyTimestamp' in subschema (sub)entries, in order to allow
clients to maintain their caches of schema information.
The following subsections provide attribute type definitions for each
of schema definition attribute types.
|
|
...
A special partition will be designed using the existing BTreePartition implementation. This partition will be special in that it will hard code indices and the attributeTypes needed to operate them. This way this partition will not need schema information (essentially attributeType descriptions) to bootstrap itself. Hence it will rid us of a serious chicken and egg problem as a persistent store for schema information.an LDIFPartition implementation.
| Section |
|---|
| Section |
|---|
| Column |
|---|
This partition will contain entries describing individual schema elements and groups of these elements which we call schemas. The structure will be rather simple. Here's quick look at what it might look like to the right. New objectClasses for Schema EntitiesSpecial objectClasses will need to be defined for schema specific entities to be modeled as entries instead of as attribute values in the schemaSubentry. Some objectClasses which will need to be defined are: - attributeTypeDescriptionattributeType
- objectClassDescriptionobjectClass
- ditStructureRuleDescriptionditStructure
- ditContentRuleDescriptionditContent
- nameFormDescriptionnameForm
- syntaxDescriptionsyntax
- matchingRuleDescriptionmatchingRule
- matchingRuleUseDescriptionmatchingRule
- syntaxChecker
- normalizer
- comparator
These objectClasses will model all of the LDAP schema elements and more. There are 3 additional elements that are ApacheDS specific and are listed last above: syntaxCheckers, normalizers, and comparators. ApacheDS uses these low level constructs to build sytaxes and matchingRules that are used throughout the system. | Note |
|---|
The SyntaxChecker is an implementation of the SyntaxDescription object, which describe the syntax that an describes the syntax that an attributeValue must respect. The Comparators are also implementation of used by MatchingRules to compare values. Normalizers are a little bit different : they do a transformation of an attribute value accordingly to the rules which are given in various RFC for each AttributeType (for instance, names should not be case sensitive, multiple consecutive white spaces should be replaced by a single white space, etc ...). There is no formal description of normalizer with an associated OID. |
Normalizers are used by indices and other processes to generate canonical representations of attributeType values so they can be compared. Normalizers are used to normalize values in entries as well as in filter expressions. Comparators compare values and these constructs implement the java.util.Comparable interface. They are used to sort values to insert them into indices and to evaluate greater and less than expressions where attributeType values must be compared. SyntaxCheckers are used to contrain constrain values so the correct values are used by entries for attributeTypes of that syntax. |
| Column |
|---|
| 
| Note |
|---|
The ObjectClass should also contains the description and the Obsolete flag if set to true. |
|
|
...
All those AttributeTypes are defined in the MetaSchema page
Chicken and Egg Problem
There's a subtle chicken and egg problem that got us into a bind with all this bootstrap registry stuff that uses pre-compiled Java classes to generate schema objects. The default btree based implemenation for partitions needs access to schema information in order to build indices and operate properly to perform search operations.
We will avoid this problem by hard coding the few attributeType definitions we need into the schema partition. The partition will thus be able to fire up without the need for the schema subsystem to be present. This is good because this partition will be used to store the schema information needed to start up the schema subsystem. Hence the chicken and egg problem.
By hard coding the indices used we know all the attributeTypes needed and can create static classes representing these entities. Furthermore no interceptors will need to be started in order for this partition to start up and make it's information available. This means the schema subsystem will directly access this partition without the protection of various services like normalization. Hence it must explicitly normalize all distinguished names and filter arguments fed into partition interface calls. Other more significant services like managment of operational attributes will also not be provided at least during schema subsystem startup. We explain why and how problems will be avoided to work around this fact.
Schema Subsystem Startup
The schema subsystem should provide a simple schema element store interface to abstract the backing store and wrap access to this delicate partition which is not protected by various interceptors at least on startup. Let's call this interface ISchemaStore. This will perform simple lookups of schema entities from the backing store. The simpler the interface the better: meaning fewer methods to implement. For now it's used just to pull schema objects to load global registries.
The schema subsystem will begin initializing once it is handed the schema partition. Upon getting it the partition is used to load all entities in all schemas into global registries. Access to global registries are exposed via the schema subsystem facade. After this point the serve can start up in the usual sequence. At some point a schema interceptor is inserted into the interceptor chain managed by the server.
Schema Subsystem Startup
The schema subsystem startup is pretty simple. If we already have an existing schemaPartition, we will read all the schema entities stored in this partition, and initialize the Registries accordingly. At this point, the schema must be valid, otherwise the server won't start. If we don't have yet a schemaPartition on disk, then we extract from a Jar all the base schemaEntities, boot a LdifPartition instance, and load all the schema entities into the Registries.
The schema subsystem is now readyThis interceptor deals with translating this proprietary representation of schema information into a form accepted by the protocol and injecting it into the subentries of schema authoritative areas.
Using the X.500 Administrative Model
X.500 provides a powerful model for administering schema information within a DIT directly so different authoriative areas can exist with different schemas in effect. Doing so is simple. At the apex of an SAA (Schema Authoritative Area) a subentry is inserted. This subentry contains a simple subtree specification which is simply {} which means the whole area underneath the apex (which is called the administration point or AP).
...
These are the attributes that go into the schemaSubentrysubschemaSubentry. The problem with LDAP is that it never realized that there can be more than one schema subentry in the portion of the DIT served by a DSA. Every entry within a DSA contains a subschemaSubentry attribute pointing to the schema subentry containing schema information governing that entry. This includes the Root DSE.
...
