Posts Tagged ‘Database’

The OpenDJ Architecture

July 23, 2012 4 comments

An understanding of the components that make up the OpenDJ Architecture is useful for administering, configuring, or troubleshooting the OpenDJ server.

The following information has been taken from ForgeRock’s OpenDJ Administration, Maintenance and Tuning Class and has been used with the permission of ForgeRock.

The OpenDJ server has been developed using a modular architecture in which most or all components are written to a well-defined specification.  This image above provides an overview of these components.  The following sections provide a brief description of some of the more prevalent components shown in this image.

Configuration Handler

The OpenDJ Configuration Handler is responsible for managing configuration information within OpenDJ’s configuration files (i.e. config.ldif).  Configuration information may impact one or more components; as such, the Configuration Handler is responsible for notifying appropriate components when a configuration change occurs.

Connection Handlers

Connection and request handlers manage all interaction with LDAP clients. This includes accepting new connections and reading and responding to client.  Connection handlers are responsible for any special processing that might be required for this communication, including managing encryption or performing protocol translation.  It is possible to have multiple concurrent implementations active at any given time and as such, OpenDJ includes connection handlers which support various forms of communication that clients use to interact with the server (JMX, LDAP, LDAPS, LDIF, SNMP).  Administrators have the ability to enable or disable these connection handlers to support their client environment.

Note:  ForgeRock is currently working on REST and JSON interfaces to provide direct access to directory server data.

Backend Databases

Connection handlers place client requests onto OpenDJ’s Work Queue.  Worker threads detect requests placed on the work queue and are responsible for performing the processing necessary to respond to the request.  Today’s directory servers must be able to handle a tremendous number of requests in a short period of time; as such, OpenDJ’s Work Queue has been built to be both highly efficient and provide high performance.

A backend database serves as a repository for searching, retrieving, and storing directory data.  OpenDJ supports multiple backends including those considered typical databases (such as Oracle, MySql, and Berekely DB) as well as file-based and memory-based backends.  There can be multiple backend databases active at any given time, each of which handle mutually exclusive subsets of data (selection of the appropriate database is based on the root suffix specified in the operation).  OpenDJ facilitates interaction with these backends and provides tools for enabling, disabling, creating, removing, backing up, and restoring the databases independently from each other without impacting other backends.

Note:  Backends may consist of local or remote repositories (i.e. the database is stored on a remote machine).  This can be found in cases where the backend interacts with a proxy or a virtual server.  Support for proxy and virtual server backends are scheduled for a future release.


OpenDJ has a robust logging capability that allows server information to be retained in various repositories.  The most common loggers are as follows:

  • Access Logger – stores server operations (binds, searches, modifications, etc.)
  • Error Logger – stores warnings, errors, and significant events that occur with the server
  • Debug Logger – records debug information when the server is run with debugging enabled and Java assertions are active.

Multiple loggers can be configured for each of these and each logger may be actively storing different information (filtered or not) in different formats in different repositories.

Note:  Some error loggers can be used as an alerting mechanism to actively notify administrators of potential problems.

SASL Handlers

The LDAP protocol supports two methods that clients may use to authenticate to the server:

SASL is an authentication framework that supports multiple authentication mechanisms including ANONYMOUS, CRAM-MD5, DIGEST-MD5, EXTERNAL, GSSAPI, and PLAIN.

OpenDJ includes a set of handlers that implement each of these SASL mechanisms in order to determine the identity of the client.

Access Control

OpenDJ contains an access control module that is used to determine if a client is permitted to perform a particular request or not.

Password Storage

OpenDJ includes several password storage modules that can be used to obscure user passwords using a reversible or one-way algorithm.  Password storage schemes encode new passwords provided by users so that they are stored in an encoded manner. This makes it difficult or impossible for someone to determine the clear-text passwords from the encoded values.  They can also be used to determine whether a clear-text password provided by a client matches the encoded value stored in the server.

Password Complexity

OpenDJ includes a series of modules that define logic used to determine whether a user’s password meets minimum requirements or not.

Syntax and Matching Rules

