directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Object LDAP mapping
Date Mon, 17 Dec 2007 19:31:41 GMT
On Dec 17, 2007 12:13 PM, Jörg Henne <> wrote:

> Graham,
> Graham Leggett schrieb:
> > Hi all,
> >
> > Although not directly related to the directory server itself, I thought
> I
> > would ask here as the concentration of LDAP experts is high :)
> >
> > Has anybody heard of a Java package that does object to LDAP mapping,
> > along the lines of Hibernate or Torque in the land of SQL?
> >
> > In other words, I would like a Java class hierarchy of objects
> > representing LDAP objectlasses and LDAP objects.
> >
> > If such a thing doesn't exist, would the directory project be keen to
> > adopt such a new piece of code as its home, if it were to be written?
> >
> the project contains an LDAP mapping component which
> uses a persistence model similar to Hibernate with an XML based mapping
> specification similar to Castor's. Although it is currently part of the
> aforementioned project, if has always been designed with a stand-alone
> operation in mind.
> What the LDAP mapper currently can do:
> - map "entities" (essentialy POJOs) to LDAP objects
> - handle CRUD operations
> - handle one-to-many (multi-valued attributes referencing objects as in
> groupOfNames) relationships
> - handle many-to-one relationships (single-valued attributes referencing
> objects)
> - handle bi-directional associations (currently with two active
> association ends leading to somewhat brittle behaviour - to be replaced
> with JPA/Hibernate style association management where only one end with
> be "responsible")
> - handle parent-child relationships (nesting of objects within the tree)
> - handle some degree of transitive persistence (save/update a graph of
> objects in one go)
> - offer reasonable performance through lazy-loading and caching
> - support different mappings for one Java-class allowing one domain
> model to be used on different DIT "dialects", e.g. RFC-based directories
> and MS-ADS-based directories.

I could have used that several times in the past 3 years.  Let's talk about
it more and glad to hear below with your responses to Emmanuel that the
license issue can be rectified.

Now that we have some attention on this topic let's crank something out that
people can use.  Whether you guys have something already working or you want
to start fresh no matter to me.  The sooner we can avoid writing needless
handwoven code for LDAP persistence the better.

> What it currently can't do:
> - support for transactions though compensating actions has been designed
> into the system, but hasn't been properly implemented. Implementing it,
> would be rather simple, though.
> - the mapping model works for us, but might be too limited in some cases.
> - handle attribute types beyond simple strings
> - be properly documented :-)
> There is one other product in this area I am aware of: spring LDAP. I
> had a quick look at spring LDAP, and it appeared to me to have a rather
> limited scope of merely eliminating LDAP chores more along the lines of
> a templating rather than a mapping. However, it supports transactions.
> I have toyed with the idea of donating this component to the Apache
> Directory Project, but have so far kept quiet, since the level of
> maturity wasn't where I would have deemed it fit for general
> consumption. This however, has changed in the last few weeks. So, if you
> consider rolling your own mapping solution, I think you would be a lot
> better off with the component. The component
> currently lives at
> in the org.openthinclient.ldap package. Also contained are some
> test-cases illustrating basic usage. The GENERIC_RFC.xml mapping file
> could serve you as a rough guide to mapping your own objects.
> Just as a quick note to the broader Apache DS community:
> For the lack of a proper writeup of what I/we've been up to I'll give
> you a quick update. A few years ago, levigo developed a Linux based thin
> client management solution which has been deployed at quite a few
> customers, driving some thousands of thin client systems. Through the
> years it has always been a solution catering more to specialized cases,
> than to a real mass-market.
> About two years ago we started to replace the existing solution with a
> complete overhaul. This new solution was based on the idea of serving
> everything thin clients need from a single server with a simple
> deployment, to replace the old one requiring separate native TFTP, NFS,
> and DHCP servers. Second system syndrome along with limited resources
> has dragged out development of this system much longer than we
> anticipated, but in the past months the system reached a state where we
> can successfully pilot it in various settings.
> Since levigo's business model with respect to thin clients does not
> hinge on the sale of licenses, we open-sourced this solution in
> September. The project pulls together several technologies in order to
> achieve the goal of a single-server thin client solution: Java-based
> servers for NFS, TFTP, and PXE (a DHCP derivate for network boot
> applications) as well as Apache DS for the storage of all configuration
> information. At least two components of the system might be of interest
> for integration into Apache DS:
> - the PXE proxy has a lot of code which could be forged into a full DHCP
> server - I've always wanted to do this, but haven't found enough time yet.
> - the LDAP mapping mentioned above.

That's pretty cool.  I'll take a closer look at it.  It would be cool if we
can get our DHCP module up to speed too.  Also I talked to an acquaintance
who would has already implemented SLP and would like to do it here as a
module in ApacheDS in MINA.  Don't know for sure but this might add some
value.  Regardless it's good to hear from you again.


View raw message