directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [GSoC] Project use cases
Date Sat, 15 Mar 2008 16:05:46 GMT

On Mar 15, 2008, at 7:23 AM, David Montag wrote:

> Hi,
>
> For those of you who don't know me, my name is David Montag, and  
> I'm a student studying in Linköping, Sweden. I'm hoping to do a  
> Google Summer of Code project with Apache Directory.
>
> So, I and Alex have been discussing a GSoC project. A brief initial  
> description can be found here: http://cwiki.apache.org/confluence/ 
> display/DIRxPMGT/Google+Summer+of+Code
>
> I will here present two use cases for the schema<->POJO/POJI  
> mapping. The mapping could be done using a maven plugin, for  
> example. This is how I picture the use cases. Please correct my  
> mistakes, and give me feedback.
>
> 1. Schema -> POJO
> An LDAP server has a Foo objectClass. It may have different kinds  
> of attributes. The user wants to access and manipulate Foo entries  
> natively in Java. The plugin reads the schema from the server, and  
> generates some files, Foo.java being one of them. The user then  
> codes against the Foo interface. I don't know how the actual  
> persisting of the objects will be done. I imagine some kind of  
> proxy objects for this. It can be decided later. I also don't know  
> how Foo objects will be created. Possibly through a factory.
>
> 2. POJO -> Schema
> A user has a Bar Java class. The user would like this class  
> persisted using LDAP. The user instructs the plugin to persist the  
> class by adding annotations to the code. The plugin then generates  
> an LDAP schema from the Java class. Using additional annotations,  
> the output schema format can be adapted. The generated schema can  
> then be pushed to the LDAP server. The user then possibly uses some  
> factory to create Bar objects that are persistent.
>
>
> Maybe I'm considering the persistence part too much? Please give me  
> comments.

I would work on an ldap back end for a jpa system.  IMO jpa has  
solved a lot of the problems about representing persistence options  
in a fairly reasonable way; I'm not sure if they are too biased  
towards relational backends to be completely appropriate for an ldap  
backend.  Someone has recently been talking about one for jpox.   
OpenJPA has a pluggable back end that could be replaced.

I would not concentrate first on schema generation/java source code  
generation but on getting the mapping to work reliably.  I think that  
in any actual use of such a system people will be (relatively) happy  
to write the POJOs and ldap schema as long as the runtime data  
operations are reliable and fast.  I also think that focussing on the  
simple cases where all the types of pojos are known at the start will  
be more productive than trying to model "you can stuff anything you  
want into this entry" cases.

In my experience mapping a single POJO with simple properties to an  
ldap entry is pretty easy.  The challenge is in mapping trees of  
POJOs.  The main challenge is that in contrast to the simplicity of a  
relational store where there is really only one way to represent  
relationships -- logically -- in ldap there are at least two:   
containment and reference.  This intrusion of access path decisions  
into data model design complicates the mapping code considerably.

Along with Ole's project that Emmanuel mentioned there is the jpox  
work that started recently.  Some time ago I worked a bit on a  
slightly jpa-like model for triplesec, where the person writing the  
code "enhances" the pojos by essentially coding in mappers for each  
field.
The tripelsec branch I worked on is at
https://svn.apache.org/repos/asf/directory/sandbox/djencks/triplesec- 
jacc2
and the specific code is in  admin-api2/src/main/java/org/apache/ 
directory/triplesec/admin/persistence/ with pretty much all use of it  
one directory up.

thanks
david jencks

>
>
> Thanks,
> David
>


Mime
View raw message