JNDI vs LDAP

[blahblahblahh]

So, I was doing my periodic surf of the Sun sites, looking for what's changed, what's new and wonderful, and possibly worth using, and JNDI caught my attention.

Last time I saw it, it wasn't much to us, but since then we've taken to using LDAP a lot more extensively than we'd originally intended. JNDI seems to solve or improve several of the complaints we've had with LDAP (mainly along the lines of "the code to use it is a bitch to maintain", and "DN syntax gives you headaches unless you work with it every day"). Note: LDAP's great, but it's still a PITA if you're only trying to use it in a non-mainstream branch of your system, because it just has a different way of looking at *everything* compared to what you're used to. So, it's expensive (in time, effort) to maintain/use.

Has anyone here got any comments or experience of using JNDI they'd care to share? Our usage would be a bit unusual, but for other games devs JNDI could be an excellent replacement for LDAP user-accounts systems, or even as a basis for a game-logic system. A good research project, perhaps...

It seems, from Sun's docs, that JNDI is simply two things:

- a wrapper of LDAP into a neat OOP API
- a federation/composite of LDAP with other directory protocols into a common API

Both of which seem emminently sensible, and neither of which I can see providing opportunities for Sun to produce a slow implementation (having a bottleneck where we would be using this would be lethal).

[kevglass]

Wow, JNDI, what a blast from the past. A few years ago (read about 4) Endolf and myself worked on a full scale enterprise project for a large telecom.

JNDI like most Java APIs tends to try and abstract away from the actual implementation for optimal use. LDAP servers (much like CORBA ORBs) work by obeying the base RFC standard and then implementing which of the various extensions (RFCed and Custom) that they feel like.  The problem being that the method used for the detection of extensions is something the LDAP servers at the time didn't agree on.

The hardest thing we found was attempting to get any sort of portability between the small selection of LDAP servers that exist. The DN syntax is a bit odd but its fairly quickly understood and accepted. One major concern is the manipulation of security tokens. A couple of the servers we tried were trying to push ACLs as a "standard" but then a Lucent developed server decided to completely ignore that.

A collegue at the time described the JNDI API like this:

"You know how far away from being useful JDBC is? If you went 2 thirds of the way towards usefulness you'd find JNDI"

EDIT: Reading this through before I post this seems quite negative. Actually, I quite liked LDAP and JNDI for the things we were doing which was essentially mapping objects into the directory server which fits rather well.

Kev

[blahblahblahh]

The two things I'm interested in using JNDI for are:

  - Location of things in a distributed environment; a typical LDAP role (read VERY frequently - on average approx once for every single game-action, but altered very infrequently - on average each item changes at most once every 20 minutes, perhaps as frequently as every few minutes in rare situations), but the amount of information stored in the objectclass is near to trivial - this would be PURELY a locator service, NOT a retrieval service, so the LDAP DB would be merely a conveniently richly searchable directory, and not contain any end-data.

  - Chucking all authentication (A1) and authorization (A2) off to an LDAP server. Authentication is trivial, but authorization is sufficiently complex to do that it would be convenient not to bother (not to mention quite nice to do LDAP-compatible A1 and A2 as a "feature", although so far only one sales prospect has ever known what LDAP was, so perhaps this would be an "anti feature") At the moment, we're running a trivial RDBMS for A1, and a decoupled semi-tree-structured RDBMS for A2.

(nb: for A2 we have: users (multiple group membership), user-groups, resources (single group membership), resource-groups, user-group to resource-group ACL's, and then arbitrary extra groupings layered on top in order to keep group-memberships small for the poor human admins )

And then there's all the hassle of A3 (admin) which we've only got rudimentary standard tools for. Integrating a decent A3 set of tools onto the A2 layer is a current and ongoing challenge, with many different options. Which is why we've standardized on nothing (since different licensees have very different desires and are happy doing their own).

So...I think for the primary use-case we're fine with the lowest-common-denominator of LDAP.

For the other one, I'm not sure what we'd need in terms of LDAP features. I've never done much LDAP auth outside of client-server stuff using the secure layer - but this would be all internal to a cluster, so AFAICS there's no need for any of that.

And JNDI claims to be LDAPv3 compatible anyway. There were a lot of improvements in 1.4.x (including the addition of basic stuff like pooling, and some new services like DNS in the standard JVM distribution)