directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikola Ivancevic <>
Subject Re: Implementing another backstore (backend)
Date Sun, 30 Jan 2005 15:36:26 GMT
Your guess was right. I have to expose existing data via LDAP to number 
of servies (eg. FTP servers, MTAs, ...). All these services talk LDAP, 
but, in other hand, (existing) ISP accounting system has its own data 
model. In order to avoid data redudancy (having, for examle, user 
account information in two places (LDAP server and ISP's database), I 
need to implement an adapter for the existing data model.
For now, I think that I have to implement only non-modify LDAP operation 
(bind, lookup, search...), but it would be nice if there would be a 
complete, fully functional backend (or a collection of backend 

And if one could specify in server.propertis something like:
    server.db.partitions= test1 test2 test3
that would be great! :)


Alex Karasulu wrote:

> Nikola Ivancevic wrote:
>> Hi
>> I am working on an ISP-centric application. Currently, I am trying to 
>> find out the most suitable way to implement LDAP interface for the 
>> app.  Few days ago I 'discovered' the ApacheDS project and started to 
>> examine it. After reading docs and looking over the source, I think 
>> that ApacheDS might be an elegant solution for me. And I 
>> could not find any attempt of implementing a mechanism for another 
>> backstore 'plugin' (so far), I am thinking of the way how to do that. 
>> I'm willing to contribute to the ApacheDS, so it would be nice if I 
>> could implement that extension in the way that is most native to the 
>> rest of ApacheDS project.
> Wondering what your requirements are.  I would think the default 
> backend would suite most needs out of the box.  Mind describing your 
> situation a little more in detail?  Are you trying to get at some 
> nonstandard access model and expose it via LDAP? If so this might be a 
> good move for sure.
>> So, any hint out there?
> Well Nikola you can easilly write a backing store implementation and 
> snap it into the server having it attached to a context within the 
> namespace.  Take a look at the following interfaces here...these must 
> be implemented.  Then plugging in your backend and using it becomes cake.
> ContextPartition
> ----------------

>      or here in javadocs:

> The ContextPartition interface is what you want to implement and that 
> extends the BackingStore interface with links to follow.  It's a 
> simple backing store which adds a single method getSuffix() to figure 
> out where on the LDAP namespace this store (partition) is attached.  
> The DN returned by getSuffix() is the base where entries at and under 
> this DN are stored in this partition.  So if the suffix is 
> dc=apache,dc=org we would store this entry and its descendents within 
> that 'context' partition.  Here is the real meat to the interface but 
> this in itself is very simple and straight forward.  It's all about 
> doing CRUD ops on Attributes objects.  As many JNDI interfaces as 
> possible are utilized in specifying this contract so you don't have to 
> learn anything new if you already know JNDI.

>    or here in javadocs:

> One last note.  You need not worry about anything but storage.  All 
> other services are built on top of this using interceptors which 
> introduce aspects like authorization etc.
> If you are interested we'd love to try and build a prevayler based 
> backend.  Personally I have no time but I don't mind overseeing it and 
> helping out if you are interested.  This would really be cool for fast 
> in memory stores like the system backend rather than using a btree 
> based store with lots of cache.
> Cheers,
> Alex

Nikola Ivancevic - VTkom d.o.o.
Bulevar Mihajla Pupina 6, Novi Sad, Serbia & Montenegro
Tel: (+381 21) 47 222 40, 612 772; fax: (+381 21) 47 222 41
e-Mail: <>

View raw message