blob: 2c07c2c6f3712bf218cdfeb4da880863bd9b1a60 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<document>
<properties>
<author email="akarasulu@apache.org">Alex Karasulu</author>
<title>Apache Directory Project: Server's Features</title>
</properties>
<body>
<section name="Server's Features">
<p>
The Apache Directory Server is an embeddable LDAP server implemented in
pure Java. It has several features that make it unique amoung LDAP
servers. These features are described below:
</p>
<ul>
<li>
Designed as an LDAP and X.500 experimentation platform. Plugable
components and subsystems make Eve extremely modular and perfect for
experiments with various aspects of the LDAP protocol. The server
may be made to can run on any IoC based microkernel using IoC type
wrappers for POJO components implementing POJI services.
</li>
<li>
The server's frontend is completely separable from its backend and
vice-versa making it very flexible for implementing virtual
directories, proxy servers and gateways to X.500.
</li>
<li>
Several backends can be implemented and plugged into the server's
partition nexus. The server supports a BTree based partition out of
the box but any backing store can be used to implement a partition so
long as it conforms to interfaces.
</li>
<li>
The server exposes all aspects of administration via a special system
backend. LDAP can be used to manage these concerns through the
system naming context at <code>ou=system</code>.
</li>
<li>
Java based triggers and stored procedures are being implemented.
</li>
<li>
Both the backend subsystem and the frontend are separable and
independently embeddable.
</li>
<li>
The server contains a server side JNDI LDAP provider as the facade
for the entire backend subsystem. JNDI operations are directly
translated by this provider into operations against the nexus and the
target partitions storing server entries.
</li>
<li>
The server will use JNDI as the data access API for stored procedures.
This will make stored procedures functional within and outside of the
server without requiring recompilation.
</li>
<li>
The server's networking code is based on a simple Staged Event Driven
Architecture (SEDA) which gives it the ability to handle large
amounts of concurrency. Multiple swapable network layers will be
available for different usage characteristics.
</li>
<li>
The server uses the Snickers tools and APIs for ASN.1 BER encoding and
decoding. These tools are designed for a very small encoding and
decoding footprint as well as for use in non-blocking servers. The
chunking nature of the BER codec makes the server very efficient while
handling encoding and decoding making it more resistant to DoS
attacks.
</li>
</ul>
</section>
</body>
</document>