[ApacheDS Webapp or not Webapp] was [ApacheDS] Embedded http service part2

[Emmanuel Lecharny <el...@apache.org>]

Ole Ersoy a écrit :

> OK - Now I'm getting all mixed up
> about whether I should change the heading or not.
>
> I'm going to trust Emmanuel's judgement, and just leave it.

Sorry, I didn't read Alex comment, and he is right. So I changed the 
subject :)

>
> Emmanuel Lecharny wrote:
>
>> Ole Ersoy a écrit :
>
>
> SNIPPING the SNIP
>
>> I see at least one obvious use-case : embedding ADS allow you to 
>> avoid network costs because ADS will be adressed directly. This will 
>> allow the app to use the full power of ADS, at full speed, which is 
>> really a good use case. But there are many more...
>
>
> Hmmm - So I assume then that
> that even though the webapp
> and ADS are running on the same
> host the webapp that runs with
> ADS embedded will run faster than the
> one connecting to ApacheDS via JDNI?
>
> I also assume that we're talking a significant
> improvement like 5 to 10 % faster.

I would say 5 to 10 times faster.

>
>>
>> But this is the common case ! I don't really see exactly what you are 
>> thinking of. What I see is that you have only two cases :
>> - ADS embedded
>> - ADS beside the server, but then it is seen as a standard LDAP 
>> server, running in its own JVM. Nothing new under the sun (tm), so 
>> far...
>
>
> I'm thinking ADS beside the server running the webapp.
> So the webapp connects to ADS via JNDI.
> But if there is performance to be gained from
> embedding ADS within the webapp then that of coarse is very valid.

Yes, this is the perfect scenario. Also consider people who don't want 
to bother with an external LDAP server installation.

>> Do you have something else in mind ?
>
>
>
> The only thing I had in mind was to separate
> the application layer from the data store,
> through an integration layer so as to maintain
> modularity and make each piece appeal to as many
> people as possible.

Usually, when you have a webapp and you need to address a LDAP server, 
it is a separated LDAP server, ADS is bringing this new possibility to 
embed it. I don't know about another LDAP server which allow you to do 
so (except OpenDS, AFAIK). So the scenario you are thinking of is the 
scenario everybody use.

>
> For low volume applications like administration, etc.
> this makes sense because more people can use the webapp,
> thus more people will be interested in improving it,
> and performance is a fairly minor consideration.
>
> On the other hand if the webapp is a phone directory
> and gazillions of connections are made per second then
> maybe embedding is a good thing.  This is why I asked about
> the percentage gain in performance via embedding vs.
> JNDI on the same host.

It is huge. I dind't measured it yet, ut from the profiling session I 
have done, the ASN.1 codeing/decoding + network layer is really costing 
a lot.

>
> The main thing I was trying to high light was that there
> could be a developer interest cost to embedding,
> so choosing the right set of use cases is important.

The good thing with ADS is that embedding cost almost nothing, as you 
communicate with ADS using exactly the same API as the one you will use 
to communicate with a remote LDAP server : JNDI. In fact, this is 
totally transparent, except the initialization.

Emmanuel

Re: [ApacheDS Webapp or not Webapp] was [ApacheDS] Embedded http service part2

[Ole Ersoy <ol...@gmail.com>]

Emmanuel Lecharny wrote:
SNIP


>>
>>
>> Hmmm - So I assume then that
>> that even though the webapp
>> and ADS are running on the same
>> host the webapp that runs with
>> ADS embedded will run faster than the
>> one connecting to ApacheDS via JDNI?
>>
>> I also assume that we're talking a significant
>> improvement like 5 to 10 % faster.
> 
> I would say 5 to 10 times faster.


WHoahhhh!!!  Smoookinnn!!
OK - Lights are starting to
turn on now :-)

SNIP


  > Yes, this is the perfect scenario. Also consider people who don't want
> to bother with an external LDAP server installation.

Good point as well.

> 
>>> Do you have something else in mind ?

>> The only thing I had in mind was to separate
>> the application layer from the data store,
>> through an integration layer so as to maintain
>> modularity and make each piece appeal to as many
>> people as possible.
> 
> Usually, when you have a webapp and you need to address a LDAP server, 
> it is a separated LDAP server, ADS is bringing this new possibility to 
> embed it. I don't know about another LDAP server which allow you to do 
> so (except OpenDS, AFAIK). So the scenario you are thinking of is the 
> scenario everybody use.
> 
>>
>> For low volume applications like administration, etc.
>> this makes sense because more people can use the webapp,
>> thus more people will be interested in improving it,
>> and performance is a fairly minor consideration.
>>
>> On the other hand if the webapp is a phone directory
>> and gazillions of connections are made per second then
>> maybe embedding is a good thing.  This is why I asked about
>> the percentage gain in performance via embedding vs.
>> JNDI on the same host.
> 
> It is huge. I dind't measured it yet, ut from the profiling session I 
> have done, the ASN.1 codeing/decoding + network layer is really costing 
> a lot.

Wow - OK - It all makes a lot more sense now :-)

> The good thing with ADS is that embedding cost almost nothing, as you 
> communicate with ADS using exactly the same API as the one you will use 
> to communicate with a remote LDAP server : JNDI. In fact, this is 
> totally transparent, except the initialization.

Cool - so it sounds like it's easy to give all developers the best of
both worlds.  Maybe even have thin layer with a a little toggle
for turning embedded ADS on and off, making the webapp appeal
to all developers.

I'm getting a lot more excited.  :-)

Thanks for all the clarification Emmmanuel.
I'm definitely a lot more excited about
the the embedding scenario
now.  Let me crunch this DAS out, and then once that's done I'll try
to do a thin embedding layer with the first DAS sample application.

Cheers,
- Ole