Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Alex Karasulu" <aok123@bellsouth.net>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Cc: <geronimo-dev@incubator.apache.org>,
	<ldapd-devel@lists.sourceforge.net>
Subject: RE: Avalon + Geronimo = Another (Last?) Chance
Date: Sun, 10 Aug 2003 10:51:47 -0500
Message-ID: <000001c35f57$51952c30$090110ac@trunk.joshuatree.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <3F3648DB.2060500@apache.org>
Importance: Normal

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.htm=
l.
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]=20
Sent: Sunday, August 10, 2003 8:30 AM
To: Avalon Developers List
Subject: Re: Avalon + Geronimo =3D 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=20
requirements in dealing with ORB based services - including things like=20
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=20
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
>
>
>
> =20
>

--=20

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