directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject AP's data structure
Date Mon, 27 Dec 2010 11:05:26 GMT

here is a description of the data structure used to handle the 
Administrative model in the AP branch.

We manipulate two kinds of objects that need to be stored in memory when 
the server is started :
- administrativePoints (APs)
- subentries (SEs)

The relation between those two elements are simple :
- an AP can have zero to many SEs
- a SE can cover one to many APs role, but only one AP entry
- APs and SEs both have roles : AccessControl (AC), CollectiveAttribute 
(CA), TriggeExecution (TE) and SubSchema (SS)
- roles are defined by some auxiliary ObjectClass in SEs, by an 
attribute (AdministrativeRole) in APs
- the relation between an AP and a SE exists only if they have the same 
- A SE *must* be declared under an AP, which means that we can't have an 
isolated AP, when the AP can be defined alone, but in this case, it's 
just a placeholder.

As an example, if we define an AP for 2 roles (AC and CA), and three 
subentries : SE1 for CA, and SE2 for AC and CA (the two subentries 
define two different areas with their respective subtreeSpecification), 
the SE1 is associated with the AP entry and with the CA role, and SE2 is 
associated with the same AP entry but covers 2 roles.
Here, an AP entry is associated with 2 SEs, and SEs can cover one to 
many roles.

To handle this, we need to define the following structures :
- AdministrativePoint will describe a AP role. It will be loaded when 
the server is started, and loaded into some caches : one cache per role. 
As we can't have 2 APs with the same role at one level in the DIT, we 
can safely store the cache in a DnNode<AdministrativePoint> structure. 
The AdministrativePoint itself is an interface, with some extented classes :

     +-- [AbstractAdministrativePoint] (A)
           +-- [AutonomousAdministrativePoint]
           +-- [AccessControlAdministrativePoint](A)
           |     ^
           |     |
           |     +-- AccessControlAAP
           |     |
           |     +-- AccessControlIAP
           |     |
           |     +-- AccessControlSAP
           +-- [CollectiveAttributeAdministrativePoint](A)
           |     ^
           |     |
           |     +-- CollectiveAttributeAAP
           |     |
           |     +-- CollectiveAttributeIAP
           |     |
           |     +-- CollectiveAttributeSAP
           +-- [TriggerExecutionAdministrativePoint](A)
           |     ^
           |     |
           |     +-- TriggerExecutionAAP
           |     |
           |     +-- TriggerExecutionIAP
           |     |
           |     +-- TriggerExecutionSAP
           +-- [SubSchemaAdministrativePoint](A)
                 +-- SubSchemaAAP
                 +-- SubSchemaSAP

As we can see, we have as many classes as we have roles, and covered 
area. (At this point, I'm not sure we need to define the AAP classes for 
each role).
The abstract class holds all the fields needed to manipulate the APs 
(except for the AAP) :
- DN dn : the AP position in the DIT
- String uuid : the AP EntryUUID
- seqNumber : the AP sequence number (one per role)
- AdministrativeRole role : the role (AC, CA, TE or SS)
- AdministrativePoint parent : the AP's parent. (used when the current 
AP is an IAP : we will have to update it's parent's seqNumber if it's 
- Map<String, AdministrativePoint> children : the AP sub-APs (used when 
there are some IAPs children)
- Set<Subentry> subentries : the set of subentries attached to this AP role

The Subentry class is simpler, as it holds only a few fields :
- SubtreeSpecification ss : defines the area on which the subentry acts
- Set<AdministrativeRole> administrativeRoles : The set of roles this 
subentry is handling
- String uuid : The subentry EntryUUID

We also use some caches for AdminsitrativePoint and Subentries. they are 
used as speedups for accessing those elements. Each kind of 
AdministrativePoint will have its own cache, which will be a 
DnNode<AdministrativePoint>, those caches are being handled by the 

The SubEntryCache is slightly different, as it's currently a fixed size 
cache, with a limited number of element stored into it. This is a bad 
implementation, and has to be replaced by a standard cache, using 
EhCache. It's supposed to be used to retrieve a subentry without havng 
to do a lookup into the backend, when modifying the APs or the 
subentries, but I don't think it's actually necessary. the rationnal is 
that when we modify an AP, removing a role, the associated subentry 
*must* have been deleted first, so a subentry cache is useless in this 
case. And when updating an entry, we refer to the AP, which already has 
a reference to the subentry, so we don't need a subentry cache. It will 
be removed.

That's pretty much it. The last thing is the SeqNumbers which are added 
to each AP entry, as we may have up o four different roles to manage, 
and there is no reason to update an entry when we change a subentry for 
a role the entry is not related with.

Hope it's clear enugh !


Emmanuel L├ęcharny

View raw message