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?

Regards,
Graham
--

[ Post a follow-up to this message ]

Hi Graham,

Ole Ersoy has worked on such a piece of code a while back. I think it
has matured in the Tuscany project.

Otherwise, you have to know that there is a Java schema containing all
the Objectclasses you need to describe a Java class, and to store a
serialized object. Not sure that it will fit your need.

In any case, as we are redesigning the JNDI API to be closer to what we
need, it will be a pleasure to include a Java<->Ldap OL-Mapping tool in
ADS project (OL = ObjectLdap, with Object-Relational-mapping in mind 

Graham Leggett wrote:
> 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?
>
> Regards,
> Graham
> --
>
>
>
>


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

[ Post a follow-up to this message ]

You may want to try using jdbc-ldap with your favorite orm.

Marc


On 12/17/07, Graham Leggett <minfrin-QRS0OI1c9YQ@public.gmane.org> wrote:
> 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?
>
> Regards,
> Graham
> --
>
>
>

[ Post a follow-up to this message ]

Hi Graham!

Graham Leggett wrote:
> 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.

JNDI itself offers a simple mapping from LDAP entries to Java objects
and vice versa with the help of so called state factories (Java -> LDAP)
and object factories (LDAP -> Java).

http://java.sun.com/products/jndi/t...tate/index.html
http://java.sun.com/products/jndi/t...tory/index.html

At least it helps you to abstract from the LDAP schema.

Spring LDAP is another option. It has comparable functionality, but you
get another dependency (JNDI is always present).

http://www.springframework.org/ldap

Both options do not provide transparent mapping like Hibernate does.
Greetings,
Stefan

[ Post a follow-up to this message ]

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 openthinclient.org 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.

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 openthinclient.org component. The component
currently lives at
https://openthinclient.svn.sourcefo.../comm
on
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.

Joerg Henne

[ Post a follow-up to this message ]

Hi Jörg !

long time, no see  At least, you are still prresent on the Directory
page : http://directory.apache.org/communi...s/the-team.html

<snip/>
>
> 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 openthinclient.org component. The component
> currently lives at
> https://openthinclient.svn.sourcefo.../co
mmon
> 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 would be great. There is only one little problem I can oversee :
the actual project is released under GPL V2 license, which is not
compatible with ASL 2.0. But I'm sure we can work this around.

It would be a pleasure to discuss more in detail about such a
contribution. I suggest we can start a new thread about it.

Thanks a lot !



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

[ Post a follow-up to this message ]

Emmanuel,

Emmanuel Lecharny schrieb:
>
> long time, no see 
yes, I am painfully aware of that. My involvement with our thin client
activities is a on-again off-again affair. Currently it is more
on-again, allowing me to re-visit lots of things which have been left in
a less-than-satisfying state since. :-/
> That would be great. There is only one little problem I can oversee :
> the actual project is released under GPL V2 license, which is not
> compatible with ASL 2.0. But I'm sure we can work this around.
>
The GPL choice is mainly influenced by the fact that a large part of
openthinclient.org depends on the Linux-based thin client OS.
Re-licensing any original openthinclient.org component (i.e. one for
which we actually own the copyright) that is useful outside
openthinclient.org is no problem at all.
> It would be a pleasure to discuss more in detail about such a
> contribution. I suggest we can start a new thread about it.
Ok, so be it. I've procrastinated for too long with giving the Apache DS
community an update, so I better use this kick to get me going :-)

Joerg Henne

[ Post a follow-up to this message ]

Hi Graham,

The LDAP DAS is sitting in Tuscany.  It would need an EMF based model though
, as it is designed to work with the EMF API / EMF SDO API.  The longer term
 plan is to have it work with the Tuscany SDO API as well + support Transact
ions, etc.  Also note that
the persistance to ADS is done by convention and the model's XML Schema Name
space is used to create the root DN within ADS.

In general the way it works is you would generate an EMF model (Basically mo
del Pojo's ehanced by the EMF API, similar to what modello does for maven) f
rom an source such as XML Schema, Annotated Java Interfaces, or XMI and then
 use the DAS to store the m
odel instance in ADS.  When doing CRUD stuff, the DAS loads a model from ADS
 and then uses SDO's change summary capability to handle updates.

I still need to do the Developer Use Case documentation (Or the How To), but
 the tests are pretty thorough so giving it a go should be easy.  If you nee
d Object to DN mapping though that's not by convention (XML Namespace) I thi
nk some of the other tools
mentioned would suit you better.  It's pretty easy to implement mapping with
 the SDO / EMF API using annotations, but I need more days :-).

Cheers,
- Ole



Emmanuel Lecharny wrote:
> Hi Graham,
>
> Ole Ersoy has worked on such a piece of code a while back. I think it
> has matured in the Tuscany project.
>
> Otherwise, you have to know that there is a Java schema containing all
> the Objectclasses you need to describe a Java class, and to store a
> serialized object. Not sure that it will fit your need.
>
> In any case, as we are redesigning the JNDI API to be closer to what we
> need, it will be a pleasure to include a Java<->Ldap OL-Mapping tool in
> ADS project (OL = ObjectLdap, with Object-Relational-mapping in mind 
>
> Graham Leggett wrote: 
>
>

[ Post a follow-up to this message ]

The RDBMS access model is completely different from the LDAP access model.
Trying to map JDBC to LDAP and vice versa may work superficially but should
only be used by those who need training wheels on LDAP.

Alex

On Dec 17, 2007 11:42 AM, Marc Boorshtein <mboorshtein-Re5JQEeQqe8AvxtiuMwx3
w@public.gmane.org> wrote:

> You may want to try using jdbc-ldap with your favorite orm.
>
> Marc
>
>
> On 12/17/07, Graham Leggett <minfrin-QRS0OI1c9YQ@public.gmane.org> wrote: 
> I 
>

[ Post a follow-up to this message ]

Hi Graham,

It's a please to hear from you again.

On Dec 17, 2007 11:17 AM, Graham Leggett <minfrin-QRS0OI1c9YQ@public.gmane.o
rg> wrote:

> 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?
>

I think Castor had something out there and even Hibernate tried.  There's
also this Spring LDAP stuff but that's not really an object mapping
framework but rather more of a utility library that removes most of the
redundant scaffolding used with JNDI code specifically.

There is a big void in this space and I have some ideas where we can fill
that gap.  I started experimenting with a few things in the sandbox here:

http://svn.apache.org/viewvc/direct...sulu/j2l/trunk/

The code experiments with a handful of simple ideas:

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.

The rest of the user's needs can be accomodated with hints to the mapping
engine using Java 5 Annotations.

So this little experiment played with these concepts to see just how
feasible this is and the amount of wattage we'd need to apply to get this
done in a reasonable amount of time.  I am by no means attached to the code
there.  I just tinkered so we can discard this and start fresh if you like.

Regards,
Alex

You annotate a your classes, and interfaces their members or methods with
tags


> 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?
>
> Regards,
> Graham
> --
>
>
>

[ Post a follow-up to this message ]