You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2003/08/10 17:51:47 UTC
RE: Avalon + Geronimo = Another (Last?) Chance
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
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@apache.org]
Sent: Sunday, August 10, 2003 8:30 AM
To: Avalon Developers List
Subject: Re: Avalon + Geronimo = Another (Last?) Chance
Anton Tagunov wrote:
>Hello All!
>
>FA> new "Geronimo" project -- Apache's J2EE implementation
>
>They have been speaking about using OpenORB and that thing
>is already based on Avalon to the best of my knowledge.
>
Yep. In fact a lot of the features in Merlin have come out of
requirements in dealing with ORB based services - including things like
composite components, dynamic service publication, etc.
>This might give as additional $0.02 chances to push
>through :)
>
>Stephen, how deep have you been involved in OpenORB?
>
Deep. All of the OpenORB team have already done all of the paperwork to
bring things over to Apache. I'll need to followup with Greg Stien on
where things are on the license side of things.
Stephen.
>
>They just can not do without a CORBA transport!
>
>-Anton
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Ldapd-devel] LDAP Support in Geronimo
Posted by "Noel J. Bergman" <no...@devtech.com>.
Richard,
> Actually we probably won't be all that far by [October],
> but the earlier we have the LDAP impl the better.
They have a working one now, but they want to substantially re-do it. AIUI,
right now you could download their early release, and run it against the
JNDI LDAP provider.
--- Noel
Re: [Ldapd-devel] LDAP Support in Geronimo
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
That would be great ... Actually we probably won't be all that far by than,
but the earlier we have the LDAP impl the better.
On 8/14/03 6:27 PM, "Alex Karasulu" <ao...@bellsouth.net> wrote:
> After looking at our roadmap I think we can be useful to you by mid October
> where we have the new JNDI provider and backend architecture in place and
> thoroughly tested.
>
> We'll try to have an interim release using an older backend architecture
> however but I would rather sacrifice this to get you the polished product in
> its most efficient and usable form.
>
> Alex
>
> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: Tuesday, August 12, 2003 2:43 AM
> To: geronimo-dev@incubator.apache.org
> Cc: ldapd-devel@lists.sourceforge.net; dev@avalon.apache.org
> Subject: Re: [Ldapd-devel] LDAP Support in Geronimo
>
>
> On Tuesday, August 12, 2003, at 07:23 am, Alex Karasulu wrote:
>
>> How long do you think there is before a beta release of Geronimo?
>
> Not sure yet. Geronimo is useful for deploying MBeans already; dunno
> when we should do a beta release though - its probably still too soon.
>
>
>> 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 ;-).
>
> Though doing some alpha releases of LDAPd would be most useful in
> allowing us to start integrating LDAPd into Geronimo sooner rather than
> later.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Richard Monson-Haefel
Co-Founder\Developer, Apache Geronimo
Author of:
J2EE Web Services (AW 2003)
Enterprise JavaBeans, 4ed (O'Reilly 2004)
Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
RE: [Ldapd-devel] LDAP Support in Geronimo
Posted by Alex Karasulu <ao...@bellsouth.net>.
After looking at our roadmap I think we can be useful to you by mid October
where we have the new JNDI provider and backend architecture in place and
thoroughly tested.
We'll try to have an interim release using an older backend architecture
however but I would rather sacrifice this to get you the polished product in
its most efficient and usable form.
Alex
-----Original Message-----
From: James Strachan [mailto:james_strachan@yahoo.co.uk]
Sent: Tuesday, August 12, 2003 2:43 AM
To: geronimo-dev@incubator.apache.org
Cc: ldapd-devel@lists.sourceforge.net; dev@avalon.apache.org
Subject: Re: [Ldapd-devel] LDAP Support in Geronimo
On Tuesday, August 12, 2003, at 07:23 am, Alex Karasulu wrote:
> How long do you think there is before a beta release of Geronimo?
Not sure yet. Geronimo is useful for deploying MBeans already; dunno
when we should do a beta release though - its probably still too soon.
> 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 ;-).
Though doing some alpha releases of LDAPd would be most useful in
allowing us to start integrating LDAPd into Geronimo sooner rather than
later.
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [cvs] how to get the code (was Re: [Ldapd-devel] LDAP Support in Geronimo)
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 01:12 pm, Jacek Laskowski wrote:
> James Strachan wrote:
>> On Tuesday, August 12, 2003, at 09:03 am, James deGraft-Johnson
>> wrote:
>>> HI,
>>>
>>> How do I get the existing code base from CVS?
>> http://www.apache.org/~jstrachan/geronimo/cvs-usage.html
>> http://jakarta.apache.org/site/cvsindex.html
>> I don't know tortoise-cvs though the following should work from the
>> command line...
>> cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
>> password: anoncvs
>
> Hi,
>
> It doesn't pertain to Geronimo per se, but I'm wondering why every
> docs about cvs (at least at Apache site) doesn't mention that the
> password may be specified on the command line ? Whouldn't it be
> simpler as the following cvs login command doesn't ask for the
> password, thus one doesn't need to type in the password over and over
> again ?
>
> cvs -d :pserver:anoncvs:anoncvs@cvs.apache.org:/home/cvspublic login
>
> Unless I'm mistaken, performing the following command is quite enough
> to check out the sources (no need to cvs login):
You need to login to the above repository once. Once you've logged in
you don't need to do it again (as it stores the login in your home
directory). So once you've logged in you can checkout any apache
modules.
>
> cvs -d :pserver:anoncvs:anoncvs@cvs.apache.org:/home/cvspublic -q
> checkout incubator-geronimo
James
-------
http://radio.weblogs.com/0112098/
Re: [cvs] how to get the code (was Re: [Ldapd-devel] LDAP Support
in Geronimo)
Posted by Jacek Laskowski <ja...@hp.com>.
James Strachan wrote:
>
> On Tuesday, August 12, 2003, at 09:03 am, James deGraft-Johnson wrote:
>
>> HI,
>>
>> How do I get the existing code base from CVS?
>
>
> http://www.apache.org/~jstrachan/geronimo/cvs-usage.html
> http://jakarta.apache.org/site/cvsindex.html
>
> I don't know tortoise-cvs though the following should work from the
> command line...
>
> cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
> password: anoncvs
Hi,
It doesn't pertain to Geronimo per se, but I'm wondering why every docs
about cvs (at least at Apache site) doesn't mention that the password
may be specified on the command line ? Whouldn't it be simpler as the
following cvs login command doesn't ask for the password, thus one
doesn't need to type in the password over and over again ?
cvs -d :pserver:anoncvs:anoncvs@cvs.apache.org:/home/cvspublic login
Unless I'm mistaken, performing the following command is quite enough to
check out the sources (no need to cvs login):
cvs -d :pserver:anoncvs:anoncvs@cvs.apache.org:/home/cvspublic -q
checkout incubator-geronimo
> James
-Jacek
RE: [cvs] how to get the code
Posted by James deGraft-Johnson <jd...@digaman.com>.
Hi,
I figured it out. The example I copied duplicated the repository name that
is why it was failing.
Thanks.
James deGraft-Johnson
3419 Hampton Hollow Drive, Apt G,
Silver Spring MD 20904.
Tel: (301) 847-1694
Fax: (301) 847-8025
Mobile: (240) 475-1444 (jdegraft@verizon-uc.com)
-----Original Message-----
From: James Strachan [mailto:james_strachan@yahoo.co.uk]
Sent: Tuesday, August 12, 2003 4:08 AM
To: geronimo-dev@incubator.apache.org
Subject: [cvs] how to get the code (was Re: [Ldapd-devel] LDAP Support in
Geronimo)
On Tuesday, August 12, 2003, at 09:03 am, James deGraft-Johnson wrote:
> HI,
>
> How do I get the existing code base from CVS?
http://www.apache.org/~jstrachan/geronimo/cvs-usage.html
http://jakarta.apache.org/site/cvsindex.html
I don't know tortoise-cvs though the following should work from the
command line...
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
password: anoncvs
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic checkout
incubator-geronimo
James
-------
http://radio.weblogs.com/0112098/
[cvs] how to get the code (was Re: [Ldapd-devel] LDAP Support in Geronimo)
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 09:03 am, James deGraft-Johnson wrote:
> HI,
>
> How do I get the existing code base from CVS?
http://www.apache.org/~jstrachan/geronimo/cvs-usage.html
http://jakarta.apache.org/site/cvsindex.html
I don't know tortoise-cvs though the following should work from the
command line...
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
password: anoncvs
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic checkout
incubator-geronimo
James
-------
http://radio.weblogs.com/0112098/
RE: [Ldapd-devel] LDAP Support in Geronimo
Posted by James deGraft-Johnson <jd...@digaman.com>.
HI,
How do I get the existing code base from CVS?
I have downloaded tortoise-cvs, and I am trying to download module
incubator-geronimo however it seems to be unhappy about the password.
(user:anoncvs)
James deGraft-Johnson
3419 Hampton Hollow Drive, Apt G,
Silver Spring MD 20904.
Tel: (301) 847-1694
Fax: (301) 847-8025
Mobile: (240) 475-1444 (jdegraft@verizon-uc.com)
-----Original Message-----
From: James Strachan [mailto:james_strachan@yahoo.co.uk]
Sent: Tuesday, August 12, 2003 3:43 AM
To: geronimo-dev@incubator.apache.org
Cc: ldapd-devel@lists.sourceforge.net; dev@avalon.apache.org
Subject: Re: [Ldapd-devel] LDAP Support in Geronimo
On Tuesday, August 12, 2003, at 07:23 am, Alex Karasulu wrote:
> How long do you think there is before a beta release of Geronimo?
Not sure yet. Geronimo is useful for deploying MBeans already; dunno
when we should do a beta release though - its probably still too soon.
> 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 ;-).
Though doing some alpha releases of LDAPd would be most useful in
allowing us to start integrating LDAPd into Geronimo sooner rather than
later.
James
-------
http://radio.weblogs.com/0112098/
Re: [Ldapd-devel] LDAP Support in Geronimo
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 07:23 am, Alex Karasulu wrote:
> How long do you think there is before a beta release of Geronimo?
Not sure yet. Geronimo is useful for deploying MBeans already; dunno
when we should do a beta release though - its probably still too soon.
> 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 ;-).
Though doing some alpha releases of LDAPd would be most useful in
allowing us to start integrating LDAPd into Geronimo sooner rather than
later.
James
-------
http://radio.weblogs.com/0112098/
Re: [Ldapd-devel] LDAP Support in Geronimo
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 07:23 am, Alex Karasulu wrote:
> How long do you think there is before a beta release of Geronimo?
Not sure yet. Geronimo is useful for deploying MBeans already; dunno
when we should do a beta release though - its probably still too soon.
> 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 ;-).
Though doing some alpha releases of LDAPd would be most useful in
allowing us to start integrating LDAPd into Geronimo sooner rather than
later.
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [Ldapd-devel] LDAP Support in Geronimo
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
RE: [Ldapd-devel] LDAP Support in Geronimo
Posted by Alex Karasulu <ao...@bellsouth.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Volunteers - Topics
Posted by Luis Avila <la...@axer.cl>.
Done.... i hope it's useful....
Regards
--
Luis Avila
__________________________
Technology Project Manager
Axer Systems S.A.
Román Díaz 205 Of. 503
Fono: 56-2-235 2747
http://www.axer.cl
On Tue, 2003-08-12 at 10:16, James Strachan wrote:
> Good idea - go for it Luis. Just add pages :)
>
>
> On Tuesday, August 12, 2003, at 03:12 pm, Luis Avila wrote:
>
> > Here are a brief list of people involved in topics about the project.
> > It's only with a very fast revision of the mails so surely is
> > incomplete, but is a starting point.
> >
> >
> > I propose to make one page in the wiki site with this information, so
> > we
> > can choose some team or to start one in some topic not covered.
> >
> >
> > Regards
> >
> >
> > Persistence:
> >
> > dain
> > Jeremy Boynes
> > Michael Turilin
> >
> > JNDI
> >
> > Richard Monson-Haefel
> > Henri Yandell
> > Stefano Passiglia
> > Alex Blewitt
> >
> > WS
> >
> > Richard Monson-Haefel
> > Alberto Rodriguez Galdo
> >
> > Mail
> >
> > Alex Blewitt
> >
> > User Friendliness
> >
> > Erin Mulder
> > Chris Opacki
> >
> > Clustering
> >
> > Michael Remijan
> >
> > Security
> >
> > Prashant Bhatt
> >
> > Tests
> >
> >
> > --
> > Luis Avila
> > __________________________
> > Technology Project Manager
> > Axer Systems S.A.
> > Román Díaz 205 Of. 503
> > Fono: 56-2-235 2747
> > http://www.axer.cl
> >
> >
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: Volunteers - Topics
Posted by James Strachan <ja...@yahoo.co.uk>.
Good idea - go for it Luis. Just add pages :)
On Tuesday, August 12, 2003, at 03:12 pm, Luis Avila wrote:
> Here are a brief list of people involved in topics about the project.
> It's only with a very fast revision of the mails so surely is
> incomplete, but is a starting point.
>
>
> I propose to make one page in the wiki site with this information, so
> we
> can choose some team or to start one in some topic not covered.
>
>
> Regards
>
>
> Persistence:
>
> dain
> Jeremy Boynes
> Michael Turilin
>
> JNDI
>
> Richard Monson-Haefel
> Henri Yandell
> Stefano Passiglia
> Alex Blewitt
>
> WS
>
> Richard Monson-Haefel
> Alberto Rodriguez Galdo
>
> Mail
>
> Alex Blewitt
>
> User Friendliness
>
> Erin Mulder
> Chris Opacki
>
> Clustering
>
> Michael Remijan
>
> Security
>
> Prashant Bhatt
>
> Tests
>
>
> --
> Luis Avila
> __________________________
> Technology Project Manager
> Axer Systems S.A.
> Román Díaz 205 Of. 503
> Fono: 56-2-235 2747
> http://www.axer.cl
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: Volunteers - Topics
Posted by Tim Urberg <ti...@yahoo.com>.
Please add Jacek Laskowski and I to the test team. I'd also like to take part
in the User Friendliness team.
Thanks,
Tim Urberg
OpenEJB Developer
--- Luis Avila <la...@axer.cl> wrote:
> Here are a brief list of people involved in topics about the project.
> It's only with a very fast revision of the mails so surely is
> incomplete, but is a starting point.
>
>
> I propose to make one page in the wiki site with this information, so we
> can choose some team or to start one in some topic not covered.
>
>
> Regards
>
>
> Persistence:
>
> dain
> Jeremy Boynes
> Michael Turilin
>
> JNDI
>
> Richard Monson-Haefel
> Henri Yandell
> Stefano Passiglia
> Alex Blewitt
>
> WS
>
> Richard Monson-Haefel
> Alberto Rodriguez Galdo
>
> Mail
>
> Alex Blewitt
>
> User Friendliness
>
> Erin Mulder
> Chris Opacki
>
> Clustering
>
> Michael Remijan
>
> Security
>
> Prashant Bhatt
>
> Tests
>
>
> --
> Luis Avila
> __________________________
> Technology Project Manager
> Axer Systems S.A.
> Rom�n D�az 205 Of. 503
> Fono: 56-2-235 2747
> http://www.axer.cl
>
>
Volunteers - Topics
Posted by Luis Avila <la...@axer.cl>.
Here are a brief list of people involved in topics about the project.
It's only with a very fast revision of the mails so surely is
incomplete, but is a starting point.
I propose to make one page in the wiki site with this information, so we
can choose some team or to start one in some topic not covered.
Regards
Persistence:
dain
Jeremy Boynes
Michael Turilin
JNDI
Richard Monson-Haefel
Henri Yandell
Stefano Passiglia
Alex Blewitt
WS
Richard Monson-Haefel
Alberto Rodriguez Galdo
Mail
Alex Blewitt
User Friendliness
Erin Mulder
Chris Opacki
Clustering
Michael Remijan
Security
Prashant Bhatt
Tests
--
Luis Avila
__________________________
Technology Project Manager
Axer Systems S.A.
Román Díaz 205 Of. 503
Fono: 56-2-235 2747
http://www.axer.cl
Re: LDAP Support in Geronimo
Posted by Phil Steitz <ph...@steitz.com>.
Bruce Snyder wrote:
> This one time, at band camp, Richard Monson-Haefel said:
>
> RM>It would be interesting to find out how fast LDAPd's embedded lookup facility
> RM>is. If its fast, it would make sense to eventually use it for the JNDI
> RM>Environment Naming Context. However, I still feel that having something quick
> RM>and lightweight now - a stopgap if you will - is better than waiting for LDAPd
> RM>to reach its first release.
>
> LDAP is designed to be extremely fast when performing lookups and IMHO
> would be a fine choice as one of the implementations. I've worked with
> LDAP in the past and been very impressed by it's performance on digging
> through even a very sizable directory. However, the flip side of the coin
> is that inserts are not nearly as fast as lookups. But inserts into any
> type of persistence repository (LDAP, SQL, file, etc.) is always slower
> due to the fact that they're I/O bound.
If I understood Alex's post above, the embedded version bypasses the
wire protocol, making it faster still and eliminating the resource mgt
issues with connection pools, sockets, file descriptors, etc. If it
also supports LDAP replication across embeddings, that will solve
another basic problem (see below).
>
> RM>That said, embedding a LDAP server into Geronimo would provide a solution for a
> RM>variety of problems, least of which is the JNDI ENC. It would be the nexus of an
> RM>authentication/authorization system and security domain administration. In
> RM>addition, it can be used for configuration and would make an excellent service
> RM>in its own right -- especially if its accessible intraVM as well as interVM. It
> RM>could also be used as the CORBA Naming service, support for which is required by
> RM>the EJB specification.
>
> Very true. A JNDI lookup abstracts the backing mechanism. This is very
> powerful because it gives us the ability to implement an innumerable
> amount of solutions on the backend, all of which use JNDI as the lookup
> API. This would really satisfy many different requirements for many
> different industries, too, because not everyone can deal with LDAP.
>
> RM>Personally, I hope that LDAPd is accepted into the Incubator so that we can plan
> RM>on incorporating into the Geronimo project (provided it works and survives the
> RM>incubator process).
>
> +1 ;-)
>
> RM>Whether or not we end up using LDAPd, Geronimo should be designed so that LDAP
> RM>servers of any make are plugable at some level. This would enable organizations
> RM>to leverage existing LDAP installations. If LDAP is plugable (is that a word?)
> RM>it should be a simple to configure and deploy -- avoiding overly complex
> RM>bindings is important, IMO.
The LDAP protocol is certainly standardized, but to my knowledge the
embedded API described above is not. So "any" LDAP server will work if
either the LDAP JNDI provider or the LDAP wire protocol is used, but to
get the benefit of the embedded solution we would need to use LDAPd
(unless I am missing something).
> RM>
> RM>In the LDAP area I suggest we adopt a dual strategy of supporting arbitrary LDAP
> RM>installations via remote communications (LDAP protocol) as well as an embedded
> RM>solution (i.e. embedded LDAPd). If we are serious about LDAPd, perhaps those
> RM>folks could help with both strategies.
>
> This was the next thing I was going to say in addition to my statements
> above. Support of more than just an embedded LDAP soltuion is crucial
> and that's what the JNDI abstraction will buy us.
+1 JNDI abstraction will also allow the three really different basic
JNDI requirements mentioned above -- config, ENC, identities -- to be
backed by different stores/lookup technologies. I would expect that
in-memory solutions (which the embedded LDAPd would essentially be,
since the db would be fully cached) would usually be best for the first
two, while the third would generally require access to a remote
repository. The abstraction layer should allow different strategies to
be plugged in for each of these applications.
>
> RM>The one thing I'm not sure about i the Avalon coupling. If LDAPd is based on
> RM>Avalon would it still work as an imbedable service if Geronimo doesn't adopt
> RM>Avalon? It seems likely, but I think its worth asking anyway.
>
> Good question. If Avalon will work as yet another service within Geronimo,
> then I imagine that LDAPd would simply depend upon the Avalon service.
>
> RM>Alex Karasulu wrote:
> RM>
> RM>> BTW, the LDAPd team is currently working on submitting their incubator
> RM>> request as well. LDAPd is based on Avalon and is an LDAPv3 server with a
> RM>> SEDA based architecture. It is based almost entirely on Apache software.
> RM>>
> RM>> We started the LDAPd (embeddable) server project to eventually enable open
> RM>> source J2EE servers like JBoss, and Servlet Containers like Tomcat with an
> RM>> embedded LDAP server for configuration management. The project was
> RM>> triggered by the introduction of an LDAPv2 server into Weblogic Server by
> RM>> BEA. We wanted JBoss and Tomcat to be able to compete with BEA in this
> RM>> aspect - especially since BEA WLS uses LDAP to easily manage cluster
> RM>> configurations amongst other things.
> RM>>
> RM>> The role of a directory is critical to any distributed component model and
> RM>> goes beyond the aspect of configuration management. Take web services for
> RM>> example: the UDDI folks are working with the IETF to establish a schema
> RM>> model in LDAP for UDDI, here's the draft submission
> RM>> http://www.globecom.net/ietf/draft/draft-bergeson-uddi-ldap-schema-01.html.
> RM>> Likewise .NET is leveraging AD and ADAM to do the same for both web services
> RM>> and COM objects. When systems are composed of hundreds or thousands of
> RM>> distributed components (J2EE or .NET), these components need to find one
> RM>> another. We at the LDAPd Group feel that LDAP is a critical technology in
> RM>> enabling these distributed component architectures, which allows them to be
> RM>> orchestrated regardless of distribution. Our existence is based on this
> RM>> premise. We have come along way and are about to provide these functional
> RM>> services in a standard fashion while leveraging JNDI.
> RM>>
> RM>> LDAPd is based on Avalon and has a very unique relationship with the JNDI.
> RM>> Its front end which serves requests over the line protocol simply uses the
> RM>> server-side JNDI provider to access LDAP entries as Attributes. The server
> RM>> side provider wraps the backend apparatus which attaches naming system
> RM>> partitions to one common tree from multiple databases, or backends as we
> RM>> call them. Embedding LDAPd with the front end or just its backend apparatus
> RM>> will be as easy as using JNDI to get a context through the server side JNDI
> RM>> provider. This way under an embedded configuration, the protocol is
> RM>> bypassed and embedding servers simply access the backend apparatus directly
> RM>> via JNDI. We have centered around this design specifically to enable
> RM>> applications that already use JNDI LDAP to continue to do so but now under
> RM>> an embedded configuration. The change should only be a property setting for
> RM>> the Context.INITIAL_CONTEXT_FACTORY property.
Is there support for replication across embeddings? This would be
useful in clustered deployments.
> RM>>
> RM>> As with any open source effort we question our motives and our direction
> RM>> frequently and welcome commentary from a community. This is what has made
> RM>> several Apache projects so strong and what we believe will make LDAPd
> RM>> strong. What thoughts if any does the community have on this hypothesis and
> RM>> LDAPd's fundamental reason for being?
> RM>>
> RM>> Also we have come to a point where LDAPd has become bigger than our group
> RM>> alone. We are continuously looking for contributions and guidance to make
> RM>> the right decisions. From several conversations with Apache members we have
> RM>> begun to realize that LDAPd would make a good addition to the suite of
> RM>> flagship servers generously offered by the ASF. Hence we are now taking
> RM>> formal steps toward offering LDAPd to the Apache community via the
> RM>> Incubator. Together we can merge the protocols that glue the Internet
> RM>> together and offer world class software freely in the Apache tradition.
> RM>>
> RM>> Sincerely,
> RM>> Alex Karasulu
> RM>>
>
> Bruce
Re: LDAP Support in Geronimo
Posted by Bruce Snyder <fe...@frii.com>.
This one time, at band camp, Richard Monson-Haefel said:
RM>It would be interesting to find out how fast LDAPd's embedded lookup facility
RM>is. If its fast, it would make sense to eventually use it for the JNDI
RM>Environment Naming Context. However, I still feel that having something quick
RM>and lightweight now - a stopgap if you will - is better than waiting for LDAPd
RM>to reach its first release.
LDAP is designed to be extremely fast when performing lookups and IMHO
would be a fine choice as one of the implementations. I've worked with
LDAP in the past and been very impressed by it's performance on digging
through even a very sizable directory. However, the flip side of the coin
is that inserts are not nearly as fast as lookups. But inserts into any
type of persistence repository (LDAP, SQL, file, etc.) is always slower
due to the fact that they're I/O bound.
RM>That said, embedding a LDAP server into Geronimo would provide a solution for a
RM>variety of problems, least of which is the JNDI ENC. It would be the nexus of an
RM>authentication/authorization system and security domain administration. In
RM>addition, it can be used for configuration and would make an excellent service
RM>in its own right -- especially if its accessible intraVM as well as interVM. It
RM>could also be used as the CORBA Naming service, support for which is required by
RM>the EJB specification.
Very true. A JNDI lookup abstracts the backing mechanism. This is very
powerful because it gives us the ability to implement an innumerable
amount of solutions on the backend, all of which use JNDI as the lookup
API. This would really satisfy many different requirements for many
different industries, too, because not everyone can deal with LDAP.
RM>Personally, I hope that LDAPd is accepted into the Incubator so that we can plan
RM>on incorporating into the Geronimo project (provided it works and survives the
RM>incubator process).
+1 ;-)
RM>Whether or not we end up using LDAPd, Geronimo should be designed so that LDAP
RM>servers of any make are plugable at some level. This would enable organizations
RM>to leverage existing LDAP installations. If LDAP is plugable (is that a word?)
RM>it should be a simple to configure and deploy -- avoiding overly complex
RM>bindings is important, IMO.
RM>
RM>In the LDAP area I suggest we adopt a dual strategy of supporting arbitrary LDAP
RM>installations via remote communications (LDAP protocol) as well as an embedded
RM>solution (i.e. embedded LDAPd). If we are serious about LDAPd, perhaps those
RM>folks could help with both strategies.
This was the next thing I was going to say in addition to my statements
above. Support of more than just an embedded LDAP soltuion is crucial
and that's what the JNDI abstraction will buy us.
RM>The one thing I'm not sure about i the Avalon coupling. If LDAPd is based on
RM>Avalon would it still work as an imbedable service if Geronimo doesn't adopt
RM>Avalon? It seems likely, but I think its worth asking anyway.
Good question. If Avalon will work as yet another service within Geronimo,
then I imagine that LDAPd would simply depend upon the Avalon service.
RM>Alex Karasulu wrote:
RM>
RM>> BTW, the LDAPd team is currently working on submitting their incubator
RM>> request as well. LDAPd is based on Avalon and is an LDAPv3 server with a
RM>> SEDA based architecture. It is based almost entirely on Apache software.
RM>>
RM>> We started the LDAPd (embeddable) server project to eventually enable open
RM>> source J2EE servers like JBoss, and Servlet Containers like Tomcat with an
RM>> embedded LDAP server for configuration management. The project was
RM>> triggered by the introduction of an LDAPv2 server into Weblogic Server by
RM>> BEA. We wanted JBoss and Tomcat to be able to compete with BEA in this
RM>> aspect - especially since BEA WLS uses LDAP to easily manage cluster
RM>> configurations amongst other things.
RM>>
RM>> The role of a directory is critical to any distributed component model and
RM>> goes beyond the aspect of configuration management. Take web services for
RM>> example: the UDDI folks are working with the IETF to establish a schema
RM>> model in LDAP for UDDI, here's the draft submission
RM>> http://www.globecom.net/ietf/draft/draft-bergeson-uddi-ldap-schema-01.html.
RM>> Likewise .NET is leveraging AD and ADAM to do the same for both web services
RM>> and COM objects. When systems are composed of hundreds or thousands of
RM>> distributed components (J2EE or .NET), these components need to find one
RM>> another. We at the LDAPd Group feel that LDAP is a critical technology in
RM>> enabling these distributed component architectures, which allows them to be
RM>> orchestrated regardless of distribution. Our existence is based on this
RM>> premise. We have come along way and are about to provide these functional
RM>> services in a standard fashion while leveraging JNDI.
RM>>
RM>> LDAPd is based on Avalon and has a very unique relationship with the JNDI.
RM>> Its front end which serves requests over the line protocol simply uses the
RM>> server-side JNDI provider to access LDAP entries as Attributes. The server
RM>> side provider wraps the backend apparatus which attaches naming system
RM>> partitions to one common tree from multiple databases, or backends as we
RM>> call them. Embedding LDAPd with the front end or just its backend apparatus
RM>> will be as easy as using JNDI to get a context through the server side JNDI
RM>> provider. This way under an embedded configuration, the protocol is
RM>> bypassed and embedding servers simply access the backend apparatus directly
RM>> via JNDI. We have centered around this design specifically to enable
RM>> applications that already use JNDI LDAP to continue to do so but now under
RM>> an embedded configuration. The change should only be a property setting for
RM>> the Context.INITIAL_CONTEXT_FACTORY property.
RM>>
RM>> As with any open source effort we question our motives and our direction
RM>> frequently and welcome commentary from a community. This is what has made
RM>> several Apache projects so strong and what we believe will make LDAPd
RM>> strong. What thoughts if any does the community have on this hypothesis and
RM>> LDAPd's fundamental reason for being?
RM>>
RM>> Also we have come to a point where LDAPd has become bigger than our group
RM>> alone. We are continuously looking for contributions and guidance to make
RM>> the right decisions. From several conversations with Apache members we have
RM>> begun to realize that LDAPd would make a good addition to the suite of
RM>> flagship servers generously offered by the ASF. Hence we are now taking
RM>> formal steps toward offering LDAPd to the Apache community via the
RM>> Incubator. Together we can merge the protocols that glue the Internet
RM>> together and offer world class software freely in the Apache tradition.
RM>>
RM>> Sincerely,
RM>> Alex Karasulu
RM>>
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
LDAP Support in Geronimo
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
LDAP Support in Geronimo
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
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
>