On Mon, Dec 27, 2010 at 4:35 PM, Emmanuel Lecharny <[email protected]> wrote: > Hi, > > 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 > role. > - 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 : > > (AdministrativePoint) > o > | > +-- [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 if possible we should avoid using DN altogether in these data structures, as we already know updating these DNs is expensive > - 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 deleted) > - 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 > DirectoryService. > > 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 ! > > > > > > -- > > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
thanks for the detailed summary Emmanuel -- Kiran Ayyagari
