ldap-utility: integrazione LDAP in Java senza boilerplate

Il problema

Quasi ogni applicazione aziendale, prima o poi, deve parlare con una directory: autenticare le persone contro Active Directory, leggere gruppi e attributi, mantenere allineate le anagrafiche. In Java questo significa quasi sempre riscrivere lo stesso codice: aprire un contesto JNDI, comporre filtri di ricerca a mano, iterare su NamingEnumeration, estrarre attributi uno per uno, e ricordarsi di chiudere tutto anche quando qualcosa fallisce.

È codice noioso, ripetitivo e sorprendentemente facile da sbagliare. Peggio ancora, tende a essere difficile da testare: per verificarlo serve una directory vera, e questo basta a far sì che la maggior parte dei progetti non lo testi affatto.

Le scelte di progetto

Mapping dichiarativo invece di estrazione manuale. Una ricerca restituisce direttamente una lista di oggetti Java tipizzati, non una struttura di attributi da scartabellare. Chi usa la libreria descrive cosa vuole ottenere; la traduzione da attributi LDAP a campi dell’oggetto resta un dettaglio interno.

Un server LDAP in memoria dentro la libreria. È la decisione che considero più importante del progetto. Rendere i test eseguibili senza infrastruttura esterna cambia la probabilità che quei test vengano scritti davvero: se provare il codice richiede una directory aziendale raggiungibile, semplicemente non verrà provato.

Generazione delle classi a partire dagli attributi. Ogni directory ha il proprio schema. Anziché imporre un modello dati rigido, la libreria genera il sorgente Java corrispondente agli attributi effettivamente presenti, riducendo il lavoro manuale nella fase di adozione.

Superficie pubblica volutamente ridotta. Ricerca, autenticazione, generazione. Nient’altro. Una libreria di utilità che cresce senza criterio diventa un framework, e un framework va mantenuto: preferisco che faccia poche cose e che restino stabili nel tempo.

L’artefatto

La libreria è distribuita su Maven Central, il registro ufficiale dell’ecosistema Java. Pubblicarci non è un caricamento libero: richiede la verifica della proprietà del dominio usato come groupId, la firma GPG degli artefatti e il rispetto dei requisiti su metadati, sorgenti e javadoc. È una barriera che vale la pena citare, perché dice della cura del rilascio più di qualunque numero di download.

Il codice è pubblico con licenza MIT: chiunque può leggerlo, verificarlo, usarlo in produzione e modificarlo.