directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Naming and Eve provider pros and cons (was (Re: Embedding Eve Was: To release or not to release?))
Date Fri, 26 Nov 2004 16:27:14 GMT
Brett Porter wrote:

> Phil Steitz wrote:
>> From the various recent posts, it seems we have two basic use cases 
>> here and possibly two solutions for one of them -- maybe not a bad 
>> thing, but something to think about.
>> 1) Centralized access to configuration information and object 
>> references for physically distributed systems
>> 2) Bootstrapping and providing local, in-memory access to 
>> configuration / object references based on information in local flat 
>> files.
>> In Java, we want to use the JNDI client API in both cases. 1) is a 
>> classic application for Directory Services and certainly part of the 
>> motivation for Eve.  For 2) either embedded Eve or [naming] will 
>> work. I am interested in understanding the pros and cons of these two 
>> approaches.  We may want to merge them in some way (i.e., modify 
>> [naming] to just front embedded Eve). Does this make sense?
Let's look at the pro's and con's this will be a good exercise:

I think naming and Eve offer two alternatives for different limits 
within the problem space.  Each definately has some advantage over the 
other depending on where we are in the spectrum.  An with that said they 
compliment each other nicely.

** Secondary verses Primary Storage **

First off Eve is a disk based solution with caching whereas from my 
understanding Naming is in memory.  Now as memory is getting cheaper and 
cheaper (bigger and bigger) this point is becoming moot.  However today 
Eve's JDBM based database is better for storing large datasets.  We 
could also build different database for Eve too like ones in memory to 
make this point even more moot. 

** Search Performance **

There will be a point where Eve's JDBM database will overtake Naming 
when it comes to lookup or search performance.  This probably will 
happen when the data set is very large on the order of 100K to 1M 
items.  Basically Eve's JDBM database uses B+Trees to index into 
serialized objects in a master table.  This lookup takes relatively 
constant time with a balanced tree.  Naming from my understanding would 
use in memory structures to find objects like HashMaps.  Also I don't 
know if Naming supports search to find objects within an entire 
subtree.   If Naming supported search using in memory BTree's as indices 
then there would be no advantage to using Eve when it comes to search 

** Replicated - Distributed - Language Independent LDAP Store **

If you're looking to replicate your data, access and manage it via LDAP 
than Eve is for you.  Plus this is a language independent mechanism.  
Naming would no be language independent as it is tied to JNDI and Java 
obviously.  Plus the access name syntaxes are totally different.  One 
uses LDAP relative and distinguished names whereas the namespace of the 
other is specific to java:enc which uses a file path like notation for 
addressing objects in the namespace.   This is usually more intuitive to 
those dealing with simple applications where the applications know 
exactly where their stuff is in the tree and search is not needed.

** Schema based Constraints **

Naming does not have any schema driven constraints outside of the Java 
language.  LDAP uses schema much like a relational database schema to 
constrain the entities stored within the directory.  Although objects 
can be serialized into an LDAP directory this is not the primary means 
to store objects.  Usually u want to parameterize the object into atomic 
fields which can be made searchable instead of storing blobs of 
serialized objects.  This makes for faster searches which are not tied 
to Java - other apps can use the same data in languages besides Java.


Really Eve is a heavy weight store when compared with Naming and has 
search capabilities using LDAP filters.  It is for  language independent 
environments where the same data may be accessed by  non-Java clients 
via LDAP.  It allows data to be managed and constrained using external 
tools.  It is more of an enterprise scale solution where as Naming may 
not be.

It's namespace syntax is much more complex than Naming which makes the 
use of Naming for rapidly building apps much more attractive.  If you're 
just starting out, and don't know what your object domain is.  Or you're 
building a new application that is only going to be based on Java.  
Further more you don't know what interactions are going to be required 
with the environment and other applications the don't bother using Eve 
for configuration.  Naming is a much better tool for rapidly building 
applications without worrying about LDAP and schema and how to represent 
your Java objects.  Just use Naming to just store your objects for your 
configuration and be done with it.

In general I'd recommend using Naming over Eve except when you're 
problem space is very well understood and you need to have your 
configuration information managed and constrained within an enterprise.  
When you jump to this level then Eve is perfect for you.  Plus you can 
switch between hitting a remote LDAP directory and embedding Eve without 
code changes so that's a big win.  I think this last recommendation goes 
in line with the one I have for those folks who buid database driven 
apps: don't worry about a database or a schema just focus on getting the 
object model right and use an in memory data store that does not require 
thinking about relational anything for now.  Use an object database if 
you have to.  This line of thinking goes with LDAP as well and hence is 
a big factor in recommending the use of the Naming provider over the Eve 
provider.  These providers for configuration complenent  each other at 
different ends of the spectrum.

> I'm not yet familiar enough with Eve to say, but it would have to be 
> able to perform all the functionality of naming without requiring an 
> onerous amount of additional configuration or dependencies to make 
> sense. I'm not sure this would be the case. What probably makes more 
> sense to have Eve use naming if that makes any sense, and keep naming 
> as a small library for the purposes of (2).
> However, being able to embed Eve offers richer functionality to an 
> application that might be useful even for doing (2).
>> FWIW, I would not want to see Tomcat or Geronimo completely abandon 
>> 2) -- i.e., become wholly dependent on centralized "administrative 
>> repositories". There are some practical advantages to having basic 
>> configuration information available locally.
Well again this comes with a move from being a standalone app server to 
one that snaps in to an enterprise to enable configuration via 
centralized interfaces.  Imagine making changes to several instances of 
Geronimo in a cluster.  This is the sort of thing that Eve will provide 
value for. 

> I agree - one reason to use JNDI for the client is to be able to 
> switch between or combine two depending on the deployment environment.
Well the switch in theory is nice but not possible between Eve and 
Naming due to lack of namespace alignment.  Eve is an LDAP namespace 
provider while Naming is for java:enc.  So you cannot interchange 
between the two without considerable code changes.  However going form 
Naming to another java:enc provider should not be an issue.  Likewise 
switching between the Eve provider and the SUN JNDI LDAP provider should 
not require code changes.


View raw message