On 12/27/10 1:49 PM, Kiran Ayyagari wrote:
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
Yeah, it might be possible to get rid of DN in the AP class. We never
access the AP directly, we use the DN for that, so we already have the
DN, no need to store it.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
