directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne <j.he...@levigo.de>
Subject Re: Object LDAP mapping
Date Mon, 17 Dec 2007 19:47:43 GMT
Alex,

Alex Karasulu schrieb:
> A default mapping scheme is used to map Classes to STRUCTURAL 
> objectClasses and Interfaces to AUXILIARY objectClasses.  You probably 
> can immediately infer on your own what abstract Java classes map to.  
> Java interface and class properties map to ldap attributes.   There is 
> some level of smart inference we can make for most general cases to 
> make sure the right things happen with regard to may and must lists.  
> Hence there is a default mapping scheme with some smart logic designed 
> to handle most common cases in terms mentioned above and on how to 
> handle syntaxes etc.   Also I think we can do some superb stuff with 
> other concepts in both LDAP and Java like ditStructureRules, nameForms 
> etc, and with things like Java aspects.  However we can talk about 
> this later. This should cover about 60-80% of the mapping needs.
Just a few quick notes on the rationale behind our approach. We started 
out from a few basic premises:
1. We want to be able to support multiple different LDAP schemas (or 
rather schema dialects) from the same domain model.
2. Differences between the dialects can not easily be factored out in a 
generic fashion, like a HibernateDialect, since they are not language 
dialects but structure dialects
3. We want to be able to map our domain model onto existing directories, 
without forcing them to install custom schemas or schema extensions. 
This premise is pain-inducing and, in retrospect, debatable. We talked 
to administrators of large MS-ADS installations any they were generally 
very reluctant or hostile towards schema extensions. So, in order to not 
artificially limit us by requiring one, we tried to do without - but 
failed: the schema for the RFC classes present in ActiveDirectory looks 
good upon cursory inspection, but is actually horribly broken. The 
nesting rules imposed by the schema makes it impossible to use quite a 
few classes in the way they were meant to be used. Therefore we require 
a minimal schema extension which relaxes those restrictions.

Premises #1 and #2 rule out Java 5 annotations, therefore we are using 
separate XML to describe the mapping. Mapping creation from annotations 
could be added though.

That being said, I must confess that compared to a solution where the 
inheritance hierarchies of the LDAP schema and the domain model are 
"synchronized" our approach lacks a lot of elegance.

Joerg Henne



Mime
View raw message