LDAP vs relational database (Part 2)

A continuation of my previous post on pointing out the advantages of LDAP over relational databases. In this round I address fewer points though delve a bit deeper.

Universal drivers: No vendor specific database drivers are needed as LDAP specifies a standard wire protocol. That is, any vendor’s LDAP client should be interoperable with any other vendor’s directory server. Therefore, the onerous task of obtaining and managing vendor database drivers is no longer necessary.

LDAP controls: Controls provide a mechanism for both the client and the server to send additional information with a LDAP request. A very useful LDAP control is persistent search (not all servers support the control, but it is a common feature). This control notifies the search requester of a change in the search results. For example, if an application centrally stores configuration information in a directory it needs to be notified if the configuration is changed. This is easily accomplished by running a persistent search on the config data - if a change (add, modify, delete, move) occurs the server will asynchronously notify the client. Checkout controls supported by OpenDS.

Directory Service Markup Language (DSML): I'm sure I'll get ribbed for pointing out this one as I haven't seen any production use of DSMLv2 since its introduction in 2002. DSML is simply LDAP translated to XML (typically transported over HTTP). The primary benefits of which are: no LDAP client required, LDAP operations may easily pass through the firewall, and directory operations can be batched together and executed in a single request. We’re going to make interesting use of this capability in the near future with the introduction of a Javascript library that nicely models LDAP and talks DSML. The advantage? This will enable web developers to write browser-based applications that talk directly to OpenDS. Dare I say web 2.0?

URL based searches: Depending on the capabilities of your LDAP client, a standardized URL may be used to execute a search; e.g., ldap://localhost/dc=example,dc=com???(uid=treydrake) returns the entry associated with “treydrake”. With a bit of practice, fine grained entry/attribute retrieval and search criteria is easily expressed on the "web command line". Not quite ReST, but convenient nonetheless.

LDAP schema constructs: I've noted that LDAP schema consists of objectclasses and attributes. A point worth mentioning is that objectclasses are much more flexible than flat RDBMS tables. Specifically, there are 3 types of objectclasses: structural, abstract, and auxiliary. Structural types are concrete classes that represent an LDAP entry. Abstract classes are simply structural parents; i.e., they define attributes for inheritance by more specialized, structural classes. Finally, auxiliary types are supplemental classes that may be associated with structural or abstract classes. To make these concepts concrete consider the typical person example, "inetorgperson" (the LDAP standard defines numerous standard objectclass types, one of which is "inetorgperson"). This type is derived as follows: top -> person -> organizationalPerson -> inetorgPerson. Where top is the parent of all LDAP classes and inetorgperson defines new person attributes and inherits all superior objectclass attributes. Objectclass inheritance is a heck of a lot cleaner than defining numerous tables and linking them together with foreign keys!

Globally unique schema: An interesting aspect of LDAP schema is the identification of objectclasses and attributes as globally unique objects known as OIDs. That is, every attribute and objectclass has both a name and a unique ID. This makes sharing schema objects throughout the enterprise much more precise and traceable as an OID is associated with an authority (a company, standard, etc). For example, I may create an objectclass named "blog" with the OID 1.3.6.1.4.1.26922.1.1. OIDs are also hierarchal; breaking apart the OID, "1.3.6.1.4.1" identifies the object is owned by a private enterprise, "26922" identifies the specific enterprise and the trailing suffix "1.1" is completely defined by the enterprise. An enterprise, having defined a new globally unique object, may then publish a detailed description of the new objectclass for reference by consumers. Clearly, identifying schema elements with collision proof ids versus names is a distinct advantage. Need your own OID namespace? Get one here.

Comments:

Someone told me they once saw a deployment of DSML, but until I see it with my own eyes...

Posted by Pat on February 22, 2007 at 05:31 PM CST #

ok, playing Devil's advocate here - These are all compelling reasons (really), but I can't help but think of the Object DataBase people and how they had all the good reasons you shouldn't really be using RDBMSs... I see one advantage to RDBMS: SQL and one disadvantage to LDAP directories: JNDI...

Posted by Alexis MP on March 03, 2007 at 06:53 AM CST #

Alexis, I hear you. And here's my answer: Resurrecting a Java LDAP API

Posted by Trey Drake on March 22, 2007 at 12:41 PM CDT #

The feature description you gave of an LDAP server implementation sounds somewhat similar to an object database or an XML one. In fact, I often think that using an object database may help while implementing such server.

This leads me to the question: how strong is the integration OpenDS/Berkeley DB ? I am just curious about the difficulty to migrate towards an object database, or a XML database, like Xindice or eXist-db, as a backend. Can you give some details ? Thanks.

Posted by Dominique De Vito on April 03, 2007 at 03:33 AM CDT #

Dominique, the OpenDS "backend" is pluggable. That is, you are free to swap Berkeley DB for the database of your choice provided you implement the appropriate interfaces.This document should clarify our usage of the JE backend. <p/> If you're interested in wiring up a new backend please join the opends project and send your questions to the "users" mailing list.

Posted by Trey Drake on April 03, 2007 at 08:33 AM CDT #

i could not find where in IANA i was supposed to register a private OID. OID's have been one of my primary grievances against LDAP for a long long time, but if there way to get a globally unique private OID, it would go a long way towards making me feel like LDAP and OpenDS was an acceptable place for all structured data, and not just the stuff that has always had an LDAP schema. thusfar my practice has been making up byzantine numbers and assuming it would never be a problem locally.

thanks for hte followup post, its an excellent exploration of how OpenDS does and could in the future meet up against relational systems.

Posted by rektide on May 30, 2007 at 08:18 AM CDT #

You can request a PEN (private enterprise number) from IANA here: http://pen.iana.org/pen/PenApplication.page The prefix is fixed and appended with your PEN. You're then free to append suffixes to uniquely identity your schema. You should not use arbitrary OIDs as you're bound to stomp on someone else's namespace.

Posted by Trey Drake on May 31, 2007 at 04:27 AM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

treydrake

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today