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
