You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2006/09/04 05:40:31 UTC
[ADS 2.0] Detach JNDI from ApacheDS
Hi,
Yes, I know this is a very radical approach, but I think this is mandatory
to accelerate our development.
JNDI is an abstraction API for all kinds of directory services. LDAP is a
part of the list. From my experience, JNDI is not really the best API to
access an LDAP server. It can access the LDAP server, but not gives us the
best convenience from the viewpoint of the API user. And we're using JNDI
Name and DirContext interface to program our internals. That's why we need
a new API which perfectly fits into LDAP. By doing that, we can program our
interceptors and partitions more easily mapped into LDAP operations rather
than JNDI operations.
Of course, this change will take away the advantage of embedded mode unless
we spend more time to create a bridge between JNDI and our API. But I think
our primary concern is to provide a high quality LDAP server whose internals
are highly optimized for LDAP, not to provide a JNDI embeddable LDAP server.
Here's my suggestion:
1. Change the DirectoryPartition and Interceptor interface to fit 1:1 to
LDAP operations rather than JNDI operations.
* Core/ServerDirContext will be removed in this process.
* ServerStartupConfiguration should be merged into StartupConfiguration
and embedded mode should go away because we can just disable the LDAP
service later when OSGi is adopted.
2. Migrate to OSGi framework
* All protocol services will be provided as OSGi bundles and should be
plugged into ApacheDS dynamically. Because we don't have any embedded JNDI
provider, LDAP protocol connection to loopback device will be used
temporarilly.
3. Support an embedded mode
* But who will ever use DNS or other services without LDAP provider? The
only advantage of the embedded access is the small performance gain which
might not be that important in distributed directory services.
Was this too radical? :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Trustin Lee <tr...@gmail.com>.
On 9/6/06, Ersin Er <er...@gmail.com> wrote:
>
> We will definetely support JNDI with an adoptor. It's really not a
> matter. The problem is how we will design our new architecture :-)
Exactly. The problem is about our new *internal* architecture. There
shouldn't be any big change in its exposed interfaces.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Ersin Er <er...@gmail.com>.
We will definetely support JNDI with an adoptor. It's really not a
matter. The problem is how we will design our new architecture :-)
On 9/5/06, John E. Conlon <jc...@verticon.com> wrote:
> On Mon, 2006-09-04 at 18:51 -0400, Alex Karasulu wrote:
> > Emmanuel Lecharny wrote:
> > > Trustin Lee a écrit :
> > >
> > >> Hi,
> > >>
> > >> Yes, I know this is a very radical approach, but I think this is
> > >> mandatory to accelerate our development.
> > >>
> > >> JNDI is an abstraction API for all kinds of directory services. LDAP
> > >> is a part of the list. From my experience, JNDI is not really the
> > >> best API to access an LDAP server. It can access the LDAP server, but
> > >> not gives us the best convenience from the viewpoint of the API user.
> > >> And we're using JNDI Name and DirContext interface to program our
> > >> internals. That's why we need a new API which perfectly fits into
> > >> LDAP. By doing that, we can program our interceptors and partitions
> > >> more easily mapped into LDAP operations rather than JNDI operations.
> > >
> > > The beauty of LDAP is that you can work with JNDI, Novelm API (jldap :
> > > http://www.openldap.org/jldap/) or even our own new API. We can keep the
> > > JNDI approach, because it's common to many application, and dropping it
> > > would be seen a little bit questionnable by our current users (I'm
> > > thinking of Geronimo)
> > >
> > >>
> > >> Of course, this change will take away the advantage of embedded mode
> > >> unless we spend more time to create a bridge between JNDI and our
> > >> API. But I think our primary concern is to provide a high quality
> > >> LDAP server whose internals are highly optimized for LDAP, not to
> > >> provide a JNDI embeddable LDAP server.
> > >
> > > We can provide both, in my opinion. JNDI is an interface...
> > >
> >
> > Yeah I think we can provide both. Trustin was referring to a bridge
> > before and I agree.
> >
> > The LDAP protocol provider would not use this bridge however. It would
> > use the LDAP specific API instead.
> >
> > Other protocol providers that back their information within ApacheDS can
> > use the JNDI bridge.
> >
> > >> Here's my suggestion:
> > >>
> > >> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1
> > >> to LDAP operations rather than JNDI operations.
> > >> * Core/ServerDirContext will be removed in this process.
> > >> * ServerStartupConfiguration should be merged into
> > >> StartupConfiguration and embedded mode should go away because we can
> > >> just disable the LDAP service later when OSGi is adopted.
> > >
> > > This is a possible move. Alex ?
> >
> > Yeah I think can. What I recommend is small refactorings to slowly
> > bring us towards this or a similar goal. First we can decouple the JNDI
> > provider from the core. We can also decouple the configuration from the
> > core as well. By doing these things we will arrive at a better
> > structure and then will have better vision to figure out what needs to
> > be done next.
> >
> > >>
> > >> 2. Migrate to OSGi framework
> > >> * All protocol services will be provided as OSGi bundles and should
> > >> be plugged into ApacheDS dynamically. Because we don't have any
> > >> embedded JNDI provider, LDAP protocol connection to loopback device
> > >> will be used temporarilly.
> >
> > Hmmm I don't know about this. I think these guys can use the bridge and
> > not have to go through the wire which would slow things down. Trustin
> > was this lookback thing related to conversations we had in the past over
> > ClassLoader issues and instances of the DirectoryServer? My memory is a
> > bit hazy here.
> Well we do have an embedded JNDI provider - it is still in its infancy
> but lives within the trunks/apacheds/osgi.
>
> Currently running an 'embedded' ApacheDS within the same VM as my
> application using a version of the provider (modified) but the cool
> thing is: with the magic of OSGi and 'JNDI' my 'application' does not
> know anything about ApacheDS. ApacheDS is a set of OSGi bundles that to
> my application bundles, offer an OSGi service (InitialContextFactory).
> The virtual machine also runs an LDAP protocol bundle that allows LDAP
> clients to change the backend configuration of my app. If I wanted I
> could (at runtime) stop the ApacheDS and load an alternative
> InitialContextFactory that uses a LDAP service on another machine.
>
> My app does not go through LDAP but JNDI. Using LDAP for clients access
> to modify the configuration. Making an alternative LDAP interface is
> fine if necessary for internal optimization but we should still support
> JNDI higherlevel access.
>
> John
>
>
--
Ersin
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by "John E. Conlon" <jc...@verticon.com>.
On Mon, 2006-09-04 at 18:51 -0400, Alex Karasulu wrote:
> Emmanuel Lecharny wrote:
> > Trustin Lee a écrit :
> >
> >> Hi,
> >>
> >> Yes, I know this is a very radical approach, but I think this is
> >> mandatory to accelerate our development.
> >>
> >> JNDI is an abstraction API for all kinds of directory services. LDAP
> >> is a part of the list. From my experience, JNDI is not really the
> >> best API to access an LDAP server. It can access the LDAP server, but
> >> not gives us the best convenience from the viewpoint of the API user.
> >> And we're using JNDI Name and DirContext interface to program our
> >> internals. That's why we need a new API which perfectly fits into
> >> LDAP. By doing that, we can program our interceptors and partitions
> >> more easily mapped into LDAP operations rather than JNDI operations.
> >
> > The beauty of LDAP is that you can work with JNDI, Novelm API (jldap :
> > http://www.openldap.org/jldap/) or even our own new API. We can keep the
> > JNDI approach, because it's common to many application, and dropping it
> > would be seen a little bit questionnable by our current users (I'm
> > thinking of Geronimo)
> >
> >>
> >> Of course, this change will take away the advantage of embedded mode
> >> unless we spend more time to create a bridge between JNDI and our
> >> API. But I think our primary concern is to provide a high quality
> >> LDAP server whose internals are highly optimized for LDAP, not to
> >> provide a JNDI embeddable LDAP server.
> >
> > We can provide both, in my opinion. JNDI is an interface...
> >
>
> Yeah I think we can provide both. Trustin was referring to a bridge
> before and I agree.
>
> The LDAP protocol provider would not use this bridge however. It would
> use the LDAP specific API instead.
>
> Other protocol providers that back their information within ApacheDS can
> use the JNDI bridge.
>
> >> Here's my suggestion:
> >>
> >> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1
> >> to LDAP operations rather than JNDI operations.
> >> * Core/ServerDirContext will be removed in this process.
> >> * ServerStartupConfiguration should be merged into
> >> StartupConfiguration and embedded mode should go away because we can
> >> just disable the LDAP service later when OSGi is adopted.
> >
> > This is a possible move. Alex ?
>
> Yeah I think can. What I recommend is small refactorings to slowly
> bring us towards this or a similar goal. First we can decouple the JNDI
> provider from the core. We can also decouple the configuration from the
> core as well. By doing these things we will arrive at a better
> structure and then will have better vision to figure out what needs to
> be done next.
>
> >>
> >> 2. Migrate to OSGi framework
> >> * All protocol services will be provided as OSGi bundles and should
> >> be plugged into ApacheDS dynamically. Because we don't have any
> >> embedded JNDI provider, LDAP protocol connection to loopback device
> >> will be used temporarilly.
>
> Hmmm I don't know about this. I think these guys can use the bridge and
> not have to go through the wire which would slow things down. Trustin
> was this lookback thing related to conversations we had in the past over
> ClassLoader issues and instances of the DirectoryServer? My memory is a
> bit hazy here.
Well we do have an embedded JNDI provider - it is still in its infancy
but lives within the trunks/apacheds/osgi.
Currently running an 'embedded' ApacheDS within the same VM as my
application using a version of the provider (modified) but the cool
thing is: with the magic of OSGi and 'JNDI' my 'application' does not
know anything about ApacheDS. ApacheDS is a set of OSGi bundles that to
my application bundles, offer an OSGi service (InitialContextFactory).
The virtual machine also runs an LDAP protocol bundle that allows LDAP
clients to change the backend configuration of my app. If I wanted I
could (at runtime) stop the ApacheDS and load an alternative
InitialContextFactory that uses a LDAP service on another machine.
My app does not go through LDAP but JNDI. Using LDAP for clients access
to modify the configuration. Making an alternative LDAP interface is
fine if necessary for internal optimization but we should still support
JNDI higherlevel access.
John
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Trustin Lee <tr...@gmail.com>.
On 9/5/06, Alex Karasulu <ao...@bellsouth.net> wrote:
>
> >> 2. Migrate to OSGi framework
> >> * All protocol services will be provided as OSGi bundles and should
> >> be plugged into ApacheDS dynamically. Because we don't have any
> >> embedded JNDI provider, LDAP protocol connection to loopback device
> >> will be used temporarilly.
>
> Hmmm I don't know about this. I think these guys can use the bridge and
> not have to go through the wire which would slow things down. Trustin
> was this lookback thing related to conversations we had in the past over
> ClassLoader issues and instances of the DirectoryServer? My memory is a
> bit hazy here.
IIRC, the ClassLoader issue and the OSGi migration are not related to each
other. I am talking about loopback TCP/IP communication. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:
> Trustin Lee a écrit :
>
>> Hi,
>>
>> Yes, I know this is a very radical approach, but I think this is
>> mandatory to accelerate our development.
>>
>> JNDI is an abstraction API for all kinds of directory services. LDAP
>> is a part of the list. From my experience, JNDI is not really the
>> best API to access an LDAP server. It can access the LDAP server, but
>> not gives us the best convenience from the viewpoint of the API user.
>> And we're using JNDI Name and DirContext interface to program our
>> internals. That's why we need a new API which perfectly fits into
>> LDAP. By doing that, we can program our interceptors and partitions
>> more easily mapped into LDAP operations rather than JNDI operations.
>
> The beauty of LDAP is that you can work with JNDI, Novelm API (jldap :
> http://www.openldap.org/jldap/) or even our own new API. We can keep the
> JNDI approach, because it's common to many application, and dropping it
> would be seen a little bit questionnable by our current users (I'm
> thinking of Geronimo)
>
>>
>> Of course, this change will take away the advantage of embedded mode
>> unless we spend more time to create a bridge between JNDI and our
>> API. But I think our primary concern is to provide a high quality
>> LDAP server whose internals are highly optimized for LDAP, not to
>> provide a JNDI embeddable LDAP server.
>
> We can provide both, in my opinion. JNDI is an interface...
>
Yeah I think we can provide both. Trustin was referring to a bridge
before and I agree.
The LDAP protocol provider would not use this bridge however. It would
use the LDAP specific API instead.
Other protocol providers that back their information within ApacheDS can
use the JNDI bridge.
>> Here's my suggestion:
>>
>> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1
>> to LDAP operations rather than JNDI operations.
>> * Core/ServerDirContext will be removed in this process.
>> * ServerStartupConfiguration should be merged into
>> StartupConfiguration and embedded mode should go away because we can
>> just disable the LDAP service later when OSGi is adopted.
>
> This is a possible move. Alex ?
Yeah I think can. What I recommend is small refactorings to slowly
bring us towards this or a similar goal. First we can decouple the JNDI
provider from the core. We can also decouple the configuration from the
core as well. By doing these things we will arrive at a better
structure and then will have better vision to figure out what needs to
be done next.
>>
>> 2. Migrate to OSGi framework
>> * All protocol services will be provided as OSGi bundles and should
>> be plugged into ApacheDS dynamically. Because we don't have any
>> embedded JNDI provider, LDAP protocol connection to loopback device
>> will be used temporarilly.
Hmmm I don't know about this. I think these guys can use the bridge and
not have to go through the wire which would slow things down. Trustin
was this lookback thing related to conversations we had in the past over
ClassLoader issues and instances of the DirectoryServer? My memory is a
bit hazy here.
>> 3. Support an embedded mode
>> * But who will ever use DNS or other services without LDAP
>> provider? The only advantage of the embedded access is the small
>> performance gain which might not be that important in distributed
>> directory services.
Good point. At this point I'm not exactly sure on any one direction.
Sorry but I have not had a chance to think about 1.1 fully yet. I've
been so focused on making sure we get this 1.0 out the door.
Alex
RE: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Gregg Freeman <GF...@seagullsoftware.com>.
> 3. Support an embedded mode
> * But who will ever use DNS or other services
without LDAP
> provider? The only advantage of the embedded access
is the small
> performance gain which might not be that important in
distributed
> directory services.
We really need this embeded mode. Many application will
benefit from it
: no more complicated firwall configuration to let LDAP
go through, no
more need to start the server before the application,
etc. It's a little
bit like Jetty. Sometime, it's better to embrace
everything in a simple
application.
Well, if two run in the same machine, the client will use a
loopback device to connect to the server, so firewall shouldn't be that
much a problem. I agree with you that embedded mode is useful, but we
can still run both in the same VM and use loopback device. Direct
method invocation can come later.
+1 for "embedded" (whatever that is). We're using it just as we would
an embedded Jetty or Tomcat - we want to start it in the same JVM as our
application and have the application have control over the LDAP server's
lifecycle. Direct method invocation isn't nearly as important as
lifecycle control, in our situation. So, I guess it depends on what you
call "embedded". :) In our case it means tightly integrated, but not
invisible.
Best Regards,
Gregg
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Trustin Lee <tr...@gmail.com>.
On 9/4/06, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Trustin Lee a écrit :
>
> > Hi,
> >
> > Yes, I know this is a very radical approach, but I think this is
> > mandatory to accelerate our development.
> >
> > JNDI is an abstraction API for all kinds of directory services. LDAP
> > is a part of the list. From my experience, JNDI is not really the
> > best API to access an LDAP server. It can access the LDAP server, but
> > not gives us the best convenience from the viewpoint of the API user.
> > And we're using JNDI Name and DirContext interface to program our
> > internals. That's why we need a new API which perfectly fits into
> > LDAP. By doing that, we can program our interceptors and partitions
> > more easily mapped into LDAP operations rather than JNDI operations.
>
> The beauty of LDAP is that you can work with JNDI, Novelm API (jldap :
> http://www.openldap.org/jldap/) or even our own new API. We can keep the
> JNDI approach, because it's common to many application, and dropping it
> would be seen a little bit questionnable by our current users (I'm
> thinking of Geronimo)
My idea is not just dropping but probiding a bridge (JNDI provider which
wraps our own API). So it should be OK.
> Of course, this change will take away the advantage of embedded mode
> > unless we spend more time to create a bridge between JNDI and our
> > API. But I think our primary concern is to provide a high quality
> > LDAP server whose internals are highly optimized for LDAP, not to
> > provide a JNDI embeddable LDAP server.
>
> We can provide both, in my opinion. JNDI is an interface...
Exactly. I am just talking about the priority.
> 3. Support an embedded mode
> > * But who will ever use DNS or other services without LDAP
> > provider? The only advantage of the embedded access is the small
> > performance gain which might not be that important in distributed
> > directory services.
>
> We really need this embeded mode. Many application will benefit from it
> : no more complicated firwall configuration to let LDAP go through, no
> more need to start the server before the application, etc. It's a little
> bit like Jetty. Sometime, it's better to embrace everything in a simple
> application.
Well, if two run in the same machine, the client will use a loopback device
to connect to the server, so firewall shouldn't be that much a problem. I
agree with you that embedded mode is useful, but we can still run both in
the same VM and use loopback device. Direct method invocation can come
later.
> Was this too radical? :)
>
> No, not too much ... I thought you would propose to switch to C# (I
> would called it a revolution then :)
Yeah Glasgow team ported MINA to C# a little bit, so we can do that when
it's ready. ;)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Emmanuel Lecharny <el...@gmail.com>.
Trustin Lee a écrit :
> Hi,
>
> Yes, I know this is a very radical approach, but I think this is
> mandatory to accelerate our development.
>
> JNDI is an abstraction API for all kinds of directory services. LDAP
> is a part of the list. From my experience, JNDI is not really the
> best API to access an LDAP server. It can access the LDAP server, but
> not gives us the best convenience from the viewpoint of the API user.
> And we're using JNDI Name and DirContext interface to program our
> internals. That's why we need a new API which perfectly fits into
> LDAP. By doing that, we can program our interceptors and partitions
> more easily mapped into LDAP operations rather than JNDI operations.
The beauty of LDAP is that you can work with JNDI, Novelm API (jldap :
http://www.openldap.org/jldap/) or even our own new API. We can keep the
JNDI approach, because it's common to many application, and dropping it
would be seen a little bit questionnable by our current users (I'm
thinking of Geronimo)
>
> Of course, this change will take away the advantage of embedded mode
> unless we spend more time to create a bridge between JNDI and our
> API. But I think our primary concern is to provide a high quality
> LDAP server whose internals are highly optimized for LDAP, not to
> provide a JNDI embeddable LDAP server.
We can provide both, in my opinion. JNDI is an interface...
>
> Here's my suggestion:
>
> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1
> to LDAP operations rather than JNDI operations.
> * Core/ServerDirContext will be removed in this process.
> * ServerStartupConfiguration should be merged into
> StartupConfiguration and embedded mode should go away because we can
> just disable the LDAP service later when OSGi is adopted.
This is a possible move. Alex ?
>
> 2. Migrate to OSGi framework
> * All protocol services will be provided as OSGi bundles and should
> be plugged into ApacheDS dynamically. Because we don't have any
> embedded JNDI provider, LDAP protocol connection to loopback device
> will be used temporarilly.
+1 for moving to OSGI. This is a must.
>
> 3. Support an embedded mode
> * But who will ever use DNS or other services without LDAP
> provider? The only advantage of the embedded access is the small
> performance gain which might not be that important in distributed
> directory services.
We really need this embeded mode. Many application will benefit from it
: no more complicated firwall configuration to let LDAP go through, no
more need to start the server before the application, etc. It's a little
bit like Jetty. Sometime, it's better to embrace everything in a simple
application.
>
> Was this too radical? :)
No, not too much ... I thought you would propose to switch to C# (I
would called it a revolution then :)
Emmanuel
Re: [ADS 2.0] Detach JNDI from ApacheDS
Posted by Ersin Er <er...@gmail.com>.
On 9/4/06, Trustin Lee <tr...@gmail.com> wrote:
> Hi,
>
> Yes, I know this is a very radical approach, but I think this is mandatory
> to accelerate our development.
>
> JNDI is an abstraction API for all kinds of directory services. LDAP is a
> part of the list. From my experience, JNDI is not really the best API to
> access an LDAP server. It can access the LDAP server, but not gives us the
> best convenience from the viewpoint of the API user. And we're using JNDI
> Name and DirContext interface to program our internals. That's why we need
> a new API which perfectly fits into LDAP. By doing that, we can program our
> interceptors and partitions more easily mapped into LDAP operations rather
> than JNDI operations.
>
> Of course, this change will take away the advantage of embedded mode unless
> we spend more time to create a bridge between JNDI and our API. But I think
> our primary concern is to provide a high quality LDAP server whose internals
> are highly optimized for LDAP, not to provide a JNDI embeddable LDAP server.
>
> Here's my suggestion:
>
> 1. Change the DirectoryPartition and Interceptor interface to fit 1:1 to
> LDAP operations rather than JNDI operations.
> * Core/ServerDirContext will be removed in this process.
> * ServerStartupConfiguration should be merged into StartupConfiguration
> and embedded mode should go away because we can just disable the LDAP
> service later when OSGi is adopted.
I completely agree on 1:1 fit. I also prefer pure LDAP operations to
optimized operations (like the modify operation which takes a single
ModificationItem instead of an array, or lots of kinds of search
operations). Those optimized operations make services writing hard and
causes lots of repeated code (and also untested code because we rarely
use some of them).
> 2. Migrate to OSGi framework
> * All protocol services will be provided as OSGi bundles and should be
> plugged into ApacheDS dynamically. Because we don't have any embedded JNDI
> provider, LDAP protocol connection to loopback device will be used
> temporarilly.
>
> 3. Support an embedded mode
> * But who will ever use DNS or other services without LDAP provider? The
> only advantage of the embedded access is the small performance gain which
> might not be that important in distributed directory services.
>
> Was this too radical? :)
No of course. This is something we discussed several times. Alex had
recently started a thread about getting rid of JNDI.
I think we also need to provide a clinet API again as a 1:1 with LDAP.
I am not sure about how this might overlap with the server API but I
think they will somehow differ.
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
--
Ersin