Non mi piace molto. Non mi piace molto perchè a mio avviso è un pò limitante nella semantica degli oggetti che possono essere salvati nel repository, nella fattispecie i "link" agli altri nodi sono..esattamente questo, dei link. Molti obietteranno che questo è esattamente il comportamento di un file system, il problema è che un content repository NON è un file system.
Nella pratica un content repository è utilizzato per salvare bit di dati in una struttura gerarchica e dinamica, con possibilità di modificare i nodi a runtime (un modo piuttosto diverso --e secondo me migliore in molti casi-- di un RDBMS tradizionale). Devo ancora scavare più a fondo, ma mi sembra che la gerarchia, cioè la possibilità di salvare nodi come figli di altri nodi, venga vista come una sorta di mappatura della gerarchia delle classi su una struttura simil-file system.
Ok, se è effettivamente così mi piace ancora meno.
Ora, finalmente, una breve panoramica su "come dovrebbe essere un content repository per il cheng":
- gerarchico, ma nel senso di "posizione" non di "tipo";
- con possibilità di specificare la semantica dei nodi collegati:
- composizione: il nodo figlio non ha senso di esistere senza il padre (e quindi è "posizionato" come figlio del nodo a cui appartiene);
- aggregazione: il nodo collegato è un'entità a se stante, quindi può essere posizionato dove vuole; il nodo aggregante mantiene un link ad esso;
- semistrutturato: i nodi possono (e spesso è molto meglio che lo facciano) specificare un "tipo", anche se in questi casi sarebbe meglio chiamarlo "prototipo", al quale possono essere aggiunte proprietà senza dover necessariamente rivedere l'infrastruttura (e mi pare che questo punto sia soddisfatto);
- mi piace molto anche l'idea dei "mixin", già implementata: un nodo può soddisfare diversi mixin, che altro non sono che ulteriori prototipi che specificano dati addizionali (erediarietà multipla? no, il nodo ha un prototipo solo e molti mixin..non è corretto, ma si possono grosso modo mappare mixin con le interfacce di java --e non a caso uno dei mixin di default di alfresco è versionable, notate una certa somiglianza della nomenclatura con le interfacce che comunemente si creano in java? (hint: *able)-- ).
Tra parentesi, un sistema del genere è anche come salverei le informazioni di un'applicazione web, ed avrebbe in effetti anche la pregevole proprietà di poter essere esposto tramite servizi rest piuttosto facilmente.
Certo, esistono progetti molto ambiziosi sullo storage di dati esposto tramite servizi rest, piuttosto che tramite "driver" proprietari. Ad esempio couchdb (incubato da apache e il cui principale sviluppatore è stato "acquisito" da IBM per lavorare a tempo pieno sul progetto..e vorrà dire qualcosa), il difetto che trovo in questa soluzione è che non è gerarchico: i dati sono salvati in uno "flat space".
Detto questo aspetto che qualcuno implementi il jsr 283 (content repository 2.0), per vedere in che direzione si è mossa la comunità java...
