geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: [Ldapd-devel] LDAP Support in Geronimo
Date Tue, 12 Aug 2003 06:23:31 GMT
Richard,

We would be interested in clocking this thing as well.  However we are not
trying to optimize at the moment.  We are trying to stabilize the
architecture first keeping it as flexible as possible.  We will get to a
point where performance tuning and these statistics will be the primary
focus.  Intuitively though the embedded configuration cooks using the jdbm
based backend - must faster than doing remote work on any LDAP server I've
seen but that's expected.

How long do you think there is before a beta release of Geronimo?  We can
make preparations to meet somewhere in terms of the development timeline.

LDAPd's official release is some time out - can't even predict it at the
moment.  We're doing another alpha soon though with a major revamp which has
the code name 'Eve', a play on M$'s ADAM ;-). 

Yes I agree that the security subsystem would benefit greatly if built on
top of an LDAP server.  I also agree that the distributed nature of LDAP,
with LDAP replication, masters and slaves provides some very convenient
features for a J2EE container that go beyond just configuration management.
I'm sure you have looked at what BEA has done with Weblogic 7 and up with
the embedded LDAP server.  What do you think of this move?

In terms of Avalon, LDAPd uses the principals and interfaces in Avalon.
It's extremely modular thanks to Avalon.  This does not mean that it needs
to run within a full fledged container like phoenix.  Its components can
easily be glued together using Excalibur components and toolkit code.  There
really is no need for Geronimo to care about the use of Avalon.  Avalon
framework is very important overall to any server side application I
believe.  Things like SoC and IC have helped use immeasurably.  So there
really is no rift if the server embedding LDAPd is not based on Avalon. As
long as the server uses JNDI to operate on the directory all is well.

In terms of surviving the incubator it may not make it at all, but that does
not mean we can't write code.  After all that's what makes us happy at the
end of the day right.  I thought about it before making the decision.  The
primary goal was to attract more Apache folks to it.  I'm looking for more
expertise and interest in making LDAPd successful while sharing it with
everyone.  At the end of the day I want a free LDAP server - iPlanet (SUN
ONE) is just too damn expensive and AD/AM is not an option.  The worst thing
is that it does not make it through the incubator and it sits on sourceforge
for an eternity.  That would stink but what can we do but give it a shot.
So we'll try our best to make it a success.

Thanks for your input and hope to talk some more.  Feel free to give us
input as to what aspects of LDAPd we should focus on improving to
accommodate its use in an embedded configuration.

Sincerely,
Alex Karasulu

-----Original Message-----
From: ldapd-devel-admin@lists.sourceforge.net
[mailto:ldapd-devel-admin@lists.sourceforge.net] On Behalf Of Richard
Monson-Haefel
Sent: Monday, August 11, 2003 4:59 AM
To: geronimo-dev@incubator.apache.org
Cc: 'Avalon Developers List'; ldapd-devel@lists.sourceforge.net
Subject: [Ldapd-devel] LDAP Support in Geronimo

It would be interesting to find out how fast LDAPd's embedded lookup
facility
is. If its fast, it would make sense to eventually use it for the JNDI
Environment Naming Context.  However, I still feel that having something
quick
and lightweight now - a stopgap if you will - is better than waiting for
LDAPd
to reach its first release.

That said, embedding a LDAP server into Geronimo would provide a solution
for a
variety of problems, least of which is the JNDI ENC. It would be the nexus
of an
authentication/authorization system and security domain administration. In
addition, it can be used for configuration and would make an excellent
service
in its own right -- especially if its accessible intraVM as well as interVM.
It
could also be used as the CORBA Naming service, support for which is
required by
the EJB specification.

Personally, I hope that LDAPd is accepted into the Incubator so that we can
plan
on incorporating into the Geronimo project (provided it works and survives
the
incubator process).

