CRUD generico con Java Reflection API, EclipseLink ed ICEFaces

Problema: abbiamo un nutrito insieme di tabelle anagrafiche con struttura simile (solitamente ID, DESCRIZIONE e pochi altri campi), e vorremmo offirire nella nostra applicazione Web le funzionalità CRUD su di esse. Quello che vogliamo assolutamente evitare è la replicazione del codice che offre queste funzionalità per ogni tabella da gestire: in sostanza, si desidera un approccio quanto più generico possibile al problema.

Voglio condividere con voi una soluzione a questo problema a mio avviso molto interessante, che fa uso estensivo delle Reflection API di Java, EJB 3.0, JPA (con EclipseLink 1.20 come persistence engine) per il backend, e IceFaces 1.8 per la parte grafica.

EJB 3.1 : passi avanti verso la maturità

Desidero condividere con voi la sintesi di un interessante articolo pubblicato su TSS di P.Moreira, riguardante la prossima release della versione 3.1 degli EJB. E' stata finalmente rilasciata la versione Proposed Final Draft, siamo ormai prossimi a una versione finale. In questa versione, vengono introdotte una serie di nuove feature, mirate a sfruttare appieno il potenziale di questa tecnologia.

No-Interface View

I Session Bean non sono più obbligati a implementare alcuna interfaccia. Il container EJB fornisce la reference ad una "no-interface view", che permette al client di invocare qualsiasi metodo pubblico sul bean, e assicurando che le transazioni, la sicureza e l'interception si comportino come sempre. Tutti i metodi pubblici del SB sono resi disponibili attraverso la no-interface view, e un client può ottenere la reference a questa view attraverso dependency injection o JNDI lookup (come avviene attualmente per le interfacce locali e remote). La differenza è che, a differenza delle local and remote view, in cui la reference consiste nelle rispettive interfacce locali/remote, la reference alla no-interface view è tipata come la classe stessa del SB.