Obiettivo del Plain Old Java Object è di uniformare i modelli di data persistence per Java. Il punto di incontro di Ejb e Jdo.
28 settembre 2004
Sun è al lavoro per uniformare i modelli di data persistence relativi allo sviluppo Java.
Lo fa sia coralmente, sia con l’iniziativa, quasi personale, dei responsabili dei vari gruppi che afferiscono al mondo Java e che si muovono in direzione della comunità tecnologica, chi portando una specifica, chi un’altra.
Esistono, di fatto, modelli di data persistence differtenti per gli Enterprise Java Beans 3.0, proposti dalla Java Specification Request (Jsr) 220 e per i Java Data Objects (Jdo) avanzati dalla Jsr 243.
Già questa semplice dicotomia è, secondo gli stessi coordinatori delle Jsr, di nocumento al movimento comunitario che ruota attorno a Java, perché genera incertezze e discussioni a sfondo pratico.
Per uscire dal guado Sun ha pensato di creare, con il contributo della comunità stessa, un singolo modello di data persistence per Java: Pojo, ovvero Plain old Java object.
L’obiettivo tecnico che si prefigge Pojo è quello di fornire un singolo strumento per la mappatura a oggetti e relazionale di tutte le applicazioni Java, siano esse lavorate in J2Se o J2Ee.
Sun pensa di concludere il lavoro contestualmente al rilascio di J2Ee 5.0, ovvero per il 2006.
Gli Ejb (cioè le specifiche Api per la costruzione di applicazioni distribuite, a componenti e multilivello) da una parte e gli Jdo (cioè le classi Java mappate per essere un persistent data store, come un database relazionale) hanno due anni per convergere verso un modello unico.
Il percorso di incontro potrebbe cominciare proprio dalla seconda “stazione”: l’expert group del Jdo rilascerà Jdoql (Java data objects query language) proprio per interagire con il modello di persistence previsto per la tecnologia Pojo.
Pojo che, una volta ultimato, sarà rilasciato secondo il modello di licenza di J2Ee.
