You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by bu...@apache.org on 2016/12/31 00:12:50 UTC
svn commit: r1003796 - in /websites/staging/directory/trunk/content: ./
api/user-guide/1.2-ldap-in-a-few-words.html
api/user-guide/1.3-apache-ldap-api-rational.html
api/user-guide/1.4-preparation-to-code.html
Author: buildbot
Date: Sat Dec 31 00:12:50 2016
New Revision: 1003796
Log:
Staging update by buildbot for directory
Modified:
websites/staging/directory/trunk/content/ (props changed)
websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html
websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html
websites/staging/directory/trunk/content/api/user-guide/1.4-preparation-to-code.html
Propchange: websites/staging/directory/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Sat Dec 31 00:12:50 2016
@@ -1 +1 @@
-1776661
+1776664
Modified: websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html
==============================================================================
--- websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html (original)
+++ websites/staging/directory/trunk/content/api/user-guide/1.2-ldap-in-a-few-words.html Sat Dec 31 00:12:50 2016
@@ -184,19 +184,19 @@
}
h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
<h1 id="12-ldap-in-a-few-words">1.2 - LDAP in a few words<a class="headerlink" href="#12-ldap-in-a-few-words" title="Permanent link">¶</a></h1>
-<p><strong>LDAP</strong> is not a new technlology. It has been around since mid 1990, as a way to mitigate the complexity of the <strong>X.500</strong> based servers access. It's name is an acronym for <strong>L</strong>ightweight <strong>D</strong>irectory <strong>A</strong>ccess <strong>P</strong>rotocol. Soon after the first standard has been issued, the first full <em>LDAP</em> server was written (ie, X.500 was pushed out of the equation).</p>
-<p>We will now use the term <strong>LDAP</strong> and <strong>LDAP</strong> server for respectively the protocole and the server.</p>
+<p><strong>LDAP</strong> is not a new technlology. It's been around since the 90's to mitigate <strong>X.500</strong> complexities. Its name is an acronym for <strong>L</strong>ightweight <strong>D</strong>irectory <strong>A</strong>ccess <strong>P</strong>rotocol. Soon after the first standard was issued, the first full <em>LDAP</em> server was created and X.500 became obsolete.</p>
+<p>We'll use the term <strong>LDAP</strong> to represent the protocol and <strong>LDAP</strong> server to represent the server that implements it.</p>
<h2 id="features">Features<a class="headerlink" href="#features" title="Permanent link">¶</a></h2>
-<p>A <strong>LDAP</strong> server provides access to entries, stored in a backend. It offers an interrogation mechanism allowing fast retrieval of entries. The data structure is hierarchical, and we use a schema to manage the content of entries, plus the organisation of data.</p>
-<p>A <strong>LDAP</strong> client first has to connect to the server, and disconnect at the end. Some operations can be done on data, searches, modification and deletion, among a few others.</p>
-<p><strong>LDAP</strong> servers are extensible, but they all use a common protocol which makes it easy for users to request them. This API is an exemple of what <strong>LDAP</strong> is very good at : access data in a fast way, across servers.</p>
+<p>An <strong>LDAP</strong> server provides access to entries stored in a backend database. It provides a mechanism for fast searching and retrieval of entries. Its data structure is hierarchical, and uses a schema to manage the definition of the entry's data formats.</p>
+<p>An <strong>LDAP</strong> client must first connect to a server and disconnect when finished. Some operations may be performed on the data itself, e.g. searches, modifications and deletions, along with a few others.</p>
+<p><strong>LDAP</strong> servers are extensible, but they all use a common protocol which makes it easy for users to request to interact with them. This API is an exemple of what <strong>LDAP</strong> is very good at : it access data in a fast way, across servers.</p>
<h2 id="characteristics">Characteristics<a class="headerlink" href="#characteristics" title="Permanent link">¶</a></h2>
-<p><strong>LDAP</strong> servers are fast for retrievals : they have been designed for this purpose. On the other hand, modifications can be costly. This has to be understood when writing an application using a <strong>LDAP</strong> server as a backend.</p>
-<p>Each entry is identified by it's position in the hierarchy, and we use what is called a <strong>D</strong>istinguished <strong>N</strong>ame (or <strong>Dn</strong>) to describe this position in the tree. The base is also named the <strong>DIT</strong>, or <strong>D</strong>irectory <strong>I</strong>nformation <strong>T</strong>ree.</p>
+<p><strong>LDAP</strong> servers are fast for retrievals : having been designed specifically for this purpose. But modifications can be costly. These characteristics must be understood when writing applications using an <strong>LDAP</strong> server for data storage.</p>
+<p>Each entry is identified by a location within it's corresponding <strong>D</strong>irectory <strong>I</strong>nformation <strong>T</strong>ree, and we use what's called a <strong>D</strong>istinguished <strong>N</strong>ame (or <strong>Dn</strong>) to describe its address within it. The base entry, is known as the suffix, and all entries beneath it are collectively known as the <strong>DIT</strong>.</p>
<h2 id="programming">Programming<a class="headerlink" href="#programming" title="Permanent link">¶</a></h2>
-<p>Nowadays, <strong>LDAP</strong> is a part of the <strong>IT</strong> and it's difficult to avoid having to deal with it. <strong>LDAP</strong> servers are used to manage authentication, mainly, but also authorization, and more. It's very likely that you will have to write some code to access such a <strong>LDAP</strong> server, and the existing <strong>API</strong> are a bit cumbersome. This new <strong>LDAP API</strong> has been defined to facilitate this kind of tasks.</p>
+<p><strong>LDAP</strong> is a part of the <strong>IT</strong> landscape and so it's unavoidable that we must deal with it. <strong>LDAP</strong> servers are used to manage authentication, authorizations, demographic info and more. It's very likely that you will have to write some code to access data over <strong>LDAP</strong>, and existing <strong>API</strong>s aren't quite up to the task. This <strong>LDAP API</strong> has been designed to simplify usage.</p>
<h2 id="going-further">Going further<a class="headerlink" href="#going-further" title="Permanent link">¶</a></h2>
-<p>This was a very short introduction, you can find more literature about <strong>LDAP</strong> on the web : <a href="http://en.wikipedia.org/wiki/LDAP">Wikipedia</a> gives you a good starting point with many valid pointers.</p>
+<p>This was a very short introduction, there's more literature about <strong>LDAP</strong> on the web : <a href="http://en.wikipedia.org/wiki/LDAP">Wikipedia</a> provides a good starting point.</p>
<div class="nav">
Modified: websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html
==============================================================================
--- websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html (original)
+++ websites/staging/directory/trunk/content/api/user-guide/1.3-apache-ldap-api-rational.html Sat Dec 31 00:12:50 2016
@@ -183,21 +183,21 @@
visibility: hidden;
}
h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
-<h1 id="13-the-apache-ldap-api-rational">1.3 - The Apache LDAP API rational<a class="headerlink" href="#13-the-apache-ldap-api-rational" title="Permanent link">¶</a></h1>
-<p>Once we start to think about creating a new <strong>LDAP</strong> <strong>API</strong>, the first thing that comes to mind is that it could be a duplication of effort : there are already many libraries offering almost everything needed to write <strong>LDAP</strong> code. Some of them are :</p>
+<h1 id="13-the-apache-ldap-api-rationale">1.3 - The Apache LDAP API rationale<a class="headerlink" href="#13-the-apache-ldap-api-rationale" title="Permanent link">¶</a></h1>
+<p>When creating a new <strong>LDAP</strong> <strong>API</strong>, we need to consider whether it's a duplication of effort; there are already some libraries that do this. For example:</p>
<ul>
<li><strong>JNDI</strong> : the default <strong>JDK</strong> <strong>API</strong></li>
-<li><strong>Netscape</strong> <a href="http://www.mozilla.org/directory/javasdk.html">LdapSdk</a></li>
+<li><strong>Netscape</strong> (a.k.a Mozilla) <a href="http://www.mozilla.org/directory/javasdk.html">LdapSdk</a></li>
<li><strong>OpenLDAP</strong> <a href="http://www.openldap.org/jldap/">JLdap</a></li>
</ul>
-<p>So what makes the development of a new <em>LDAP JAVA API</em> a valid effort, and not another version of <strong><a href="http://en.wikipedia.org/wiki/Not_Invented_Here">NIH</a></strong> syndrom ?</p>
-<p>There are many reasons why we decided to start to work on such an <strong>API</strong>, and we will expose them in this chapter.</p>
-<h2 id="history">history<a class="headerlink" href="#history" title="Permanent link">¶</a></h2>
-<p>The Apache Directory Server project was first built on top of <strong>JNDI</strong>, but many of the internal <strong>LDAP</strong> structure were developed internally, just because <strong>JNDI</strong> was not designed specifically for <strong>LDAP</strong>, so it was not convenient for us to use those structure. Step by step, all of the <strong>LDAP</strong> objects (<em>Attribute</em>, <em>Entry</em>, <em>DN</em>, ...) were implemented again.</p>
-<p>At some point, we needed to communicate with another <strong>LDAP</strong> server without having to go through <strong>JNDI</strong>, so we developed our own <em>LdapConnection</em> class. This was the last step toward a full <strong>Java API</strong>.</p>
-<p>Strange enough, at the very same time in 2007, the <strong>Sun</strong> people working on <strong>OpenDS</strong> contacted us to know if we would agree to work on what would have become the next version of <strong>JNDI</strong> (<a href="https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric">Resurrecting The Java LDAP Centric API</a>. Sadly, this effort soon staled, as it seemed that <em>JNDI2</em> was not anymore an urgency for <strong>Sun</strong>. We decided to go on but the pace was slow.</p>
-<p>We started again to work on this API with the <strong>OpenDS</strong> team in 2009, and did a presentation during the 2009 <strong>LdapCon</strong> (<a href="http://www.symas.com/ldapcon2009/papers/poitou1.shtml">Towards a common LDAP API for the Java Platform</a>). The story repeated itself with <strong>Oracle</strong> buying <strong>Sun</strong> in 2010, after months of valuable collaboration with <em>Sun</em>.</p>
-<p>At least, we get some kind of convergence in many aspects of the <strong>API</strong>. We agreed on some of the key features the new <strong>LDAP API</strong> should offer :</p>
+<p>What makes the development of this new <em>LDAP JAVA API</em> a valid effort, and <strong><a href="http://en.wikipedia.org/wiki/Not_Invented_Here">NIH</a></strong> syndrom?</p>
+<p>There are many reasons why we decided to start to work on this <strong>API</strong>, and we'll discuss them throughout this chapter.</p>
+<h2 id="history">History<a class="headerlink" href="#history" title="Permanent link">¶</a></h2>
+<p>The Apache Directory Server project was first using <strong>JNDI</strong>, but many of the internal <strong>LDAP</strong> structures were developed internally, because <strong>JNDI</strong> was not well suited for <strong>LDAP</strong> usage. This meant it wasn't convenient for us to use these structures. Step by step, all of the <strong>LDAP</strong> objects (<em>Attribute</em>, <em>Entry</em>, <em>DN</em>, ...) were implemented again.</p>
+<p>At some point, we needed to communicate with other <strong>LDAP</strong> servers without having using <strong>JNDI</strong>, so we developed our own <em>LdapConnection</em> class. This was the first step toward a full <strong>Java API</strong> specifically designed for LDAP.</p>
+<p>Strangely enough when we were doing this, back in 2007, <strong>Sun</strong> people working on the <strong>OpenDS</strong> project contacted us to ask if we'd be interested in helping them with the next version of <strong>JNDI</strong> (<a href="https://blogs.oracle.com/treydrake/entry/resurrecting_the_java_ldap_centric">Resurrecting The Java LDAP Centric API</a>. Sadly, this effort stalled, as the need for <em>JNDI2</em> was no longer a priority for <strong>Sun</strong>. We decided to continue with our work but the the pace was slow.</p>
+<p>The work began once again after the <strong>OpenDS</strong> project team's presentation at <strong>LdapCon</strong> back in 2009 (<a href="http://www.symas.com/ldapcon2009/papers/poitou1.shtml">Towards a common LDAP API for the Java Platform</a>). The story repeated itself after <strong>Oracle</strong> bought <strong>Sun</strong> in 2010.</p>
+<p>Despite these fits and starts, a consensus was reached on the need for a new <strong>API</strong> and what it should do. We agreed on the key features for a new <strong>LDAP API</strong>:</p>
<ul>
<li>A complete coverage of the <strong>LDAP</strong> protocol</li>
<li>A schema aware <strong>API</strong></li>
@@ -205,9 +205,9 @@ h2:hover > .headerlink, h3:hover > .head
<li>An <strong>API</strong> taking advantage of the new <strong>Java</strong> construction (generics, ellipsis, NIO)</li>
</ul>
<h2 id="result">Result<a class="headerlink" href="#result" title="Permanent link">¶</a></h2>
-<p>The newly defined <strong>API</strong> fulfill all those aspects. </p>
-<p>We also wanted to make this <strong>API</strong> available for the masses. The Apache Software Foundation value quality and community over code, which means we think that the code is the result of a collaborative work, our users being a part of this collaboration. Every bug a user find, it's an opportunity to provide a better version of the <strong>API</strong>.</p>
-<p>At he end, we are proud to deliver an <strong>API</strong> which is used in the Apache Directory Server, but also in the Ldap Browser. </p>
+<p>This newly defined <strong>API</strong> fulfills all of these aspects. </p>
+<p>We wanted to make sure this <strong>API</strong> was made available to the masses. The Apache Software Foundation values quality and community over code, which means the code is the result of a collaborative work, our users being a necessary part of this collaboration. Every bug a user finds, is an opportunity to provide a better version of the <strong>API</strong> for everyone.</p>
+<p>In the end, we're proud to deliver a useful <strong>API</strong> that everyone can use, include our own projects like the Apache Directory Server, Directory Studio and Fortress. </p>
<div class="nav">
Modified: websites/staging/directory/trunk/content/api/user-guide/1.4-preparation-to-code.html
==============================================================================
--- websites/staging/directory/trunk/content/api/user-guide/1.4-preparation-to-code.html (original)
+++ websites/staging/directory/trunk/content/api/user-guide/1.4-preparation-to-code.html Sat Dec 31 00:12:50 2016
@@ -184,9 +184,9 @@
}
h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
<h1 id="14-preparation-to-code">1.4 - Preparation to code<a class="headerlink" href="#14-preparation-to-code" title="Permanent link">¶</a></h1>
-<p>In order to develop with the <strong>Apache Directory LDAP API</strong>, you first have to use a <strong>Java 6</strong> JDK or higher. </p>
-<p>Second, you have to download the <strong><a href="http://directory.apache.org/api/downloads.html">API</a></strong>. This package contains not only the <strong>LDAP API</strong>, but also all the needed jars (like <em>commons-lang</em>, <em>slf4j</em>...).</p>
-<p>If you are using <strong>Maven</strong>, you don't even have to refer all the libraries that are found in the package, they will be deduced automatically. You will just have to add a dependency on <em>api-all.jar</em> :</p>
+<p>The <strong>Apache Directory LDAP API</strong> requires <strong>Java 6</strong> JDK or higher. </p>
+<p>Secondly, you must download the <strong><a href="http://directory.apache.org/api/downloads.html">API</a></strong>. This package contains the <strong>LDAP API</strong> plus all of its dependent jars (like <em>commons-lang</em>, <em>slf4j</em>...).</p>
+<p>If you're using <strong>Maven</strong>, add the following dependency on <em>api-all.jar</em> :</p>
<div class="codehilite"><pre><span class="nt"><dependency></span>
<span class="nt"><groupId></span>org.apache.directory.shared<span class="nt"></groupId></span>
<span class="nt"><artifactId></span>api-all<span class="nt"></artifactId></span>
@@ -194,7 +194,7 @@ h2:hover > .headerlink, h3:hover > .head
</pre></div>
-<p>This is it, you should be ready to code !</p>
+<p>and all of its depedent jar files will be included automatically. That's it, now you should be ready to code!</p>
<div class="nav">