directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Questions about ApacheDS, LdapService, all the servers and the current hierarchy of classes...
Date Sun, 28 Dec 2008 20:52:33 GMT
Alex Karasulu wrote:
> Hi Emmanuel,
> On Sat, Dec 27, 2008 at 7:42 PM, Emmanuel Lecharny <>wrote:
>> Hi guys,
>> as I'm reviewing the configuration, and as I want to cover the LdapService
>> class, I'm a bit concerned with the current hierarchy of class we are using.
>> Let me explain :
>> We have two categories of elements : Services and Servers.
>> Services : Ldap and Ldaps, plus a DirectoryBackedService
>> Servers  : ApacheDS, KdcServer, DnsServer, NtpServer, ChangePasswordServer
> Yes you're right this categorization is flawed and confusing. The history of
> this faulty evolution was due to a merging of ideas from Enrique and
> myself.  I tried to align it and make it consistent over time but my
> attempts were interrupted.
It should not take so long to have something better. If we consider 
ApacheDS as the service container, exposing KDC, DNS, ..., LDAP 
protocols, then we don't have anymore need to talk about servers, 
because ApacheDS is the server itself. Everything else is a service (or 
should be).

This will lead to some refactoring in ApacheDS, but nothing really bad : 
like adding references to something else than LdapService.
>> The current inheritence scheme is :
>> (ProtocolService) o--- [AbstractProtocolService] <-- [NtpServer]
>> (ProtocolService) o--- [AbstractProtocolService] <--
>> [DirectoryBackedService] <-- [LdapService]
> These seem consistent.
>> (ProtocolService) o--- [AbstractProtocolService] <--
>> [DirectoryBackedService] <-- [KdcServer]
>> (ProtocolService) o--- [AbstractProtocolService] <--
>> [DirectoryBackedService] <-- [DnsServer]
>> (ProtocolService) o--- [AbstractProtocolService] <--
>> [DirectoryBackedService] <-- [ChangePasswordServer]
> Here I think we just have naming inconsistencies.  We can simply rename
> these 3 Servers to be suffixed with Service instead to become consistent.
> Regarding terminology, I view Services as components participating in a
> larger system.  The Services provide protocol functionality. 
me too.
>  I view a
> server as a standalone daemon process which can expose 1 or more services.
> I don't like the use of the term Server except in conjunction if need be
> with the ApacheDS process which is not just an LDAP server but can expose
> all these services (the big system).
In fact, ApacheDS does not expose everything. You can perfectly have a 
KerberosServer without accepting any incoming Ldap request, so far. 
ApacheDS is just the LDAP server atm.

>> I think we could have a better scheme. Here are some of the conceptual
>> problems I have :
>> 1) The [LdapService] class has nothing to do with the
>> [DirectoryBackedService], which shares some information we don't need for a
>> Ldap server.
> Perhaps it's shifted away but technically it is directory backed as well.
Yeah, but the point is that the DirectoryBackendService is absolutely 
not used to expose a directory service. It's just a thin wrapper used by 
the kerberos, DNS and ChangePassword server to manage the search baseDN 
and a few other elements.

This is where it's not consistent.

IMO, we have two kind of services : those who are backed by a directory 
(KDC, DNS, LDAP and ChangePaswsword) and those which are not (NTP). The 
few elements we have in the DirectoryBackedService should be removed and 
put in a class extending the DirectoryBackedService. (I think that the 
idea was to expose what has been called a 'catalog', which is just a 
restrained view of the underlaying store.)

We should also consider the configuration, as we may want to move it to 
be stored into the DiT : in this case, every service will be 'directory 
backed services', even NTP. But again, the view will be restained to a 
small part of the directory service : the configuration.

