geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject [JNDI] Perhaps we can join forces
Date Sun, 24 Aug 2003 07:09:43 GMT


I'm the founder and a member of the LDAPd Group which strives to build a
pure open source embeddable java LDAPv3 server.  Our goal is to build an
LDAP server with all the rich features present within modern relational
databases; i.e. stored procedures and triggers.  We are far from our goals
but hope to get there soon.  Most importantly however the server has a very
unique relationship with the JNDI which was designed from the beginning to
benefit servers like Geronimo in several ways:


The backend subsystem of LDAPd is wrapped by a server side LDAP JNDI
provider.  The provider directly operates on backends and their entries
without going through the protocol stack.  In a way, the provider is a shell
translating JNDI calls into simple database operations.  Even LDAP requests
delivered over the wire to the server's front end are satisfied using the
JNDI provider.  All handling aspects outside of the front end protocol occur
after threads penetrate the backend subsystem using the JNDI.  So things
like authentication, triggers and stored procedures (when we're done with
them) will operate even without the front-end attached.


Now the JNDI serves a dual purpose:  First it will be leveraged as the
integration API for host servers that want to embed LDAPd.  If LDAPd is
provided as a single jar file, LDAPd would initialize on the first initial
context requested of the server side JNDI provider.  Fittingly, the JNDI is
to be used as the data access API by Java stored procedures and trigger
bodies to access and operate on LDAP entries.  This way the code written
within triggers and stored procedures can remain portable and location
transparent.  Stored procedures can be written outside of the server using
the SUN JNDI LDAP provider to operate on LDAP entries outside of the server.
Once deployed into the server, the stored procedures can operate using the
server side JNDI LDAP provider with a mere change to the JNDI environment
properties used.  No code changes would be necessary.


I originally founded the LDAPd Group when BEA Weblogic Server 7.0 released,
touting an integrated LDAP server.  I view directories in general not just
LDAP directories as cornerstone technologies in distributed computing
environments.  Let's face it, the number of components, web services, and
distributed systems (not to mention the people and network nodes out there)
are growing geometrically.  Management technologies will be the critical
factors in orchestrating these distributed systems.  Directories hold the
key to the future of any distributed component technology, .Net, J2EE or
other.  BEA has recognized this hence the integration.  It was a bold
maneuver but one that will pay off over several generations of their newly
redesigned server architecture.


BEA intends to use the LDAP server to enable several aspects within Weblogic
Server.  The simplest fashion in which they have been leveraging the server
to date is as a configuration and credential store for standalone servers
and servers within a cluster.  Fast location transparent data access,
natural hierarchical container component relationships in app servers and
master slave replication make LDAP directories an excellent backing store
for clustered app server configurations.  The server is also being used to
store security subsystem information just for the needs of the server and
its administrators.  The last time I checked there were no indices or
B+Trees being used to conduct searches, so the server is very primitive and
would scale very poorly.  BEA does not recommend its use as a general
credential store outside of users accessing its console.  LDAPd however does
not have such limitations.  She was built to overcome these so open source
app servers can overcome BEA Weblogic Server.  LDAPd has the ability to
store millions of records per partition without noticeable read or even
write performance degradation.


This email can continue on for a long time and it's very late ;-) so I'll
get to the point.  The union between JNDI, LDAP and the Application Server
is here today.  However, I feel - no I know, open source can do it better
and I would like to prove that.  To do so I ask the members of the Geronimo
team to consider their involvement with influencing the progression of LDAPd
early.  I would love to have the input and help of those on this team to
maximize the benefits of the JNDI/LDAP/J2EE union at these early stages.
Upon request by some Geronimo members, the LDAPd Group has just released a
bug fix version 0.71 - still not very useful for embeddable configurations.
In the next few months, we intend to work towards revamping the backend
architecture to allow for all these features and to enable elegant
integration interfaces.  Now is a great time to consolidate some of our
efforts.  As I said in the release notes that were posted to the Jakarta
site we're working on entering The Incubator.  However I would like to keep
the code progressing regardless of how long the process takes and so any
support, feed back, or involvement from the members of the Geronimo team
would be very welcome until then, and there after.



Alex Karasulu


View raw message