directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 18:50:32 GMT
On Mon, Mar 16, 2009 at 12:10 PM, Emmanuel Lecharny <>wrote:

>  Regarding Repl Terminology
>> ----------------------------------------
>> OK let's get religious about using replication specific terminology.
>> Instead of talking about client, server, master, slave, let's use the
>> terms
>> supplier and consumer.  The reason why I like these terms besides their
>> common use is because it clearly denotes directionality and breaks down
>> elements of the replication agreements to their atomic components. So I'd
>> like to think in terms of a consumer configuration (with replication
>> agreement) and a supplier configuration (also with a repl-agmt).
> Totally +1. This is why I added them in (). So let's use them exclusively.
>> Regarding Configuration
>> -----------------------------------
>> On a separate note, I've been torn between two ways of thinking about
>> configuration for some time.  Regardless of whether we're talking about
>> replication subsystem or not, we could apply this general discussion to
>> any
>> feature/facet of the server which also contains an interceptor.  So this
>> discussion applies across the board as a configuration issue.
> probably
>> So where do we configure a subsystem? In the interceptor configuration? Or
>> as a separate component under the directory service.  Over the years I've
>> made many mistakes with this stuff.  I like the idea of having a high
>> level
>> subsystem bean that contains all the configuration for the feature in one
>> place instead of being distributed all over the configuration tree.
>> Localization is always good because then the user and developer only needs
>> to goto one place to get this information or modify the code for it.  It's
>> more manageable.
> That could lead to a centralized configuration in the DiT...

Exactly this is one of the benefits of making the configuration for a
subsystem in a single configuration bean rather than spreading the
configuration all over the place in some beans and interceptors etc.  This
is the luxury we have to gain from better organization.

>  I was always uncomfortable with bloating these interceptors with code.
>> Instead I just wanted to leave them as simple hooks that funneled events
>> (calls) into the subsystem.  The intercetor is then a simple listener that
>> belongs to the subsystem in question. So the listener detects events and
>> shuffles them into the subsystem to properly respond.  This allows us to
>> keep the configuration in the top level subsystem facade while properly
>> designing the various parts of the subsystem underneath with clarity
>> instead
>> of jamming all the subsystem handling logic tightly into interceptors
>> which
>> leads to code bloat in the interceptor modules leading to a jumbled up
>> mess
>> that is hard to manage.
> In fact, there are _very few_ interceptors that need a configuration :
> - Authentication (takes a list of authenticators, something we may want to
> be global too)
> - Journal ( but this is a new interceptor, and the configuration is not yet
> stabilized)
> - Replication, but this is exactly what we are discussing about
> and that's it.
> So far, there is nothing that prevent us to get rid of any parameter in all
> the interceptors...

This is good since it gives us the chance to do this right and not have to
clean anything up.

>  So I recommend the following:
>>  (1) Implement a subsystem for replication with a top level facade bean
>> that can be configured via XBean.
> done
>>  (2) Setup a means to setup a set of replication agreements.  The same DSA
>> can be both a consumer and a supplier to many other DSAs.  So we'll have a
>> set of consumer agreements and a set of supplier agreements.
> +1
>>  (3) Build the interceptor out to be just a simple hook into other Classes
>> in the subsystem.  Make the subsystem return values for LDAP methods in
>> the
>> chain that require return values.
> okie
>>  (4) Don't wory about adding the replication intercetor to the chain via
>> XBean, just have the subsystem inject the intercetor programatically.  The
>> user does not need to know this interceptor even exists right?
> this can be discussed further, as this question is a bit too wide right
> now. Let's use the mechanism we have right now.

OK just as long as the interceptor does not have any configuration to it we
should be fine.

>> DirectoryService vs. LdapServer
>> ----------------------------------------------
>> Now I don't know the answer to this but something itches me about putting
>> the replication subsystem into the DirectoryService.  For some time now
>> the
>> DS corresponding to the top level facade representing what we always
>> refered
>> to as the core.  The core was never supposed to be networked because then
>> that would pull dependencies like MINA.  It was the frontend that had
>> network capability.  I know mitosis broke from this but seems the moron
>> who
>> wrote it broke all the rules.
> what about having an embedded server with replication capability ?

Embedded does not mean the protocol is not exposed.  You can embed with the
front end or without.  Without the frontend you will not get replication
either since our replication sits on top of the LDAP protocol now.  So it
makes more sense to do this in the frontend IMHO.

>  Question is do we want replication to be a high level system in the
>> frontend
>> since it leverages the protocol? Or do we want it in the DS which was
>> traditionally core services without networking?
> that's a good question... I would tend to think that injecting the
> replication subsystem into the core server is probably a better way, as it
> will be available not only to the standalone server, but also for an
> embedded server (all in all, the networked server just embedded the core...)
I would respectfully disagree here.  Those who just want to embed the core
without the LDAP protocol and socket servers do so because they do not want
to expose anything.  We would still have to expose a network protocol even
if not the entire LDAP protocol, to do replication.  It makes less sense to
me to put the network machinery into the core.


View raw message