You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by Apache Wiki <wi...@apache.org> on 2007/02/04 18:50:17 UTC
[Directory Wiki] Update of "ProjectProposal" by CKoppelt
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.
The following page has been changed by CKoppelt:
http://wiki.apache.org/directory/ProjectProposal
The comment on the change is:
already on cwiki
------------------------------------------------------------------------------
+ deleted
- = Proposal for an Apache Directory Project =
- ''10 Sept 2003, Alex Karasulu (aok123@bellsouth.net) LDAPd Group Founder''
- ----
-
-
- '''Section 0 : Rationale'''
-
- The geometric growth of networks, services, distributed systems,
- and their components has brought about a revival of interest in
- directories. Directories are no longer considered commodity products
- used to store a phone book or list of users. Directories and LDAP
- have grown into a critical technology that will inevitably become a
- cornerstone of distributed systems. Several software giants like BEA,
- SUN, and Microsoft have already demonstrated their belief in this
- outcome by heavily integrating their products with directories. Directory
- and naming systems are being used in everything from a simplified form
- for ["J2EE"] configuration to full-blown enterprise directories, within
- identity management systems and distributed computing platforms like JINI.
-
-
- The overhead of managing several copies of relatively static
- information across systems and enterprises is daunting and introduces
- the potential for data inconsistency. The frequently replicated user
- and group tables in almost every database driven application alone is
- a testament to this fact. When multiple systems have to inter
- operate, they must share access to common information, and
- directories are the best storage paradigm for rapidly accessing
- this type of data. Whether the information to be stored,
- is a component's configuration, a user's security profile, a business
- rule or a business process, directories are the place to store it for
- centralized management, and distribution across systems.
-
- To date, a fully compliant pure Java open source LDAPv3 server has
- not yet been written. This is partially due to the fact that a
- practical stateful protocol server in Java was virtually impossible
- until the introduction of the NIO packages in the 1.4 SDK. LDAP, as a
- stateful protocol, manages client state through a TCP socket
- connection. The socket connection persists through several client
- requests and server responses tying them together under a logical
- session or conversation. Before the introduction of non-blocking IO
- in the NIO packages of the 1.4 SDK, a thread had to be dedicated to
- each socket to detect IO. A stateful protocol server written
- completely in Java, would have needed as many active threads as the
- number of concurrent clients. Theoretically, scalability would have
- been very poor; the performance curve would be asymptotic, degrading
- rapidly with an increase in the number of concurrent connections. To
- scale pure Java statefull protocol server implementations had to wait
- until the Merlin release of the JDK.
-
- Furthermore, no embeddable pure Java LDAPv3 server has yet been
- written and made freely available. We believe the embedding of LDAP
- servers into existing mail, application and web servers to be the
- next logical steps in the progression and integration of LDAP.
- Several commercial examples can already be sited: Microsoft Exchange
- and BEA Weblogic Server. The management benefits of coupling these
- servers with an LDAP server are beyond the scope of this proposal and
- left to the imagination of the reader. However, the synergy between
- embedded LDAP servers and other flagship Apache servers would lead to
- greater economies of scale for the Apache server suite and reduce the
- overhead of management for the Apache software user community.
-
- LDAP directories are specialized databases, however unlike their
- RDBMS counterparts, LDAP directories are fairly new and for this
- reason lack rich integration features. High on the list of features
- lacking in LDAP servers are stored procedures and triggers. Triggers
- and Java stored procedures would expand the horizon of LDAP in itself
- even without the benefits of Java. Triggers and stored procedures would
- alleviate ugly workarounds which currently using polling and meta
- directories. These features alone would attract groups within the LDAP
- and Java communities to band together and support the Apache LDAP Project.
-
- LDAP is both a network line protocol and a hierarchical relational
- database. Some might even argue that LDAP is object oriented.
- Regardless, the implementation of an LDAP server is not a trivial
- matter. LDAP code bases written in native languages have to be ported
- to run on different platforms. Conditional complies in C based
- implementations were shown to considerably reduce the maintainability
- of code bases. The complexity of a database, a network line protocol
- and conditional compilation together have resulted in reduced
- maintainability for C based LDAP servers. Also the learning
- curve and hence barrier to entry for developers is greater. These
- complications would not exist for a Java based LDAP server that is
- written once and can run anywhere.
-
- The Apache Foundation supports several component container
- projects which provide the proper foundation for a Java LDAP
- directory server. Apache also supports several server side
- application containers which can realize significant functional
- enhancements by employing an LDAP directory server. Also LDAP
- requiring organizations today must settle for less than optimal
- implementations and often have to pay as high as a dollar per entry
- to directory enable their applications. The Apache LDAP Project would
- solve these problems by providing a free robust LDAPv3 implementation
- in a standalone configuration or an embeddable configuration for use
- in all Apache servers and other third party products.
-
- Our goal is to produce a community of developers with backgrounds in LDAP,
- X.500, Database Engineering and JNDI tasked with the development of
- pure Java LDAPv3 Clients, APIs, JNDI providers and LDAPv3 compliant
- servers with the aforementioned features. The produced software will
- be ASF licensed. Where applicable the best available ASF/BSD licensed
- code will be reused and new code will be added to complete the LDAPv3
- protocol as defined in [http://www.ietf.org/rfc/rfc3377.txt RFC
- 3377] and its associated 8 RFCs listed below:
-
- * [http://www.ietf.org/rfc/rfc2251.txt RFC2251] Lightweight Directory Access Protocol (v3): LDAP on-the-wire protocol
- * [http://www.ietf.org/rfc/rfc2252.txt RFC2252] Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
- * [http://www.ietf.org/rfc/rfc2253.txt RFC2253] Lightweight Directory Access Protocol (v3): UTF-8 String Representation of DNs
- * [http://www.ietf.org/rfc/rfc2254.txt RFC2254] The String Representation of LDAP Search Filters
- * [http://www.ietf.org/rfc/rfc2255.txt RFC2255] The LDAP URL Format
- * [http://www.ietf.org/rfc/rfc2256.txt RFC2256] A Summary of the X.500(96) User Schema for use with LDAPv3
- * [http://www.ietf.org/rfc/rfc2829.txt RFC2829] Authentication Methods for LDAP
- * [http://www.ietf.org/rfc/rfc2830.txt RFC2830] Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
-
- Additionally, the schema objects specified within the following RFCs will be defined for use
- and partial or full complaince will be met where relavent to the project:
-
- * [http://www.ietf.org/rfc/rfc1274.txt RFC1274] The COSINE and Internet X.500 Schema
- * [http://www.faqs.org/rfcs/rfc1804.html RFC1804] Schema Publishing in X.500 Directory
- * [http://www.ietf.org/rfc/rfc2079.txt RFC2079] Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
- * [http://www.ietf.org/rfc/rfc2247.txt RFC2247] Using Domains in LDAP/X.500 Distinguished Names
- * [http://www.ietf.org/rfc/rfc2293.txt RFC2293] Representing Tables and Subtrees in the X.500 Directory
- * [http://www.ietf.org/rfc/rfc2294.txt RFC2294] Representing the O/R Address hierarchy in the X.500 Directory Information Tree
- * [http://www.ietf.org/rfc/rfc2307.txt RFC2307] An Approach for Using LDAP as a Network Information Service
- * [http://www.ietf.org/rfc/rfc2377.txt RFC2377] Naming Plan for Internet Directory-Enabled Applications
- * [http://www.ietf.org/rfc/rfc2587.txt RFC2587] Internet X.509 Public Key Infrastructure LDAPv2 Schema
- * [http://www.ietf.org/rfc/rfc2589.txt RFC2589] Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
- * [http://www.ietf.org/rfc/rfc2596.txt RFC2596] Use of Language Codes in LDAP
- * [http://www.ietf.org/rfc/rfc2649.txt RFC2649] An LDAP Control and Schema for Holding Operation Signatures
- * [http://www.ietf.org/rfc/rfc2696.txt RFC2696] LDAP Control Extension for Simple Paged Results Manipulation
- * [http://www.ietf.org/rfc/rfc2713.txt RFC2713] Schema for Representing Java(tm) Objects in an LDAP Directory
- * [http://www.ietf.org/rfc/rfc2714.txt RFC2714] Schema for Representing CORBA Object References in an LDAP Directory
- * [http://www.ietf.org/rfc/rfc2798.txt RFC2798] Definition of the inetOrgPerson LDAP Object Class
- * [http://www.ietf.org/rfc/rfc2829.txt RFC2829] Authentication Methods for LDAP
- * [http://www.ietf.org/rfc/rfc2830.txt RFC2830] Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
- * [http://www.ietf.org/rfc/rfc2849.txt RFC2849] The LDAP Data Interchange Format (LDIF) - Technical Specification
- * [http://www.ietf.org/rfc/rfc2891.txt RFC2891] LDAP Control Extension for Server Side Sorting of Search Results
- * [http://www.ietf.org/rfc/rfc3045.txt RFC3045] Storing Vendor Information in the LDAP root DSE
- * [http://www.ietf.org/rfc/rfc3062.txt RFC3062] LDAP Password Modify Extended Operation
- * [http://www.ietf.org/rfc/rfc3088.txt RFC3088] ["OpenLDAP"] Root Service An experimental LDAP referral service
- * [http://www.ietf.org/rfc/rfc3112.txt RFC3112] LDAP Authentication Password Schema
- * [http://www.ietf.org/rfc/rfc3296.txt RFC3296] Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories
- * [http://www.ietf.org/rfc/rfc3383.txt RFC3383] Internet Assigned Numbers Authority (IANA) considerations for the Lightweight Directory Access Protocol (LDAP)
-
-
- '''Section 0.1 : Criteria'''
-
- We feel that this project has a good chance for success as the following project
- aspects are carefully considered :
-
- ''Meritocracy:''
- The project will be meritocratic - the usual Apache meritocracy rules would apply.
-
- ''Community:''
- The user community for this project is potentially massive. The initial developer
- community for this project consists of developers from Apache and LDAPd projects.
- The aim is for this community to grow considerably once this project enters the
- incubator.
-
- ''Core Developers:''
- The initial developers are listed further below within this document and consist
- of some existing Apache committers together with committers from the LDAPd Group.
-
- ''Alignment:''
- There is clear alignment with many existing Apache projects. From Jakarta
- projects such as Tomcat, James and Slide for embedding LDAP. The LDAP DSML
- standards will eventually require the use of several XML projects. Other
- projects like OpenJms, which currently are not Apache projects but very well
- may be in the future will be used for things like replication. Jdbm likewise
- is used for building Btree based indices for custom databases. Also projects
- like Apache Xindice may be leveraged for an XML based backend or for DSML
- enabling subsystems of an LDAP server.
-
- We see the Apache Directory Project as a separate project to existing Apache
- projects, serving several roles
- * Home for Apache Directory Client APIs and Client Scripts
- * Home for Apache JNDI Providers for Various Directory Namespaces
- * Home for Apache Directory Servers
- * May also become home to an ASN.1 Encoding/Decoding Library
-
-
- '''Section 0.2 : Warning Signs'''
-
- We feel this project has a good chance for success as the following warning
- signs do not apply to the project we are proposing:
-
- ''Orphaned products:''
- This project is starting with an existing code base which using lots of the
- high quality open source code out there which is ASF/BSD licensed.
-
- ''Inexperience with open source:''
- The initial community is made up of existing Apache and LDAPd Group committers
- exclusively so the open source experience is there to varying degrees.
-
- ''Reliance on salaried developers:''
- None of the initial developers are currently paid to work on the Directory
- Project.
-
- ''No ties to other Apache products:''
- The Apache Directory Project is complementary to existing technologies at Apache.
- LDAPd currently uses Avalon and will eventually be used by james. LDAPd will
- eventually integrate into Geronimo. The Apache Directory Project will integrate with,
- and possibly subsume, Jakarta Commons Naming.
-
- ''A fascination with the Apache brand:''
- The committers are interested in developing a healthy open source community around
- ASF/BSD licensed directory servers and their clients along with other JNDI
- accessible name spaces. Is Apache the right place? We think it is. Several Apache
- folks have already shown interest in LDAPd, the seed code base to be used for this
- project. In fact the LDAPd Group was initially approached by Apache to submit an
- Incubator proposal. LDAPd Group members voted unanimously to donate the code to
- Apache in an effort to build the next flagship server at Apache and much more.
-
-
- '''Section 1 : Scope of the Project'''
-
- There are multiple goals for this Apache project:
-
- * Promote a healthy open source community!
- * Promote a language agnostic environment for both client side and server side endeavors.
- * A one stop location for all directory and naming needs on any platform or any language.
- * client APIs
- * clients
- * JNDI providers for Java and other namespaces.
- * May also include an LDAP protocol correctness and stress testing suite in the future.
- * Provide servers in embeddable configurations.
- * Provide servers in standalone configurations as UNIX daemons or NT Services.
- * Provide support for Directory Server embedding or integration with existing Apache servers like httpd, Slide, Tomcat, James and Geronimo.
-
-
- '''Section 2 : Initial Source'''
-
- The initial code base from which to create the Apache Directory repository is contained
- mostly at Sourceforge under the LDAPd project accessible [http://sourceforge.net/projects/ldapd here]. This code base must assign copyright to
- the Apache Software Foundation. The code base will need to be licensed under The Apache
- Software Foundation license. The license file in every subproject will be changed to the
- Apache license. The current license is already an Apache "style" license, so
- this change is basically a change to name The ASF as the owner.
-
- The proposed TLP (after incubation) would have an one or more directory servers with
- multiple datastore backends, a JNDI context for ["J2EE"] configuration, JNDI service
- provider(s) for LDAP and other transports, State and Object Factories suitable for use in the various Context/DirContext implementations, etc.
-
- Beside source code the LDAPd Group must transfer its IANA assigned ASN.1 Object
- Identifier to Apache Software Foundation.
-
- '''Section 3 : ASF Resources to be Created'''
-
- ''Section 3.1 : Mailing Lists''
-
- * directory-dev@incubator.apache.org
-
- ''Section 3.2 : CVS Repositories''
-
- * incubator-directory
-
- ''Section 3.3 : Bugzilla or (preferably) Jira''
-
- * directory
-
-
- '''Section 4 : Initial Set of Committers'''
-
- All contributors must sign and submit a Contributors License
- Agreement. The following individuals are the contributors, and have
- signed and sent the agreement at one time or another:
-
- * Alex Karasulu
- * Phil Steitz
- * Robb Penoyer
- * Noel Bergman
- * Jeff Machols
- * Henri Yandell
- * Wes McKean
-
-
- '''Section 5 : Apache Sponsoring Individuals'''
-
- * Nicola Ken Barozzi (Apache Incubator)
- * Noel J. Bergman (Apache James)
- * Henri Yandell (Jakarta Commons Naming)
- * Stephen McConnell (Apache Avalon)
- * James Strachan (Apache Geronimo)
-
-
- '''Section 6 : Incubation Exit Criteria'''
-
- We feel this project should exit the incubator to a TLP using the domain name directory.apache.org should the following goals be met:
-
- ''Technical Goals:''
-
- * Clean status with Apaches Continuous Integration System
- * Website cross reference to existing Apache literature with respect to rules and regulations
- * At a minimum a beta release and/or a series of Release Candidates for a directory server and its clients.
- * At least one server that complies with [http://www.ietf.org/rfc/rfc2251.txt RFC2251]
-
- ''Non-Technical Goals:''
-
- * List presence and monitoring in wider Apache communities
- * Website cross reference to existing Apache literarature with respect to rules and regulations
- * Initial integration plan and cooperation with Geronimo, and James
- * Member presence on the licensing@apache list
- * More Apache or non-Apache committers who are actively modifying source code
-