|
Hello,
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.
Sincerely, Alex Karasulu
|
