This one time, at band camp, Richard Monson-Haefel said:
RM>It would be interesting to find out how fast LDAPd's embedded lookup facility RM>is. If its fast, it would make sense to eventually use it for the JNDI RM>Environment Naming Context. However, I still feel that having something quick RM>and lightweight now - a stopgap if you will - is better than waiting for LDAPd RM>to reach its first release.
LDAP is designed to be extremely fast when performing lookups and IMHO would be a fine choice as one of the implementations. I've worked with LDAP in the past and been very impressed by it's performance on digging through even a very sizable directory. However, the flip side of the coin is that inserts are not nearly as fast as lookups. But inserts into any type of persistence repository (LDAP, SQL, file, etc.) is always slower due to the fact that they're I/O bound.
If I understood Alex's post above, the embedded version bypasses the wire protocol, making it faster still and eliminating the resource mgt issues with connection pools, sockets, file descriptors, etc. If it also supports LDAP replication across embeddings, that will solve another basic problem (see below).
RM>That said, embedding a LDAP server into Geronimo would provide a solution for a RM>variety of problems, least of which is the JNDI ENC. It would be the nexus of an RM>authentication/authorization system and security domain administration. In RM>addition, it can be used for configuration and would make an excellent service RM>in its own right -- especially if its accessible intraVM as well as interVM. It RM>could also be used as the CORBA Naming service, support for which is required by RM>the EJB specification.
Very true. A JNDI lookup abstracts the backing mechanism. This is very powerful because it gives us the ability to implement an innumerable amount of solutions on the backend, all of which use JNDI as the lookup API. This would really satisfy many different requirements for many different industries, too, because not everyone can deal with LDAP.
RM>Personally, I hope that LDAPd is accepted into the Incubator so that we can plan RM>on incorporating into the Geronimo project (provided it works and survives the RM>incubator process).
+1 ;-)
RM>Whether or not we end up using LDAPd, Geronimo should be designed so that LDAP RM>servers of any make are plugable at some level. This would enable organizations RM>to leverage existing LDAP installations. If LDAP is plugable (is that a word?) RM>it should be a simple to configure and deploy -- avoiding overly complex RM>bindings is important, IMO.
The LDAP protocol is certainly standardized, but to my knowledge the embedded API described above is not. So "any" LDAP server will work if either the LDAP JNDI provider or the LDAP wire protocol is used, but to get the benefit of the embedded solution we would need to use LDAPd (unless I am missing something).
RM> RM>In the LDAP area I suggest we adopt a dual strategy of supporting arbitrary LDAP RM>installations via remote communications (LDAP protocol) as well as an embedded RM>solution (i.e. embedded LDAPd). If we are serious about LDAPd, perhaps those RM>folks could help with both strategies.
This was the next thing I was going to say in addition to my statements
above. Support of more than just an embedded LDAP soltuion is crucial
and that's what the JNDI abstraction will buy us.
+1 JNDI abstraction will also allow the three really different basic JNDI requirements mentioned above -- config, ENC, identities -- to be backed by different stores/lookup technologies. I would expect that in-memory solutions (which the embedded LDAPd would essentially be, since the db would be fully cached) would usually be best for the first two, while the third would generally require access to a remote repository. The abstraction layer should allow different strategies to be plugged in for each of these applications.
RM>The one thing I'm not sure about i the Avalon coupling. If LDAPd is based on RM>Avalon would it still work as an imbedable service if Geronimo doesn't adopt RM>Avalon? It seems likely, but I think its worth asking anyway.
Good question. If Avalon will work as yet another service within Geronimo,
then I imagine that LDAPd would simply depend upon the Avalon service.
RM>Alex Karasulu wrote: RM> RM>> BTW, the LDAPd team is currently working on submitting their incubator RM>> request as well. LDAPd is based on Avalon and is an LDAPv3 server with a RM>> SEDA based architecture. It is based almost entirely on Apache software. RM>> RM>> We started the LDAPd (embeddable) server project to eventually enable open RM>> source J2EE servers like JBoss, and Servlet Containers like Tomcat with an RM>> embedded LDAP server for configuration management. The project was RM>> triggered by the introduction of an LDAPv2 server into Weblogic Server by RM>> BEA. We wanted JBoss and Tomcat to be able to compete with BEA in this RM>> aspect - especially since BEA WLS uses LDAP to easily manage cluster RM>> configurations amongst other things. RM>> RM>> The role of a directory is critical to any distributed component model and RM>> goes beyond the aspect of configuration management. Take web services for RM>> example: the UDDI folks are working with the IETF to establish a schema RM>> model in LDAP for UDDI, here's the draft submission RM>> http://www.globecom.net/ietf/draft/draft-bergeson-uddi-ldap-schema-01.html. RM>> Likewise .NET is leveraging AD and ADAM to do the same for both web services RM>> and COM objects. When systems are composed of hundreds or thousands of RM>> distributed components (J2EE or .NET), these components need to find one RM>> another. We at the LDAPd Group feel that LDAP is a critical technology in RM>> enabling these distributed component architectures, which allows them to be RM>> orchestrated regardless of distribution. Our existence is based on this RM>> premise. We have come along way and are about to provide these functional RM>> services in a standard fashion while leveraging JNDI. RM>> RM>> LDAPd is based on Avalon and has a very unique relationship with the JNDI. RM>> Its front end which serves requests over the line protocol simply uses the RM>> server-side JNDI provider to access LDAP entries as Attributes. The server RM>> side provider wraps the backend apparatus which attaches naming system RM>> partitions to one common tree from multiple databases, or backends as we RM>> call them. Embedding LDAPd with the front end or just its backend apparatus RM>> will be as easy as using JNDI to get a context through the server side JNDI RM>> provider. This way under an embedded configuration, the protocol is RM>> bypassed and embedding servers simply access the backend apparatus directly RM>> via JNDI. We have centered around this design specifically to enable RM>> applications that already use JNDI LDAP to continue to do so but now under RM>> an embedded configuration. The change should only be a property setting for RM>> the Context.INITIAL_CONTEXT_FACTORY property.
Is there support for replication across embeddings? This would be useful in clustered deployments.
RM>> RM>> As with any open source effort we question our motives and our direction RM>> frequently and welcome commentary from a community. This is what has made RM>> several Apache projects so strong and what we believe will make LDAPd RM>> strong. What thoughts if any does the community have on this hypothesis and RM>> LDAPd's fundamental reason for being? RM>> RM>> Also we have come to a point where LDAPd has become bigger than our group RM>> alone. We are continuously looking for contributions and guidance to make RM>> the right decisions. From several conversations with Apache members we have RM>> begun to realize that LDAPd would make a good addition to the suite of RM>> flagship servers generously offered by the ASF. Hence we are now taking RM>> formal steps toward offering LDAPd to the Apache community via the RM>> Incubator. Together we can merge the protocols that glue the Internet RM>> together and offer world class software freely in the Apache tradition. RM>> RM>> Sincerely, RM>> Alex Karasulu RM>>
Bruce
