directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Date Mon, 21 May 2007 22:19:27 GMT
On 5/21/07, Quanah Gibson-Mount <> wrote:
> --On May 21, 2007 5:34:45 PM -0400 Alex Karasulu <>
> wrote:
> > LDAP servers today do no justice to the technology.  I think we have a
> > chance to bring this protocol to the
> > 21st century.
> >
> > Eventually we'll be at the same level as other servers out there.  And
> > hopefully those other efforts will start to
> > take LDAP where we want it to go just because they want to remain
> > competitive with our feature set.
> I've discussed various feature enhancements to LDAP in general with Howard
> Chu over the years.  One of the major problems is if you want to stay RFC
> compliant or not.

This is not necessarily true.  You can still introduce these rich
integration tier
constructs into LDAP without breaking with protocol compliance.  We will do
this and still be compliant with our Open Group certification.  There is
room for extending LDAP while leveraging existing constructs in the RFCs.

This is just an analogy but consider those RDBMS' which are SQL 92 compliant
yet all of them have different mechanisms for implementing a stored
while the same mechanism for executing the SP exists in the standard.

In our perpendicular plane (the LDAP plane) we have implemented stored
procedures as Java static methods that operate on the DIT.  Users can
any kind of SP logic and use a server side JNDI provider to access the DIT
they need to.  However we use a standard mechanism to invoke the SP from the
client: meaning we use an extended operation to expose the SP.  This
with LDAPv3 and yet it introduces a new construct LDAP has never seen
We owe this advance in part to Java's dynamic nature to store and load
from the DIT where users without a restart can add their own stored

So as you can see we do not break with the protocol and are still complaint
certified by the Open Group yet we are able to introduce these new features
the LDAP community is hungry for.

The name of the game is to get people to use LDAP for data that belongs in a

Directory rather than them just give up with antiquated servers that can at
serve as a store for white pages.

The way in which the protocol was written makes it
> particularly difficult to add new features while remaining compliant (that
> is in large part why the overlay system was developed for OpenLDAP).  What
> I've suggested a few times, is to throw away LDAP and start over with
> something new (What I generally call SDAP or SMART DAP).

That's not going to happen.  We just need to be a bit more creative and see
I btw had started working with the OpenLDAP code base years ago (about 7
years ago)
before I starting working on ApacheDS.  This is when I realized that Java
had more than
the compile once run anywhere advantage.  Dynamic binding is what allowed us
to implement
SPs in ApacheDS overnight.  With OpenLDAP it was almost impossible but this
was not due
to it's inherent design but the language chosen.

Incidentally this and their brittle SUN DS is why the SUN folks woke up and
decided to start
work on OpenDS.  They see the obvious advantages and have verified my
initial premise
almost 6 years ago.  Perhaps the OpenLDAP forks can come to this same
conclusion to help
us build a better server together ;).

Of course, then
> one would no longer have an LDAP server, and I'm guessing corporate
> vendors
> would be slow to adopt (given the slow pace of their LDAP v3 adoption
> already...).

Yeah this is not going to happen or if it does it will take another 2
decades.  The key to having
an LDAP reniassance is simple really.  Here's the formula IMO:

(1) Resusitate some critical X.500 concepts that the LDAP creators chopped
out of LDAP
      to oversimplify it: namely talking about the administrative model here
and not OSI stack.
      Kurt began doing this with couple RFCs like the one for subentries and
collective attributes.
(2) Provide some solid tooling to simplify and accomodate the lack of
knowledge around LDAP
      and X.500 concepts which LDAP is built upon.  The RDBMS world is rich
with tooling support
      yet the LDAP world has virtually none.
(3) Provide the rich integration tier constructs many RDBMS developers are
accustomed to yet
      transposed to the LDAP plane.  These constructs include:
      (a) LDAP Stored Procedures
      (b) LDAP Triggers
      (c) LDAP Views
      (d) LDAP Queues (to interface with MOMs)

*** incidentally we use the X.500 admin model to implement these features

If these critical peices of the puzzle are solved then we'll see the
Directory come back as the swiss army
knife of integration it was intended to be.  Right now Directories are stuck
serving out white pages and
admins are still scratching their heads when trying to figure out how to
remove users from groups when
users are deleted to maintain referrential integrity.  Why have we messed
this up so bad?

The key to solving the integration problems with LDAP which will plauge the
enterprise for the next 30 years
lie in these critical features.  If we cannot see this and correct our path
together then our chances
of renewing the demand for LDAP are lost as new half baked technologies
emerge to solve these problems
and clutter the vision of those that should be deciding on LDAP.


View raw message