directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [GSoC] Project use cases
Date Sun, 16 Mar 2008 02:50:54 GMT

David Montag wrote:
> 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 
>  > 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.

Aha - Good luck in that case!  I'm certain you'll land it.

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

Yes - You have this right.  But let me elaborate with a concrete example on top, just so that
we cement it.  This will also answer your questions below.  Suppose for example you could
have an Ecore document that models an address (Address.ecore).  You might also have an XML
Schema that models an address (Address.xsd).  You might even have a RDB schema that models
an address (Address.sql).  All these models could be used to generate the corresponding java
code, which would be the java representation of the Address model.  So if we wanted to generate
java from all of these models we would be doing:

Address.ecore > java
Address.xsd > java
Address.sql > java

The java result might be something like and, where just
has two primitives, name(String) and number (int), and the has  reference to
Street (street), that is of type Street.  So if you create an Address instance manually like

Address address = new AddressFactory.eINSTANCE.createAddress();
Street street = new AddressFactory.eINSTANCE.createStreet();
Plain old java:
Address address = new AddressImpl();
Street street = new StreetImpl();

Note that the address instance is now a Graph.  It's a graph because address has a reference
to another object.  If we had left street off of address, then address would just be a single
object.  Now since the objects in this graph are instances of EObject we can serialize them
to XMI, or XML, or use the java serialization format, and serialize the the way any java object
instance would be serialized.

EMF lets you control the serialization format in various ways, but with the LDAP DAS the primitives
on the object are stored in the server using the corresponding ObjectClass definition (Which
if it does not already exist, would be created by the DAS).  So in this example, the
class would have a corresponding ObjectClass called Street defined in ADS.  The Street ObjectClass
would have the LDAP attributes name and number, so when the Street object is persisted to
ADS, the DAS would create an LDAP entry consisting the attributes names and values on the
object.  Street only has primitives, so the entry would have no references to other server
entries.  If the Address instance is persisted, then it would also have references to the
Street instance contained on the LDAP entry.  

Lets think about the same scenario for a SQL database instead.  In this case we might have
two tables.  An ADDRESS table and a STREET table.  The Address instance is persisted to the
columns of the ADDRESS table and the Street instance is persisted to the columns of the STREET

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

Well the XMI in this case would just be another representation of the data contained in the
object.  It's the object serialized.  But in our case we have to do a little more work, before
the object can be stored in ADS.  Before an EObject instance gets persisted it is converted
into an LDAP entry via the JNDI API.  This is basically a list of the attributes and corresponding
values that will be "hung" on a distinguised name within the server.

Note though that the XMI and XML in this case are basically just slightly different representations
of an EObject object instance, which is either the Street instance or the Address instance.

The part that's easy to mix up here is that Ecore is XMI.  However Ecore XMI describes EClass
instances.  So when EClass instances are serialized to XMI, you end up with a result that
can be used to generate java classes.  If you now create instances of these classes, you end
up with instance data that is also XMI, but it's just an object that's serialized, so that
it's state can be restored later.

Let me put it a little differently.  You could create EMF EClass instances, and use them to
model classes.  If you serialize these instances, one possible format would be an XML Schema
document.  Another would be SQL.  Another would be Ecore (XMI).  This is what's tricky about
thinking in terms of EMF, but it becomes very natural after a while.  I would give this article
a look, as it explains it with a lot more examples:
> Any EObject? 

An EObject is an instance of an EClass.  So instead of writing a class manually using your
favorite IDE, you could write an EClass definition inside your java class file.  You could
then create instances of it.  Another question is why did the Rational (IBM) guys define an
EObject.  The EMF API is like the general JAVA API, but it has features added.  So an EObject
is for EMF what an Object is for java.  So why does EMF need an Eobject?  Because it knows
how to serialize itself to XML, XMI, it supports the addition of EAnnotation instances, it
has the EClass metadata singleton reference attached to it, and so on.  Incidentally, EAnnotation
instances are what would be used when doing custom mapping of EObject instances to ObjectClasses.

> Could you perhaps 
> also give me some pointers to interesting places in the code to look?

I would study the tests.  I've been meaning finish a design guide that goes into a lot more
detail regarding the techniques that make each role within the machinery work.  I started
a guide which you can find here (It's an eclipse documentation plugin, also generated using

The general concept is to use recipes (Challenge, Solution, Discussion) to break apart each
little thing that the DAS has to do to function.  I personally think documenting and driving
the design like this makes a lot of sense, since it clarifies what the challenges and solutions
are, and these challenges should be as atomic and concrete as possible.  You could just drop
it into your eclipse plugins directory and it will show up in eclipse help.  I used this to
"guide" myself through the process of writing the DAS.  Although once I my groove on, I started
coding in the hot seat, so the guide needs updating.  I think the general headings will be
useful though.

The DAS is pretty small in terms of classes, so I think you'll get up to speed pretty quickly
once you have a chance to view the code.  The main thing is understanding the concepts illustrated
in this article:

Of coarse you also have to understand JNDI, but the DAS classes use it to do all the work,
so the DAS will probably be a good grounding for this.  I'm also sure that David's Triplesec
JACC stuff would help.
Good luck and let me know if you need elaboration on anything else,
- Ole

View raw message