Comments inline...

On 4/3/07, Ole Ersoy <> wrote:
Hey Luciano,

Excellent question, I'm somewhat new to
LDAP myself, but luckily the gang here is
amazingly helpful.  Emmanuel usually answers
before I've had time to press the send button
(I think he has ESPN or something....)
and then everyone else jumps in with lots of helpful
info right after.

Here Goes:
We're trying to minimize mapping

There are two ways to do this, which I think you
hinted at in your question.

One is to serialize the DataObject directly
to the LDAP repository (Storing a Java Object in the repository),
but then we loose out on the query capabilities that LDAP offers
us, because the whole object is just a binary blob, and we
would miss the opportunity to make use of the DataGraph's
change summary.

So, I'd think you still want to be able to perform search, right ?
Also, regarding DataGraphs (let's assume a collection of person objects from LDAP) and ChangeSummaries ( what has changed on this collection of person objects)... I'm not sure if you want to persist things on that level to the repository, otherwise you might start getting duplications (two dataGraphs with same person object) and invalid data (like change summaries where nothing really changed after the read operation), no ? Let's consider the following scenario : perform a LDAP query, to retrieve members of department X. This will give you a SDO dataGraph, then the application consuming this dataGraph manipulates and make data updates that will create changeSummary, then when you want to applyChanges back to repository, you see what has changed and only update those entries (an possible just the attributes changed on specific entries) ... Is this aligned with what you were thinking ?

Initially I was thinking the blob way would be good,
just to get going, but I would still break up the
DataGraph into one blob per DataObject.  It turned out
that doing in the LDAP way is much more attractive, and
will most likely perform better (Since we can use the DataGraph).

The LDAP Way:
The other way is to map the simple properties
of the DataObject to preexisting ObjectClasses.

Yes, I think this is more towards what I was thinking...

The keyword is "Preexisting".  If we are starting
with a brand new model that has never been written
to the repository, then we need to write the
ObjectClasses that correspond to the model's EClass (In Ecore)
or Type (In the SDO specification) to the repository.

LDAP has the equivalent of Ecore effectively for defining

The LDAP Syntax corresonds to the name member of DataType.
The LDAP AttributeType corresponds to a DataType.
The LDAP ObjectClass corresponds to an EClass or Type (SDO)

So the DAS first writes the metadata (Syntaxes, AttributeTypes, and
ObjectClasses ) to the repository, and then stores each
DataObject instances using this newly defined LDAP metadata.

If we want to map to existing ObjectClasses, then we need
a configuration file, just as with the RDB DAS.

Does that help?

- Ole

P.S. By pure LDAP API, I think you mean JNDI, and yes
JNDI can now be used to query the DataObjects stored
in the LDAP repository, just like
it's used to query the types of
information that is usually
stored in the LDAP repository.

:) I think so...

Luciano Resende