geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: [jndi] Have we found a JNDI impl yet?
Date Fri, 29 Aug 2003 07:55:39 GMT
All this sounds great, Alex, but I¹m a little concerned that its overkill
for the JNDI ENC.  The JNDI ENC is totally static at runtime (per
deployment) and therefore a very simple, and fast, in-memeory caching
strategy works best. Will your impl support this type of caching?  In
OpenEJB, the JNDI ENC impl caches lookups in a HashMap so that subsequent
lookups using the same JNDI name are wicked fast ­ fast as a Hashtable
lookup on a small data set.  I know that we can use the advanced features of
LDAPd in many areas of Geronimo (security, configuration, etc.) but for the
JNDI ENC, I think it would be best if we used something lighter.  Perhaps,
you can provide a caching impl for static data sets like this?  The thing
is, in most deployments, the number of items stored in the JNDI ENC for a
particular component is very small. Speed is of the essence ­ you can¹t get
much faster than a HashMap. ;-)

On 8/28/03 7:40 AM, in article
000001c36d72$472df780$, "Alex Karasulu"
<> wrote:

> The current architecture has a primitive server side LDAP JNDI provider
> which is about 70-80% functional.  The provider directly accesses entries
> within the backend apparatus within the server.  When contexts are
> initialized they represent an instance/point of access (hence a context)
> into the directory information tree of the server bypassing the LDAP
> protocol stack.
> In the new architecture, to be completed by mid October, the JNDI provider
> is at the core of the server's backend apparatus and shall be completed by
> then.  The server side JNDI LDAP provider will wrap something we call a
> nexus that attaches several databases each with a suffix in the namespace to
> a central point in the server.  The nexus performs name based routing to the
> backend that has jurisdiction over the region of the namespace specified by
> its suffix.  Anyway this apparatus is wrapped by JNDI.  The JNDI becomes the
> only way to enter the nexus and hence a target backend in the new
> architecture.  The JNDI is thus a shell around the backend subsystem of the
> server.  All orthogonal services implemented as Interceptors enable things
> like triggers, and change notification between calls made by the JNDI
> provider on the nexus.  This is how we introduce new services into JNDI
> calls on our provider.
> There are two ways I can immediately conceive of in which this code can be
> leveraged to enable a persistant java:comp/env namespace for Geronimo.  But
> first consider this.  There may be areas where Geronimo will need to access
> and search over persistent data without having to bring this information
> into memory - this requires the industrial power of database indexing.
> Geronimo's configuration is a perfect candidate for storage in the directory
> - it will most likely be hierarchical in nature and very fitting.  Another
> excellent possibility is the use of the embedded server as the foundation
> for a security subsystem.  With that in mind lets just look at the way in
> which we can just enable the java:comp/env namespace while using LDAPd code.
> First you can build over the LDAP namespace using it as a hierarchical
> relational database to manage environment data.  A java:comp/env namespace
> could be implemented using another JNDI provider to wrap the LDAP provider
> which has the super set of JNDI functionality (Context, DirContext, and
> LdapContext).  The wrapper provider would simply transform operations into
> the LDAP namespace according to the designed DIT structure and the schema
> used for java:comp/env objects.  The neat thing is you would have the power
> of search to find anything you needed very rapidly.  Much faster than a
> non-indexed solution - you're getting the power of a database at your
> disposal this way.  If you go this route then other aspects like
> configurations can also be stored in different areas of the directory
> information tree.  Also LDAP replication can be used to replicate your
> environment and configuration information for clustering in the future.  I
> would recommend this approach.  Although you don't expose all the LDAP
> functionality you can still leverage it under the hood of the java:comp/env
> provider to make it extremely fast.  I can help write this or add Geronimo
> developers to the LDAPd project to make it come to fruition.
> The other approach involves the generalization of the Backend interface to
> store any kind of entry that does not necessarily need to be an entry within
> the LDAP namespace: see the attached xref file for the Backend interface.
> This way the backend apparatus is a generalized entry storage subsystem that
> could be used for any kind of namespace - directory enabled or otherwise.
> Noel Bergman and I are in the process of discussing these details and anyone
> from the Geronimo team is welcome to join us.  Basically we reduce the JNDI
> methods into a minimal set of storage oriented operations very close in
> nature to the methods on Context and its subclasses.  This reduced
> instruction set if you could call it that is extremely simplified enabling
> storage for entries in any namespace.  The nexus multiplexes different
> backends for different namespaces almost federating them.
> If a generalized provider with a pluggable NameParser is written then the
> provider can theoretically be used for any namespace.  Think of the concept
> as miniature framework for JNDI to enable storage and retrieval without the
> pain of having to implement all those methods on the Context interface and
> its subclasses.
> These concepts are at the stage where new comers can join the conversation
> with a minimal learning curve to rapidly be able to participate.  We would
> welcome the collaboration to enable both projects to progress together.
> Good luck & BU,
> Alex Karasulu

View raw message