Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 79722 invoked from network); 16 Mar 2009 15:48:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Mar 2009 15:48:07 -0000 Received: (qmail 1769 invoked by uid 500); 16 Mar 2009 15:48:06 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 1730 invoked by uid 500); 16 Mar 2009 15:48:06 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 1720 invoked by uid 99); 16 Mar 2009 15:48:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Mar 2009 08:48:06 -0700 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FS_REPLICA,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.46.31 as permitted sender) Received: from [74.125.46.31] (HELO yw-out-2324.google.com) (74.125.46.31) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Mar 2009 15:47:57 +0000 Received: by yw-out-2324.google.com with SMTP id 5so755564ywh.55 for ; Mon, 16 Mar 2009 08:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SgE8QyKTxCaytn/4nvGacgdXfGaJSOfKSvwLPC0jH3A=; b=H68o8+Bzmf0xEOnRYstb1QOuS6YFuRnMf/1ByFBcpVw8fScpxu4A1AiNkBBBjJD430 qVW4TXWzo7g90iSMhSbfCBs9rGI8vaRfuub1eqGFUBBMJ8FISF3MeVVpXisRgKuZhSQW J5I4QqMV19PCy2u5NvB17ne2eX0hAzbwWINfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vdIiQFlZNjj9koiqWk9wU1QJ+smWY1VjsqoGJl0iqyrAm24VG8eyJNpSwTfOega83e wJnHzhBeDqorShtLDOVbGktQsRkCQ/NR034b0Rs+NBpiHXcfCVc83JZk0mQqHdRyE3BN wtH/syB6uJef1sGh0hVIemmU5HAS79m94pwIQ= MIME-Version: 1.0 Received: by 10.231.16.74 with SMTP id n10mr1033109iba.28.1237218455673; Mon, 16 Mar 2009 08:47:35 -0700 (PDT) In-Reply-To: <49BE351E.3000805@nextury.com> References: <49BA6F13.5060709@nextury.com> <49BDD795.6010206@gmail.com> <49BE351E.3000805@nextury.com> Date: Mon, 16 Mar 2009 11:47:35 -0400 Message-ID: Subject: Re: Replication configuration : second thought From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=000325574d7a8f5d2404653e5e04 X-Virus-Checked: Checked by ClamAV on apache.org --000325574d7a8f5d2404653e5e04 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Emmanuel, On Mon, Mar 16, 2009 at 7:16 AM, Emmanuel Lecharny wr= ote: > Hi guys, > > after having thought about the configuration a bit more, I'm not sure tha= t > it should be associated with a replication interceptor. I'm not even sure > that such an interceptor makes sense. > > If we consider both side, a server can be either a client, a server, or > both. But we will consider each case as distinct. > > If the server is a client (a replica, or a consumer), then it connects t= o > a master server using a RefreshAndPersist control associated to a search > request. This connection can be managed in a specific interceptor, but in > any case, the searchResults will have to go through the whole chain. As > it's also a persistent connection, it would be better to deal with it at = the > DirectoryService level. > > If the server is a master (a producer), then we will consider that a clie= nt > search request has been received, and persists. All the resulting entries > are filtered by the chain, and AFAICT, we don't need to add an intercepto= r > to filter the results. We just have to consider that the clinet is a > standard client. > 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). 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. 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. 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 instea= d 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. So I recommend the following: (1) Implement a subsystem for replication with a top level facade bean that can be configured via XBean. (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. (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. (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? 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 refere= d 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. Question is do we want replication to be a high level system in the fronten= d since it leverages the protocol? Or do we want it in the DS which was traditionally core services without networking? As I write this I am leaning towards the LdapServer. What we have to ask ourselves is does the replication subsystem need access to protocol layer structures and information? Another question is does anything other than th= e interceptor need access to the ReplicationManager facade (presuming this is what we named it). This is a very important question. > > So I would suggest to move the replication configuration at a higher leve= l > (DirectoryService), and remove the ReplicationInterceptor. > > This is not definitive, I'm waiting for any comment before moving on this > direction regarding to the interceptor removal (I'm not 100% sure that we > don't need some replication specific filtering, for instance). > > wdyt ? > > -- > -- > cordialement, regards, > Emmanuel L=E9charny > www.iktek.com > directory.apache.org > > > --000325574d7a8f5d2404653e5e04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Emmanuel,

On Mon, Mar 16, 2009 at 7:16= AM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Hi guys,

after having thought about the configuration a bit more, I'm not sure t= hat it should be associated with a replication interceptor. I'm not eve= n sure that such an interceptor makes sense.

If we consider both side, a server can be either a client, a server, or bot= h. But we will consider each case as distinct.

If the server is a client (a replica, or a consumer), then =A0it connects t= o a master server using a RefreshAndPersist control associated to a search = request. This connection can be managed in a specific interceptor, but in a= ny case, the searchResults will have to go through the whole chain. =A0As i= t's also a persistent connection, it would be better to deal with it at= the DirectoryService level.

If the server is a master (a producer), then we will consider that a client= search request has been received, and persists. All the resulting entries = are filtered by the chain, and AFAICT, we don't need to add an intercep= tor to filter the results. We just have to consider that the clinet is a st= andard client.

Regarding Repl Terminology
-----------------------= -----------------

OK let's get religious about using replication= specific terminology.=A0 Instead of talking about client, server, master, = slave, let's use the terms supplier and consumer.=A0 The reason why I l= ike these terms besides their common use is because it clearly denotes dire= ctionality and breaks down elements of the replication agreements to their = atomic components. So I'd like to think in terms of a consumer configur= ation (with replication agreement) and a supplier configuration (also with = a repl-agmt).


Regarding Configuration
-----------------------------------
<= br>On a separate note, I've been torn between two ways of thinking abou= t configuration for some time.=A0 Regardless of whether we're talking a= bout replication subsystem or not, we could apply this general discussion t= o any feature/facet of the server which also contains an interceptor.=A0 So= this discussion applies across the board as a configuration issue.

So where do we configure a subsystem? In the interceptor configuration?= Or as a separate component under the directory service.=A0 Over the years = I've made many mistakes with this stuff.=A0 I like the idea of having a= high level subsystem bean that contains all the configuration for the feat= ure in one place instead of being distributed all over the configuration tr= ee.=A0 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.= =A0 It's more manageable.

I was always uncomfortable with bloating these interceptors with code.= =A0 Instead I just wanted to leave them as simple hooks that funneled event= s (calls) into the subsystem.=A0 The intercetor is then a simple listener t= hat belongs to the subsystem in question. So the listener detects events an= d shuffles them into the subsystem to properly respond.=A0 This allows us t= o keep the configuration in the top level subsystem facade while properly d= esigning the various parts of the subsystem underneath with clarity instead= of jamming all the subsystem handling logic tightly into interceptors whic= h leads to code bloat in the interceptor modules leading to a jumbled up me= ss that is hard to manage.

So I recommend the following:

=A0 (1) Implement a subsystem for = replication with a top level facade bean that can be configured via XBean.= =A0
=A0 (2) Setup a means to setup a set of replication agreements.=A0 = The same DSA can be both a consumer and a supplier to many other DSAs.=A0 S= o we'll have a set of consumer agreements and a set of supplier agreeme= nts.
=A0 (3) Build the interceptor out to be just a simple hook into other Class= es in the subsystem.=A0 Make the subsystem return values for LDAP methods i= n the chain that require return values.
=A0 (4) Don't wory about add= ing the replication intercetor to the chain via XBean, just have the subsys= tem inject the intercetor programatically.=A0 The user does not need to kno= w this interceptor even exists right?


DirectoryService vs. LdapServer
--------------------------------= --------------

Now I don't know the answer to this but something= itches me about putting the replication subsystem into the DirectoryServic= e.=A0 For some time now the DS corresponding to the top level facade repres= enting what we always refered to as the core.=A0 The core was never suppose= d to be networked because then that would pull dependencies like MINA.=A0 I= t was the frontend that had network capability.=A0 I know mitosis broke fro= m this but seems the moron who wrote it broke all the rules.

Question is do we want replication to be a high level system in the fro= ntend since it leverages the protocol? Or do we want it in the DS which was= traditionally core services without networking?

As I write this I a= m leaning towards the LdapServer.=A0 What we have to ask ourselves is does = the replication subsystem need access to protocol layer structures and info= rmation? Another question is does anything other than the interceptor need = access to the ReplicationManager facade (presuming this is what we named it= ).

This is a very important question.

=A0

So I would suggest to move the replication configuration at a higher level = (DirectoryService), and remove the ReplicationInterceptor.

This is not definitive, I'm waiting for any comment before moving on th= is direction regarding to the interceptor removal (I'm not 100% sure th= at we don't need some replication specific filtering, for instance).
wdyt ?

--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org



--000325574d7a8f5d2404653e5e04--