directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Montag" <davmo...@student.liu.se>
Subject Re: [GSoC] Project use cases
Date Sun, 16 Mar 2008 00:58:22 GMT
Hi,

Wow, a lot of useful and interesting responses, thanks! I want to start by
clarifying that I'm not on your skill level (yet) when it comes to these
different technologies. But please bear with me, I'm learning new stuff
every day :)  Sometimes I might spell things out that are obvious to you,
but it's just to clarify things for myself. As always, please correct my
mistakes, but also tell me when I get things right.


Emmanuel:
> What you want is to be able to
> automatically persist objects into a ladp server, as if you don't know
> that is a LDAP server. As you can get the schema programatically,
> nothing forbid you to generate a new Schema for your object, stores it
> into the server, and then serialize the data. You don't even have to
> generate a Java class for that ! The perfect O/L mapping tool :) (O/L =
> Object/Ldap (tm) :)
So you would do something like, PersistenceFacility.store( myObject,
persistenceConfiguration ), pseudo-code'ish?

> You will have to consider some other cases :
> - ObjectClass can inherit from other ObjectClasses. Generating some POJO
> from an ObjectClass implies that you deal with these inherited OC.
Good point. I think this is related to point 3 in the wiki.

> - An entry can have more than one ObjectClass, and this is what we store
> into the server.
Sorry, but I'm not sure I understand what you're getting at. Do you mean
that the ObjectClasses could be used to model inheritance/interfaces? Or are
you getting at the problem of mapping multiple ObjectClasses to a POJO?

> - There is a special OC, extensibleObject, which allows an entry to
> accept *all* the AttributeType.
I'm assuming the problem is that the Java class can't accommodate for every
possible attribute. If so, then this is an interesting problem. I'll think
about it.

> JNDI provide two ways to store java instances into a LDAP server :
>  - as a serialized java class (heavy)
>  - as a special serialized form, a little bit like when you write a
> specific serializer instead of depending on the Object serialization.
>
> The thing is that it's heavy in both cases, as you store the object into
> one single attribute, forbidding the user to request the inner objects
> fields.
>
> A new storage (persistence) form is a major plus in this case : you save
> not only the object as a whole, but each field as attributes. If you can
> set the index on those attributes, you will be able to target ultimate
> perfomances. So, no, I don't think you focus too much on the persistence
> part. This is exactly what we need !
If I understand you correctly, we would benefit from a more "specialized"
way of serializing objects. A way that preserves the semantics of the
object, if you will. Knowing the semantics of the class would make the
serializing work easier. Am I on the right track here? Also, JNDI wouldn't
handle the case of schema->POJO, right?


David:
> 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.
The JPA approach could be interesting for the persistence part. It uses
annotations to mark up the necessary information about the class, right? It
might be desirable to have the schema generation still though. And the JPA
approach would only be part of the solution for a schema->POJO setup.

> 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.
I agree that it would be nice to see a working prototype that handled the
most common cases to begin with. The special cases - such as
extensibleObject type entities, if I understood them right - can be taken
care of later. I do think that the design should be extensible enough to
accommodate for them later on though.

> 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.
By mapping trees of POJOs, you mean that there are two approaches; either by
letting the "internal" POJO tree objects map to container entities, or by
mapping all the objects to entities on the same level, and using references
between the entities to model the tree? (I'm just repeating what you said.
Please just confirm if I understood it right.) If so, then this is a very
good point that should be considered.

> 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<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.
Okay, thanks. Not sure what to do of this right now, but I'll check it out.


Ole:
> Congratulations on the summer gig.  Just a few comments
> on top of Emmanuel's comments.  I also agree with David's
> comments that working with Graphs is "The" challenge,
> although it's easy to understand that someone might want
> something very light weight that they can use to quickly
> persist an object to ADS.  This would be a sub-use case
> of working with Graph's, so it's a good place to start experimenting.
I haven't actually got the gig yet :)  I'm going to apply next week, and
then we'll see what happens. Hopefully I get it :)  Ditto on the graph stuff
though.

I was not familiar with EMF, but after reading that introduction - which by
the way was really good - I think I got the basic concepts. By using Ecore,
one can create classes and objects, and persist them to - among some formats
- XMI, and vice versa. So what your DAS implementation does is persist the
objects to an ADS server instead of XMI, or am I getting it wrong? Is it the
XMI that's getting persisted to ADS?

It's an implementation detail, but could you give an example of what "graph"
could refer to in your examples? Any EObject? Could you perhaps also give me
some pointers to interesting places in the code to look?


Again, thanks for the excellent feedback and ideas. Looking forward to
reading your replies.

David

Mime
View raw message