[LDAPGTF] QQ news suite à Apache Con 2009

[Emmanuel Lecharny]

Jonathan Clarke wrote:
> On 11/11/2009 10:31, Francois Armand wrote:
>> Emmanuel Lecharny a écrit :
>>> Salut à tous,
>> [...]
>>>
>>> LDAP n'est clairement pas 'sexy' ;)
>>>
>>
>> Plus j'y pense, et plus je me dis qu'on pourrait vraiment profiter de la
>> mouvence "no sql" pour faire de la pub à LDAP.
>>
>> Alors, je ne sais pas exactement comment faire notre pub, car comme tu
>> m'as dis dans un autre mail, même si LDAP n'est pas basé sur SQL, on est
>> quand même dans un mode "schéma".
>>
>> Mais je pense qu'on peut quand même avancer d'autre arguments : maturité
>> des implémentations, gors avantage au niveau de l'aspect protocol (par
>> ce que bon, allez changer de system "no sql"... le cout de migration est
>> énorme).
>>
>> Bref, je sais pas trop comment, mais je pense qu'il y a une carte à
>> jouer pour le côté "sexy" de LDAP. Peut LDAP comme couche d'accès
>> unificatrice en dessus de ces stores ?
>
> Cette remarque au sujet de la mouvance "no sql" m'a fait réflechir.
>
> Il existe des API qui proposent une abstraction du backend de stockage 
> - on décrit un modèle de données, puis on utilise les primitives de 
> l'API pour l'interroger, le modifier, etc. Un exemple simple est Siena 
> (http://www.sienaproject.com/), qui a 3 backends : JDBC, Google App 
> Engine et Amazon DB <truc>.
>
> Un backend LDAP dans un projet de ce type, ca n'a pas l'air très 
> compliqué à faire, vu l'interface en question, hormis la question du 
> schema de stockage (généré à la volée ?). L'usage que j'en vois serait 
> évidemment comme base de stockage pour appli qui lit beaucoup mais 
> écrit peu...
>
> Est-ce que ce genre d'idées va dans le sens que tu pensais ?
Je ne lis pas dans les pensées de François, mais voici mon avis sur le 
sujet :

LDAP impose l'utilisation d'un schéma assez rigide. Il y a deux 
possibilités pour avancer dans la voie d'un OLM (Object Ldap Mapping, TM 
- au cas où une boîte stupide poserait un patent encore plus stupide sur 
ce terme...).

1) On stocke les objets dans un attribut, brutalement après 
sérialization, avec une clé permettant de retrouver l'object (clé qui 
serait dans le RDN)
2) On créé un ObjectClass décrivant l'objet, et on créé une entry par 
instance à stocker, avec une clé sélectionnée pour le DN (l'UUID, par 
exemple ?)

La première approche est franchement chevaline, mais pour une approche 
HTable, ça peut suffire (à condition de bien choisir sa clé)

La second approche nécessite d'effectuer un mapping plus pointu, et pose 
le problème des références sur d'autres objets, qui va se traduire en 
général par N lectures dans la base...

Ce n'est pas évident... La seconde approche est clairement simple à 
mettre en oeuvre si on travaille avec des objets 'plats' (sans 
références sur d'autres objets).

Petite précision : si on injecte un schéma à la volée (ce qui n'est pas 
forcément impossible, voir avec son vendeur préféré ;), il ffaut aussi 
être capable de générer un index à la volée, sinon, l'approche 2 est 
inutile... (sauf à définit ces index avant le lancement de la base).

Mes 2 kopecks

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org