geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [jndi] Have we found a JNDI impl yet?
Date Thu, 28 Aug 2003 14:40:03 GMT
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

Mime
View raw message