> Enrique had come up with various parameters that were to be backed in the
> DIT for two purposes:
>   (1) for service component configuration
>   (2) for service component runtime data storage
> The runtime data storage is important for services like DNS which stores the
> DNS records in the DIT.  The configuration obviously will store the
> configuration for the component.  Question is: Does [DirectoryBackedService]
> map to #1, #2, or both.  I think Enrique was wise to think of #1 as not
> relavent to this categorization.  I think he intended #2 to be the primary
> distinction which classified a service as a [DirectoryBackedService].
> This makes sense at yet another level.  These components may not use raw
> LDAP for configuration access.  They may use some configuration interface
> which is a facade over LDAP based access to the config data.  API's like
> commons config, the OSGi config interfaces, or even a natural configuration
> bean model specific to the service driven by LDAP ORM can be used.
> Regardless, ultimately these interfaces will access and store their
> information in the DIT.
We may perfectly have a different storage (ie, not LDAP). It's just a 
matter of defining the DirectoryService for each specific high level 
protocol (for instance, do we want to store NTP configuration into a 
ldap server ? Nit sure. May be a simple property file is enough, but 
using a common api to access those data will help to add new services to 
the stack).
>> 3) The ApacheDS class is the LDAP server, relying on two instances of the
>> [LdapService] class, one for LDAP, the other one of LDAPS, plus has a
>> reference to the DirectoryService, which is already present in the
>> [AbstractProtocolService] instance
> IMO, ApacheDS is a server that should encapsulate all the services including
> others unrelated to LDAP like Kerbose for example. 
Sure, but this is not what we have right now.
> The intention was to have
> a server that performed much like MS' Active Directory except services like
> Kerberos and DNS were in process services instead of external processes.
>> 4) Last, not least, the ApacheDS class is still in a apacheds-server-jndi
>> project when we don't have any more JNDI in the picture
> Right.  The thing will all this is we need a high level architectural vision
> and need to work towards that instead of evolving as we go.  The problem is
> in reaching consensus on this.
I think it should not be tahat cocmplicated to reach a consensus. We 
don't have to agree on everything, and I buy your vision, as soon as we 
have some consistencies in the differents layer. Nothing is worst than 
the chaos !
>> How can we fix all those concerns ?
> I think the best approach is to have multiple levels of architectural
> diagrams depicting our grand vision for what we're building here are
> Directory. 
>  Once we do this and agree on it then we can use this to guide
> our decissions.  At this point we have inconsistent fluid models that are
> mutating over time.  We have no solid footing or perspective. We need this
> perspective otherwise we will be building more inconsistences as time
> progresses.  These problems will eventually make it insurmountable to
> autocorrect with refactoring eventually leading to the need for a full
> rewrite.
I don't think we need to jump to a full rewrite. IMO, we are close to 
the initial vision, but some divergences have made their way into this 
initial vision. It's time to go back to the basis, here.
>> Item #4 should be easy to fix : rename the project to apacheds-server-ldap
>> instead of apacheds-server-jndi
> These are small tactical changes that do not fix the main problem. 
Yeah, it's just a remaining stain we didn't cleant while doing our big 
JNDI removal. It does not make any sense now that we don't have JNDI in 
the whole picture to have this project name apacheds-server-[JNDI]. It's 
almost totally disconnected with the previous discussion.

> Nothing makes sense until we draw out the vision and make sure we all agree
> and align. 
Agreed. Let's go back to basis, clean the place on paper, and then fix 
what need to be fixed, and let the rest of the code unchanged. I'm not 
calling for a big redesign here, I'm just asking for a bit more consistence.
>  We could be going down a path that makes it more difficult to
> return from.  Regarding your comments though I think you make very good
> points.  I just don't know if you are right until we agree on a few things
> which should not take forever to do.
> First let's answer these questions and see if we can agree:
> (1) What is the main goal of the apacheds subproject?
> (2) Is it strictly concerned with producing an LDAP service available as a
> component and packaged as a standalone server?
> Having been around for a long time I've always seen ApacheDS as a highly
> configurable composite server: not just an LDAP[S] server.  This has
> governed several decisions I've made over years in the design of the server.
> I think others including yourself have had this view but it might have
> changed I'm guessing after this email.
It hasn't changed, it's just that the current code and configuration 
file does not follow this view. So maybe it's better to fix the code and 
configuration, in order to come back to some purity...
> So, to me, our ultimate goal with ApacheDS is to have it become a platform
> for protocol services which back their protocol content in the DIT.
> Sometimes there might be exceptions with supporting protocols like NTP which
> will be needed for Kerberos operation. 
NTP server (or service) can still fit in the initial big vision.
>  Of course an ntp server outside of
> ApacheDS can provide this service. However our rational was to just provide
> this simple service so users will not to have to install external NTP
> servers in addition to ApacheDS for Kerberos to function.  So the exception
> here is OK but at the end of the day the NTP service still backs it's
> configuration in the DIT but this does not make it a
> [DirectoryBackedService].  Understanding this may give some clarity on how
> we want to model things.
> So at a bare minimum ApacheDS must provide LDAP entry storage which
> corresponds to this [DirectoryService]. It is not a protocol service however
> and perhaps chosing this name for it was a mistake which leads to confusion.
> Let's discuss this stuff in more detail and get a good picture out that we
> can use to govern our decisions so they are more correct in leading us to
> our goal.
Sure. I don't think it will take days, as it's just about semantic.

Thanks !

cordialement, regards,
Emmanuel L├ęcharny

View raw message