directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <>
Subject Re: LDAP Proxy backend
Date Mon, 25 Apr 2005 18:43:54 GMT
i've removed my original posts to make this a bit
easier to read...

--- Alex Karasulu <> wrote:

> Hmm I disagree here a bit.  The servlet-filter
> system is really 
> something for facilities.  At the present moment new
> filters are not hot 
> deployable.  It would be easy to make them be
> thought.  However I don't 
> expect users of the directory to create Interceptors
> when they want to 
> respond to an event or trigger a change based on an
> operation (nice for 
> controls btw).  So we would like to have a distinct
> DDL grammar like in 
> SQL for creating triggers.

Well, the trigger layer can be implemented as an
interceptor pretty quickly.  
> Stored procedures also need to exist in a multiuser
> environment.  There 
> is no reason why these constructs should only be
> specific to the world 
> of the relational database.

While the CONCEPTS are needed in a multi-user
environment, the contructs don't really map all that
well.  Stored procedures can be used in a couple of

1.  As a unit of funcitonality

2.  As an abstraction layer giving the administrators
better control of who/what has access to tables and
ensuring that they can control when changes are made
to tables.

In both these situations interceptors and the vd in
general play these roles in a way that is much more
suited to directory data.  For instance it's very
common to not allow direct access to network resources
but allways require the use of a proxy.  This is also
very true of directory deployments.  by placing a
proxy/vd between applications and directory data you
are giving that seperation layer that most directory
services don't provide.  In the case where someone is
using apacheds as the primary directory you still may
require that proxy layer depending on the policies of
the IT department.

Perhaps instead of the idea of stored procedures (at
least in the classical TSQL/PSQL... sence) you might
want to think about using something like a groovy to
simplify things?

> True but again we cannot expect users to do this if
> they want to respond 
> to an LDAP operation.  Think of what a nightmare
> this would have been in 
> the RDBMS world.  Think of users having to add an
> Interceptor to be able 
> to add a before trigger on a table on insert.  That
> would drive users 
> away IMHO.  

Well, I've done a lot of vd deployments and a lot of
relational db deployments.  What part is dificult? 
The creation of the interceptor (writing the code), or
the deployment of the interceptor?  If the code it's
self is pretty straight forward (which it often is),
then wouldn't it be better to center on re-using
existing knowledge (in this case knowledge of java). 
Stored Procs and Triggers in the relational world are
based on a tabuler format.  Once you move to
hierarchal model you lose a lot of simplicity and you
end up having to change how you code anyway (As in
directory processesing requires knowledge of namespace
and how to handle multi-value attributes).

> A DDL is needed.  The DDL is stored in
> the system backend 
> under a trigger management system which happens to
> have an Interceptor 
> within the chain.  That would be a much simpler
> solution for the user.

samething as above, i think at this point the words
trigger&stored proc can be interchanged with "script"

> That's the whole point to a view however you are
> formalizing the 
> specification of the unit of virtualization.  There
> is no way to specify 
> this today so a DDL is needed.  

i disagree.  i don't think there's any value in
"standardizing" a way of specifying a virtual layer. 
The value of standards is in the protocols (ldap,
dsmlv2, spml...) and in re-using existing knowledge
(ie using JNDI/JLDAP as an internal object model,
using java/javascript as the programming
language....).  I really don't see a lot of value in
something like a "create view dc=myroot,dc=com .....",
it's very simplistic and doesn't provide room for a
lot of the complexities that could come into play 
with views/virtualization.

> There are all sorts
> of ways to create 
> views.  It would be nice to give the user the
> ability to instantly 
> create these views through the DDL.  Keep in mind,
> not all 
> virtualization involves data that is external to the
> directory.  You may 
> have to merge data from multiple backends that might
> be store data 
> locally within the DSA.  

Thats not really a view, that synchronization and is a
whole other can of worms :-)

> Views allow us to do this
> in a standard manner 
> and will be very similar to SQL views.  Combined
> with stored procedures 
> this is a very powerful facility for virtualization.

yep,  i couldn't agree more!

> Today the use of a backend to implement a VD is a
> bastardization because 
> there is no specification.  

what are you going to specify?  How data is stored? 
How data is accessed?  How backends fall together to
create the view?  How would you apply a DDL?  One DDL
directive for each level of the hierarchy?  what about
overlapping namespaces?  How would you configure
namespaaces that fall underneath other namespaces?

The simplicity of DDL (and DDL style languages) would
fall apart inside of a directory IMHO.

>The space is new and
> people have just solved 
> the problem quickly to meet a demand.  We need
> standards basically.  

I completly disagree.  Radiant came out with it's vd
in late 99/early 2000 and octet stirng came out with
it's first version in early 2001.  So vd has actually
been around for 4-5 years.  it just hasn't been as
much of a buzz word as of late.

Again, there are standards.  There are standard
protocols, "standard" programming tools, and de-facto
standards for how data is arranged and applications
are deployed.  

> If 
> backends (partitions in ApacheDS terms) are plugable
> then views (again 
> their DDL) are the primary construct for
> virtualization.

more or less

> <snip/>
> >What I think would be REALLY interesting (at least
> >from a developer's perspective) is a way to
> simplify
> >the interaction with the directory from inside of a
> >plugin.     It's very common for IT departments to
> >invest in specialized libraries for simplifying
> >access.  There are also more then a couple of
> >SQL<->LDAP translation systems, in both Java and
> ADO. 
> >It's not something i've put a lot of thought into
> from
> >inside of a directory, but i would definitly think
> it
> >would help decrease the barier of entry for
> apacheds.
> >  
> >
> I think people have tried to compare LDAP and SQL to
> ease the learning 
> curve as you say.  However LDAP knowledge is
> spreading fast thanks to M$ 
> and AD spreading across IT shops.  LDAP is no longer
> this wierd data 
> access mechanism anymore that only a select few
> understand. 

I've worked with a lot of AD shops, and LDAP is a 4
letter word to them sometimes :-).  Remember that AD
in a pure MS world doesn't involve knowing what LDAP
is (and u'd be shocked as to how little people who use
AD can know about LDAP and still be very proficient at
their jobs).  To this day I am reading analyst reports
and running into companies that spend a lot of time
abstracting out LDAP because of it's complexities.  I
do agree it's a lot better then it was even a couple
of years ago, but it isn't quite there yet.

>  I don't 
> think its worth the time to do this but if its of
> interest to you then 
> by all means feel free to pursue it.

Aint open source great? :-)

> In general, I would like to work on some draft
> specifications so we can 
> standardize some things within the VD space.  I
> think views along with a 
> DDL for them is an excellent way for us to do this.

Based on my experience deploying virtual directories,
I really just don't see value in a standard DDL. 
maybe something like a Code Defenition Language (CDL)
where the interfaces are standardized, but JNDI is an
attempt at that and to be quite honest i've never
liked it :-).


> -Alex

View raw message