Alex Karasulu wrote:
Hi Emmanuel,
On Sat, Dec 27, 2008 at 7:42 PM, Emmanuel Lecharny <[email protected]>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.
Yop.
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.
Agreed.
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.
<snip/>
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.
yop.
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.
<snip>
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.
okie.
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
www.iktek.com
directory.apache.org
