blob: ca8ea1f12c781f335d25ff94608cab9f4669f193 [file] [log] [blame]
Title: 1.3 - The Apache LDAP API rational
NavPrev: 1.2-ldap-in-a-few-words.html
NavPrevText: 1.2 - LDAP in a few words
NavUp: 1-introduction.html
NavUpText: 1 - Introduction
NavNext: 1.4-preparation-to-code.html
NavNextText: 1.4 - Preparation to code
Notice: Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
.
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
# 1.3 - The Apache LDAP API rationale
When contemplating the creation of a new Java API for **LDAP**, we needed to first consider whether it was really necessary, because there were already a number of libraries that did it. For example:
* **JNDI** : the default **JDK** **API**
* **Netscape** (a.k.a Mozilla) [LdapSdk](http://www-archive.mozilla.org/directory/javasdk.html)
* **OpenLDAP** [JLdap](http://www.openldap.org/jldap/)
So why is the development of our new *LDAP API* for Java NOT the **[NIH](http://en.wikipedia.org/wiki/Not_Invented_Here)** syndrome?
There are a number of reasons for which we'll discuss throughout this chapter.
## History
The Apache Directory Server project was started using the **JNDI** library, but many of its **LDAP** structures had to be developed in-house because the **JNDI** library was ineffective for interacting with an **LDAP** server. It wasn't convenient for us to use JNDI which means it won't be for you either. Eventually, all of the necessary **LDAP** data structures (_Attribute_, _Entry_, _DN_, ...) were re-implemented by us.
At some point we had to communicate with other **LDAP** servers without using the **JNDI** library, so we developed our own _LdapConnection_ class. This was the first step toward a full **Java API** specifically designed for LDAP usage on the Java platform.
Strangely, after starting this effort (back in 2007), some people from **Sun** (Microsystems), who was working on the **OpenDS** project, contacted us to ask if we'd be interested in helping them create the next version of **JNDI**. ([Resurrecting The Java LDAP Centric API](https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric)). Sadly this effort stalled, as the need for *JNDI2* was no longer a priority for **Sun**. Nevertheless we decided to continue our work but the the pace was slow.
The work renewed after the **OpenDS** project team's presentation at **LdapCon** in 2009 ([Towards a common LDAP API for the Java Platform](http://www.symas.com/ldapcon2009/papers/poitou1.shtml)). The story repeated itself once again after **Oracle** bought **Sun** in 2010, and its project team disbanded.
Despite these fits and starts, a consensus was reached about the need for a new LDAP **API** and what it should be capable of doing. We agreed on these key features for the new **LDAP API**:
* A complete coverage of the **LDAP** protocol
* A schema aware **API**
* An easy to use **API**
* An **API** taking advantage of the new **Java** construction (generics, ellipsis, NIO)
## Result
Our newly defined **API** fulfills all of these aspects.
We needed to ensure our **LDAP API** was made available to the masses. Because the Apache Software Foundation values community over code, this code was the result of collaboration, and our users are a necessary part of this process. Every time a user finds and reports a bug we have the opportunity to provide a better version of this **API**.
In the end, we're proud to deliver a powerful new Java LDAP API, that is available for everyone to use, including our sub-projects like Apache Directory Server, Apache Directory Studio and most recently -- Apache Fortress.