Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of ole.ersoy@gmail.com designates
 64.233.162.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=KjCDq//v05zxykLNyUmnebN/lLhRVYYXBEgZ8QtQyp65nEAAgcCQK+ryUVoBea5VhXYMeXsEV3FSm/ZQ3t73H7LDi4cCnUgXS+J1++bu7FdOJ90Sg2XwmUfjM4nV+nA600GW1LXOCQljcF9U8lmA1zRFF7A5/zjtkh8/j2GJdyM=
Message-ID: <4601C9BD.6080206@gmail.com>
Date: Wed, 21 Mar 2007 19:11:41 -0500
From: Ole Ersoy <ole.ersoy@gmail.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070212)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [LDAP DAS] Efficient Updating of Persisted Objects
References: <4600BD43.3090406@gmail.com>
	 <d45b08f00703210304q7ec4be5dk1bccfce8387be31e@mail.gmail.com>
	 <46015C9C.3010109@gmail.com>
	 <d45b08f00703210952g3fb41f91o46ddfeb4b355e2f3@mail.gmail.com>
	 <4601774A.2030001@gmail.com>
	 <d45b08f00703211144m2c8ae8baofd173157bedc982c@mail.gmail.com>
	 <46018769.9040908@gmail.com>
 <5a75db780703211409w2d131de7scb04132a5fa84881@mail.gmail.com>
 <4601BD8E.5070305@gmail.com>
In-Reply-To: <4601BD8E.5070305@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

OK - Flight got canceled so I'm back in action until tomorrow morning.

Emmanuel Lecharny wrote:
> Luciano Resende a �crit :
>
>> Sorry if I'm just jumping on the discussion, but I'd like to 
>> understand it a
>> little more. Is the idea here to have client performing LDAP operations,
>> using a SDO/DAS layer that can be easily switched back and forth 
>> between a
>> pure LDAP repository and a RDB repository ?
Yes.

Let me just give a concrete example of what I mean so that it's clear.

Someone creates a webapp, that stores account information.
So theres a browser client that talks to Tomcat.
Tomcat runs a servlet talks to an integration layer consisting of SDOs.

When a user changes account information Tomcat uses the webapps's
integration layer to update the persistance tier, consisting either of 
an RDB or LDAP server.

Thus the SDO instances that hold the account data could retrieve their 
state either
from an RDB or from ADS.

If they get the account information from the RDB, they would use the RDB 
DAS.

If they want to get the info from ADS, they would use the LDAP DAS.

FOR READING
SDOs request state
Client(SDOs) -- > LDAP DAS --> ADS
Client(SDOs) <-- LDAP DAS <-- ADS

SDOs need to update ADS
Client(SDOs) -- > LDAP DAS --> ADS

So that's what I'm thinking.

I think we got on the track of discussing ADS's persistance layer as 
well due to me wondering
whether whether it would be faster if an LDAP jndi client
sent individual attributes to be persisted, rather than an entire 
object.  However I did not use the wording LDAP jndi client,
so it could have been miss understood.

So are we cleared up?

Thanks for jumping in Luciano :-)

- Ole