directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Server/Service inconsistency
Date Sun, 02 Nov 2008 13:21:05 GMT

during the MINA 2 migration, I found some incosistency in the names we 
are using. We are mixing Server and Service, and doing some 
initialization in the wrong class for some protocol. Let's teak some 
clear examples :

Ntp :
We have a NtpServer and a NtpService. The NtpService is just an 
interface, implemented by NtpServiceImpl and used in the 
NtpProtocolHandler class. The NtpServer extends AbstractProtocolService, 
which is a nonsense. The transport initialization is done in the 
NtpServer class, just for the record.

Dns :
We don't have any kind of DnsService, but we have a DnsServer which 
extends DirectoryBackedService (again, is this a service ???). The 
transport initialization is also done in this class

Dhcp :
I'm not even sure that this simply works... We have a DhcpService, but 
there is no place where we initialize any transport ...

Kerberos :
We have a KdcServer, exteding DirectoryBackedService, but not 
KerberosService. This is where we initialize the transport

ChangePwd :
Same thing : ChangePasswordServer extends DirectoryBackedService, no 
ChangePwdService. Transport initialization done in this class.

Ldap :
A LdapService class extending DirectoryBackedService, where the 
transport initialization is done. We don't have any LdapServer class.


Let's try to be consistent. We have a DirectoryBackedService class, 
which allow some other services to rely on the storage and access method 
offered by Ldap. In many cases, we will not use any kind of transport, 
like when embedding ADS in an application, thus a LdapServer is just a 
LdapServer plus a transport protocol. We should have the same for any 
other protocol we are supporting.

I suggest that the transport protocol initialization is to be done in a 
XXXServer class, and that it's related to the XXXService which implement 
the logic for the XXX protocol. This way, we will have some kind of 
consistency at a low price : definition of a couple of classes, and 
almost no modification of the code.

wdyt ?

cordialement, regards,
Emmanuel L├ęcharny

View raw message