Der Zugriff auf LDAP-Server aus Java erfolgt, auch wenn es durchaus Alternativen gibt, in den allermeisten Fällen mit JNDI (Java Naming and Directory Interface). Bei der Benutzung dieser Schnittstelle macht man ähnliche Erfahrungen wie mit reinem JDBC (Java Database Connectivity): Verbindungen müssen geöffnet und geschlossen, an jeder Stelle Checked Exceptions behandelt und Suchergebnisse mühsam iteriert werden. Das Spring Framework ist bei Entwicklern unter anderem beliebt, weil sie durch Templates von derartigen Lasten größtenteils befreit werden, im Falle von JDBC etwa durch das JdbcTemplate. Mit Spring LDAP steht eine entsprechende Lösung auch für Verzeichnisdienste zur Verfügung, wie Spring selbst unter der Apache-Lizenz.
JndiTemplate vs. LdapTemplate
Das schon länger in Spring enthaltene JndiTemplate adressiert in erster Linie den Namensdienstaspekt von JNDI und erleichtert zum Beispiel den Zugriff auf konfigurierte Ressourcen wie Datenbankverbindungen. Grundsätzlich könnte man damit auch allgemeine LDAP-Operationen absetzen, indem man die Schnittstelle JndiCallback implementiert, dem Ansatz fehlt aber jede Eleganz. Das LdapTemplate von Spring LDAP hingegen setzt ebenfalls auf JNDI auf, bietet aber unmittelbare Unterstützung für wichtige LDAP-Operationen an. Hierzu zählen neben dem Anlegen, Manipulieren und Ändern von Informationen in einem Verzeichnis vor allem das Suchen von Einträgen mit bestimmten Attributwerten.
Das Template orientiert sich an den Methodensignaturen der JNDI-Schnittstelle DirContext, ohne dabei allerdings alle überladenen Methoden (insbesondere von search) anzubieten. Des Weiteren fehlen LDAP-spezifische Methoden, die in der JNDI-Schnittstelle LdapContext vereinbart sind, zum Beispiel für Extended Operations (Stichwort StartTLS). LdapTemplate bietet Schnittstellen für Callbacks an, mit denen man an die fehlende Funktionalität dieser beiden Interfaces trotzdem herankommt.
Zum Leistungsumfang des Frameworks zählen darüber hinaus Hilfsklassen, um LDAP-typische Dinge wie DNs und Suchfilter zu konstruieren, Callbacks, um etwa Suchergebnisse in Java-Objekte umzuwandeln, und Integrationen für einzelne fortgeschrittene JNDI-Themen, wie zum Beispiel Object Factories. Verwendet werden kann die Lösung innerhalb von Spring-Anwendungen im Stile der üblichen Bean-Definitionen. Abbildung 1 zeigt eine typische Konfiguration in der Spring IDE. Auch der Einsatz als "klassische" Bibliothek über den direkten API-Zugriff ist denkbar. Eine Abhängigkeit zum Spring Framework besteht aber in jedem Fall.
Das schon länger in Spring enthaltene JndiTemplate adressiert in erster Linie den Namensdienstaspekt von JNDI und erleichtert zum Beispiel den Zugriff auf konfigurierte Ressourcen wie Datenbankverbindungen. Grundsätzlich könnte man damit auch allgemeine LDAP-Operationen absetzen, indem man die Schnittstelle JndiCallback implementiert, dem Ansatz fehlt aber jede Eleganz. Das LdapTemplate von Spring LDAP hingegen setzt ebenfalls auf JNDI auf, bietet aber unmittelbare Unterstützung für wichtige LDAP-Operationen an. Hierzu zählen neben dem Anlegen, Manipulieren und Ändern von Informationen in einem Verzeichnis vor allem das Suchen von Einträgen mit bestimmten Attributwerten.
Das Template orientiert sich an den Methodensignaturen der JNDI-Schnittstelle DirContext, ohne dabei allerdings alle überladenen Methoden (insbesondere von search) anzubieten. Des Weiteren fehlen LDAP-spezifische Methoden, die in der JNDI-Schnittstelle LdapContext vereinbart sind, zum Beispiel für Extended Operations (Stichwort StartTLS). LdapTemplate bietet Schnittstellen für Callbacks an, mit denen man an die fehlende Funktionalität dieser beiden Interfaces trotzdem herankommt.
Zum Leistungsumfang des Frameworks zählen darüber hinaus Hilfsklassen, um LDAP-typische Dinge wie DNs und Suchfilter zu konstruieren, Callbacks, um etwa Suchergebnisse in Java-Objekte umzuwandeln, und Integrationen für einzelne fortgeschrittene JNDI-Themen, wie zum Beispiel Object Factories. Verwendet werden kann die Lösung innerhalb von Spring-Anwendungen im Stile der üblichen Bean-Definitionen. Abbildung 1 zeigt eine typische Konfiguration in der Spring IDE. Auch der Einsatz als "klassische" Bibliothek über den direkten API-Zugriff ist denkbar. Eine Abhängigkeit zum Spring Framework besteht aber in jedem Fall.
Fehlerbehandlung
LDAP-spezifische Fehler werden von JNDI durch eigene Exceptions dargestellt, wobei ein klares Mapping von Fehlercodes auf die zahlreichen Exceptions existiert. Spring LDAP verpackt diese Exceptions selbst wieder in eine Runtime Exception (Unterklassen von Springs DataAccessException), um den Entwickler von der erforderlichen Behandlung der Fehlersituation zu befreien. Dieses Anliegen hat die Lösung mit anderen Templates innerhalb von Spring gemein. Leider landen in Spring LDAP Version 1.1.2 noch sehr viele Exceptions in einer UncategorizedLdapException, sodass die eigentliche JNDI Exception ausgepackt und untersucht werden muss, wenn an geeigneter Stelle eine detaillierte Fehlerbehandlung erfolgen soll.Dankenswerterweise ist die Abbildung von NamingException auf DataAccessException im LdapTemplate durch Implementierung eines Interfaces anpassbar, und zukünftige Fassungen versprechen hier deutliche Verbesserungen.