Whether or not we end up using LDAPd, Geronimo should be designed so that
LDAP
servers of any make are plugable at some level. This would enable
organizations
to leverage existing LDAP installations.  If LDAP is plugable (is that a
word?)
it should be a simple to configure and deploy -- avoiding overly complex
bindings is important, IMO.

In the LDAP area I suggest we adopt a dual strategy of supporting arbitrary
LDAP
installations via remote communications (LDAP protocol) as well as an
embedded
solution (i.e. embedded LDAPd). If we are serious about LDAPd, perhaps those
folks could help with both strategies.

The one thing I'm not sure about i the Avalon coupling. If LDAPd is based on
Avalon would it still work as an imbedable service if Geronimo doesn't adopt
Avalon? It seems likely, but I think its worth asking anyway.

Richard
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition  (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com


Alex Karasulu wrote:

> BTW, the LDAPd team is currently working on submitting their incubator
> request as well.  LDAPd is based on Avalon and is an LDAPv3 server with a
> SEDA based architecture.  It is based almost entirely on Apache software.
>
> We started the LDAPd (embeddable) server project to eventually enable open
> source J2EE servers like JBoss, and Servlet Containers like Tomcat with an
> embedded LDAP server for configuration management.  The project was
> triggered by the introduction of an LDAPv2 server into Weblogic Server by
> BEA.  We wanted JBoss and Tomcat to be able to compete with BEA in this
> aspect - especially since BEA WLS uses LDAP to easily manage cluster
> configurations amongst other things.
>
> The role of a directory is critical to any distributed component model and
> goes beyond the aspect of configuration management.  Take web services for
> example:  the UDDI folks are working with the IETF to establish a schema
> model in LDAP for UDDI, here's the draft submission
>
http://www.globecom.net/ietf/draft/draft-bergeson-uddi-ldap-schema-01.html.
> Likewise .NET is leveraging AD and ADAM to do the same for both web
services
> and COM objects.  When systems are composed of hundreds or thousands of
> distributed components (J2EE or .NET), these components need to find one
> another.  We at the LDAPd Group feel that LDAP is a critical technology in
> enabling these distributed component architectures, which allows them to
be
> orchestrated regardless of distribution.  Our existence is based on this
> premise.  We have come along way and are about to provide these functional
> services in a standard fashion while leveraging JNDI.
>
> LDAPd is based on Avalon and has a very unique relationship with the JNDI.
> Its front end which serves requests over the line protocol simply uses the
> server-side JNDI provider to access LDAP entries as Attributes.  The
server
> side provider wraps the backend apparatus which attaches naming system
> partitions to one common tree from multiple databases, or backends as we
> call them.  Embedding LDAPd with the front end or just its backend
apparatus
> will be as easy as using JNDI to get a context through the server side
JNDI
> provider.  This way under an embedded configuration, the protocol is
> bypassed and embedding servers simply access the backend apparatus
directly
> via JNDI. We have centered around this design specifically to enable
> applications that already use JNDI LDAP to continue to do so but now under
> an embedded configuration.  The change should only be a property setting
for
> the Context.INITIAL_CONTEXT_FACTORY property.
>
> As with any open source effort we question our motives and our direction
> frequently and welcome commentary from a community.  This is what has made
> several Apache projects so strong and what we believe will make LDAPd
> strong.  What thoughts if any does the community have on this hypothesis
and
> LDAPd's fundamental reason for being?
>
> Also we have come to a point where LDAPd has become bigger than our group
> alone.  We are continuously looking for contributions and guidance to make
> the right decisions.  From several conversations with Apache members we
have
> begun to realize that LDAPd would make a good addition to the suite of
> flagship servers generously offered by the ASF.  Hence we are now taking
> formal steps toward offering LDAPd to the Apache community via the
> Incubator.  Together we can merge the protocols that glue the Internet
> together and offer world class software freely in the Apache tradition.
>
> Sincerely,
> Alex Karasulu
>



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Ldapd-devel mailing list
Ldapd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ldapd-devel



Mime
View raw message