Dal 17 giugno 2005 c’è un modo standard, indipendente dall’implementazione, per leggere e scrivere su un repository di contenuti da codice Java: la specifica JSR-170, pubblicata come Content Repository for Java Technology API nel package javax.jcr. Prima di quella data ogni sistema di Enterprise Content Management (ECM) esponeva la propria API proprietaria, e spostare un’applicazione da un repository all’altro voleva dire riscriverne lo strato di accesso ai dati. Qui leggo la specifica e cosa cambia, in concreto, per chi costruisce gestione documentale su software libero.

Contesto

Un repository di contenuti sta sopra il database relazionale: gestisce documenti, cartelle, metadati, versioni, relazioni, ricerca full-text e controllo d’accesso a grana fine come servizi nativi, invece di lasciarli all’applicazione. Documentum, Microsoft SharePoint e gli altri sistemi ECM commerciali offrono questi servizi da anni, ognuno con un modello dati e un’interfaccia propri. Il costo non è solo la licenza, è il vincolo. Quando metadati, regole e workflow finiscono dentro l’API di un fornitore, cambiare prodotto significa migrare l’intero strato applicativo.

JSR-170 nasce per rompere questo accoppiamento. La specifica l’ha guidata David Nuescheler di Day Software dentro il Java Community Process: draft pubblico nel maggio 2004, proposed final draft a febbraio 2005, final release a giugno 2005. L’idea è quella che JDBC ha portato all’accesso ai database relazionali: una sola API, molte implementazioni, codice applicativo portabile.

Com’è fatta la specifica

JSR-170 definisce un grafo di nodi (Node) e proprietà (Property) a cui si accede tramite una Session aperta su un Workspace. Ogni nodo ha un tipo (NodeType) che ne vincola le proprietà e i figli ammessi: è il meccanismo con cui modelli un “contratto”, una “fattura” o una “procedura” senza toccare lo schema del database sotto. Le proprietà sono tipizzate (stringa, data, binario, riferimento) e i riferimenti tengono insieme il grafo.

La specifica è stratificata. Il Livello 1 è di sola lettura: lettura di nodi e proprietà, attraversamento del grafo, ricerca. Il Livello 2 aggiunge scrittura, spostamento, copia e gestione dei tipi di nodo estendibili. Sopra i due livelli ci sono i feature block opzionali — versioning, transazioni JTA, query SQL, locking esplicito, osservazione degli eventi sul contenuto. Ogni implementazione dichiara quali blocchi offre; l’applicazione chiede al Repository cosa ha a disposizione, invece di darlo per scontato.

La stratificazione è la parte che mi interessa. Sotto la stessa interfaccia convivono implementazioni minimali — un repository di sola lettura che espone un filesystem — e repository completi. Un’applicazione che usa solo il Livello 1 gira su entrambi.

La specifica non è l’implementazione

JSR-170 è un’API, non un prodotto. Senza un’implementazione libera resterebbe un documento. L’implementazione di riferimento è Apache Jackrabbit, nato nel codice di Slide come reference implementation della specifica e ribattezzato nel settembre 2004, quando è entrato in incubazione all’Apache Software Foundation. La versione 0.9 (incubating) è uscita a febbraio 2006 e il progetto sta diventando top-level proprio in questi giorni, con Roy Fielding come chair del PMC.

Qui sta il valore pratico della standardizzazione. Day Software, l’azienda dello spec lead, ha la propria implementazione commerciale; Apache Jackrabbit è la versione libera sotto licenza Apache 2.0; altri sistemi ECM possono esporre javax.jcr sopra il loro motore. Un caso che mi sembra indicativo è Alfresco, l’ECM open source uscito nel 2005 da John Newton — co-fondatore di Documentum — con doppia licenza (community GPL ed enterprise commerciale). Alfresco poggia su Lucene per la ricerca e Hibernate per la persistenza, e sta costruendo un’interfaccia JSR-170 sopra il proprio repository: la conformità è in corso, non ancora completa. La stessa applicazione scritta sopra javax.jcr può, in linea di principio, girare su Jackrabbit in sviluppo e su un ECM completo in produzione.

Conviene dire con precisione cosa lo standard garantisce e cosa no. Garantisce che il codice che usa l’API si compili e funzioni su implementazioni diverse, per i livelli e i blocchi che entrambe dichiarano. Non garantisce che due repository abbiano la stessa semantica nei dettagli che la specifica lascia aperti, né che i modelli di tipi di nodo siano interscambiabili senza una mappatura. A essere portabile è l’interfaccia, non il contenuto già caricato.

Cosa cambia per la gestione documentale open source

La conseguenza pratica è che la scelta dell’implementazione si stacca dalla scelta dell’API. Un’organizzazione può prototipare su Jackrabbit, modellare i tipi di contenuto, scrivere regole automatiche e workflow sopra javax.jcr, e poi scegliere il motore di produzione in base a volumi, supporto e requisiti operativi senza riscrivere lo strato applicativo. Per chi costruisce su software libero questo abbassa il rischio dell’adozione: studi il codice a fondo prima di impegnarti, e ti leghi a un’API pubblica anziché al formato interno di un fornitore.

Cambia anche cosa vuol dire “open source” per un ECM. Avere il codice disponibile non basta: se l’API di accesso è proprietaria, il vincolo resta a livello applicativo anche con i sorgenti aperti. Un repository libero che espone un’interfaccia standard sposta il punto di indipendenza dal possesso del codice al possesso dell’integrazione.

Limiti

La versione 1 di JSR-170 lascia fuori parecchio. Non standardizza le ACL e il controllo d’accesso oltre quanto serve ai due livelli; non definisce un formato di interscambio del contenuto tra repository; non copre la federazione di più repository sotto un’unica sessione. La gestione dei tipi di nodo è potente, ma la loro portabilità tra implementazioni dipende da convenzioni, non dalla specifica. E un’API standard non dice niente sulle prestazioni: due implementazioni conformi possono comportarsi in modo molto diverso sotto carico.

Resta che, da giugno 2005, c’è un punto fermo. Per la gestione documentale costruita su software libero è il livello su cui conviene programmare, qualunque repository finisca sotto.

Immagine di copertina: Logo storico di Sun Microsystems: la scritta “SUN” in viola, composta come ambigramma con le lettere disposte a 90 gradi — logo di Sun Microsystems, pubblico dominio — https://commons.wikimedia.org/wiki/File:Sun-Logo.svg