Search

Twitter

Domino Upgrade

VersionSupport end
5.0
6.0
6.5
7.0
8.0
8.5
Upgrade to 9.x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet.
Contemplating to replace Notes? You have to read this! (also available on Slideshare)

Languages

Other languages on request.

Visitors

Useful Tools

Get Firefox
Use OpenDNS
The support for Windows XP has come to an end . Time to consider an alternative to move on.

About Me

I am the "IBM Collaboration & Productivity Advisor" for IBM Asia Pacific. I'm based in Singapore.
Reach out to me via:
Follow notessensei on Twitter
(posts)
Skype
Sametime
IBM
Facebook
LinkedIn
XING
Amazon Store
Amazon Kindle

« Domino Development - Back to Basics - Part 5: Finding data - Collections and Search | Main| Using a web service to send an eMail »

A short history of directory trees

I would like, if I may, to take you on a strange journey: Where did directory trees come from?
This isn't about flowers and bees or our green friends, who missed the evolutionary advantage to emit WIFI signals, but the constructs we rely on for authentication and keeping the network in order, in other words: your directory.

Banyan VINES

In the beginning there was Banyan VINES and StreetTalk. While they are gone, they are fondly remembered. Other than the Wikipedia article I recall, that it needed almost 300k of memory (probably with all services loaded) which wasn't good when 640k was the limit.
At that time it was the only system offering directory services as a tree. Its demise was triggered by Banyan's late awakening to the fact, that requiring a propriety OS to run a directory service will lead to a collapse of hardware support.

Novell eDirectory

Along came Novell's eDirectory (ca. 20 years ago). Originally called NDS (Novell Directory Services) it suffered from teething problems giving room for other entrants. Initially it required a Novell Netware 4.x server and almost missed the boat in TCP/IP support.
Similar to VINES, the propriety OS became an issue and only in 2003 eDirectory became multi-platform. Novell had quite some ideas: HTTP based file sharing (webDAV), access via multiple protocols (via LDAP, DSML, SOAP, ODBC, JDBC, JNDI, and ADSI) and storing any information about any network object, relations and access rights.

Embrace, Extend and Extinguish

However the rise of Windows NT made way for the latest entrant: Active Directory from Microsoft. Using its marketing muscles and aptitude for easy to use interfaces, Microsoft swept the directory market and most followed. While loosely based on Open Standards, Microsoft messed with the Kerberos implementation using their successful embrace, extend and extinguish pattern.

Can you see the forest through the trees?

The biggest innovation in Active Directory is the concept of a Directory Forest. Vines and eDirectory only use a single tree. When you ask around for opinions about the feature, you will find, that any consultant paid by the hour will love it. It introduces complexity and endless hours of configuration. IT managers who know their stuff loath it. So what happened?

The leaky abstraction

IMHO this is a case of Leaky abstraction. VINES stored its data in some ISAM file, Netware eDirectory uses FLAIM (I thought they used Btrieve, but that's a minor detail here), while AD uses the JET engine. Originally shared with MS Access, it got forked into JET Blue instead of the more robust (?) SQL server.
Despite the impressive numbers in the specs JET didn't scale as well as expected, so instead of fixing it, large trees were broken down into smaller trees and regrouped into a forest (Wearing my asbestos underwear for this claim).
So the storage model leaked into the product capabilities. Anyway storing anything extra (which is the whole idea of a directory service) is a perilous undertaking, once added to the schema, it never will get out. This led to fun and entertainment and a whole cottage industry of tool vendors.

Buying a product is not a strategy

So you can follow mainstream (and don't argue, I heard them all before) or give it a really hard thought:
  • What do I want to accomplish?
  • Am I comfortable with Jet Blue?
  • How easy can I take the dependency on a single vendor or do I want to be able to select from a rich heritage?
  • Is my long term strategy better served with open standards?
For user management and authentication LDAP (for your own users) or OAuth and/or SAML (for others) might do a better job. AD doesn't do much for end-point management without additional software, so your are not bound by that. The list goes on.
Happy musing!

Comments

Gravatar Image1 - Directory vendors haven't been paying attention to the social space effectively at all. User-specific and rules-based grouping are integral to how people think of self-organizing sharing systems now, yet no directory has incorporated this massive organic resource into it's authorization and routing structure.

It's a huge wasted opportunity. I really wish someone would get on it.

Disclaimer

This site is in no way affiliated, endorsed, sanctioned, supported, nor enlightened by Lotus Software nor IBM Corporation. I may be an employee, but the opinions, theories, facts, etc. presented here are my own and are in now way given in any official capacity. In short, these are my words and this is my site, not IBM's - and don't even begin to think otherwise. (Disclaimer shamelessly plugged from Rocky Oliver)
© 2003 - 2014 Stephan H. Wissel - some rights reserved as listed here: Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution/NonCommercial/ShareAlike Creative Commons License, with the exception that no rights are granted -- since they are not mine to grant -- in any logo, graphic design, trademarks or trade names of any type. Code samples and code downloads on this site are, unless otherwise labeled, made available under an Apache 2.0 license. Other license models are available on written request and written confirmation.