Attributes must follow a particular syntax and search filters determine matches based on a set of matching rules.  OpenDJ contains a set of syntaxes and matching rules that define the logic for dealing with different kinds of attributes.

Database Cache

Interacting with data in memory is much faster than interacting with data on disk.  As such, OpenDJ includes a database caching module that loads directory data into memory.

Check out ForgeRock’s website for more information on OpenDJ or click here if you are interested in attending one of ForgeRock’s upcoming training classes.

Directory Servers vs Relational Databases

August 14, 2008 Leave a comment

An interesting question was posed on LinkedIn that asked, “If you were the architect of LinkedIn, MySpace, Facebook or other social networking sites and wanted to model the relationships amongst users and had to use LDAP, what would the schema look like?”

You can find the original post and responses here.

After reading the responses from other LinkedIn members, I felt compelled to add my proverbial $.02.

Directory Servers are simply special purpose data repositories. They are great for some applications and not so great for others. You can extend the schema and create a tree structure to model just about any kind of data for any type of application. But just because you “can” do something does not mean that you “should” do it.

The question becomes “Should you used a directory server or should you use a relational database?” For some applications a directory server would be a definite WRONG choice, for others it is clearly the RIGHT one, for yet others, the choice is not so clear. So, how do you decide?

Here are some simply rules of thumb that I have found work for me:

1) How often does your data change?

Keep in mind that directory servers are optimized for reads — this oftentimes comes at the expense of write operations. The reason is that directory servers typically implement extensive indexes that are tied to schema attributes (which by the way are tied to the application fields). So the question becomes, how often do these attributes change? If they do so often, then a directory server may not be the best choice (as you would be constantly rebuilding the indexes). If, however, they are relatively static, then a directory server would be a great choice.

2) What type of data are you trying to model?

If your data can be described in an attribute: value pair (i.e., name:Bill Nelson), then a directory server would be a good choice. If, however, your data is not so discrete, then a directory server should not be used. For instance, uploads to YouTube should NOT be kept in a directory server. User profiles in LinkedIn, however, would be.

3) Can your data be modeled in a hierarchical (tree-like) structure?

Directory servers implement a hierarchical structure for data modeling (similar to a file system layout). A benefit of a directory server is the ability to apply access control at a particular point in the tree and have that apply to all child elements in the tree structure. Additionally, you can start searching at a lower (child element) and increase your search performance times (much like selecting the proper starting point for the Unix “find” command). Relational databases cannot do this. You have to search all entries in the table. If your data lends to a hierarchical structure then a directory server might be a good choice.

I am a big fan on directory servers and have architected/implemented projects that sit 100% on top of a directory, 100% on top of relational databases, and a hybrid of both. Directory servers are extremely fast, flexible, scalable, and are able to handle the type of traffic you see on the Internet very well. Their ability to implement chaining, referrals, web services, and a flexible data modeling structure make them a very nice choice to use as a data repository to many applications, but I would not always lead with a directory server for every application.
So how do you decide which is best? It all comes down to the application, itself, and the way you want to access your data.

A site like LinkedIn might actually be modeled pretty well with a directory server as quite a bit of the content is actually static, lends well to an attribute:value pair, and can easily be modeled in a heirarchical structure. The user profiles for a site like facebook or YouTube could easily be modeled in a directory server, but I would NOT attempt to reference the YouTube or facebook uploads or the “what are you working on now” status with a directory server as it is constantly changing.

If you do decide to use a directory server, here are the general steps you should consider for development (your mileage may vary, but probably not too much):

  1. Evaluate the data fields that you want to access from your application

  3. Map the fields to existing directory server schema (extend if necessary).

  5. Build a heirarchical structure to model your data as appropriate (this is called the directory information tree, or DIT)

  7. Architect a directory solution based on where your applications reside thorughout the world (do you need one, two, or multiple directories?) and then determine how you want your data to flow through the system (chaining, referrals, replication)

  9. Implement the appropriate access control for attributes or the DIT in general

  11. Implement an effective indexing strategy to increase performance

  13. Test, test, test