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
