Upgrade "pulito" di un database "sporco" con hibernate

Interessante articolo, almeno dal punto di vista strettamente pratico, sul come aggiornare la struttura di un database legacy, o comunque esistente e non modificabile, usando Hibernate e qualche altra strategia da db admin.

Lo scenario di partenza è quello in cui si opera, usualmente, sia nell'ambito dei system integrator che durante l'evoluzione naturale di un software.

Quindi, supponete di avere un database, non normalizzato,
ricco delle solite porcate generate da evoluzioni incontrollate "perchè le ha chieste il cliente".

Inoltre, supponete che al database accedano anche altre applicazioni che non potete modificare.

Infine, supponete di voler costruire una nuova applicazione bella bellina, tutta perfettina che vuole uno schema normalizzato e che tanto desidera usare Hibernate per l'accesso al database.

Bene questo articolo è esattamente quello che fa per voi.

L'approccio usato è un misto di viste ausiliare, stored procedure e mappature Hibernate sulle stored procedure.

Quello che otterrete alla fine è ben esplicitato da questo disegnino.



Volendo si potrebbe anche arguire che la logica di normalizzazione si poteva spostare in uno strato DAO, magari gestito da EJB3, ma comunque l'esempio è molto carino e pragmatico.

Consigliato per tutti quelli che hanno a che fare quotidianamente con "il vecchio database" o con "quello schifo di database del gestionale xyz".

Ubuntu Feisty Fawn et Sun

Sun supporta e supporterà nativamente la distribuzione dei vari pacchetti java (JDK, Glassfish, Netbeans, Derby...) nella nuova Ubuntu uscita ieri (appena cala il traffico aggiorno anche la mia ;-) ).

Ok, direte, dove sta la novità? In effetti si faceva tranquillamente anche prima aggiungendo il repository multiverse. La differenza è che adesso i ".deb" di Java sono supportati nel repository ufficiale direttamente da Sun.

Quindi... pronti, ai posti, via

sudo apt-get install jdk6

Mutare o non mutare: questo è il dilemma

L'immutabilità di una classe è un aspetto fondamentale della progettazione in Java (e in generale in qualsiasi linguaggio OO) che raramente si insegna ma che ogni giorno, spesso incoscientemente, si incontra.

Considerate ad esempio la classe String, createne un oggetto, e provate a cambiarne lo stato senza creare un nuovo oggetto String. Ad esempio provate ad aggiungerci un carattere in coda o a modificare il primo. Ci siete riusciti?

E' impossibile che ci riusciate, perchè String è immutabile. Ogni qual volta invocate un metodo che la modifica, ad esempio concat, ottenete sì il risultato atteso ma in un nuovo oggetto String.
I più smaliziati, sanno che quando si operano elaborazioni su stringhe conviene usare StringBuffer che altro non è che la versione mutabile di String. Ossia una stringa modificabile senza passare per la creazione di nuove istanze della medesima. In pratica un arraylist di caratteri sotto il vostro totale controllo.

Quanto detto per String vale in generale e rientra nel più generico principio architetturale della mutabilità o dell'immutabilità di una classe.

Detto più formalmente:

• una classe è mutabile se avendo un riferimento ad un suo oggetto posso cambiarne lo stato
• una classe è immutabile se avendo un riferimento ad un suo oggetto non è possibile cambiarne lo stato

E' una scelta architetturale che ha conseguenze molto importanti. Pensate ad esempio cosa accade quando voi tornate come risultato di un metodo un riferimento ad una struttura dati interna del vostro oggetto (ad esempio una List privata): l'oggetto chiamante può cambiarvi lo stato senza che voi lo sappiate. Ci son due modi per evitare la cosa: ritornare un clone (metodo clone() di Object) della vostra struttura interna o rendere la struttura ritornata immutabile.

Vi segnalo questi tre articoli [uno, due, tre] come buona introduzione alla creazione e all'uso delle classi immutabili (occhio alla questione del final)

Non ho dubbi che dopo la lettura, comincerete anche voi a vedere mutabilità e immutabilitò ovunque e a chiedervi di fronte ad ogni classe: come la faccio, mutabile o immutabile.

Questo è il dilemma.

Costruisciti il tuo Google. Oggi.

Finalmente, dopo mesi di "relax", è stata rilasciata la versione 0.9 di Nutch.

Nutch è l'implementazione (naturalmente in Java) di un motore di ricerca completo, basato sull'architettura di Google.

Il progettone include quindi un crawler, un sistema di indexing (basato su Lucene 2), un'implementazione dell'algoritmo di PageRank efficiente (il modello di Markov è risolto online, senza costruire in memoria alcuna matrice delle probabilità) e un sistema parallelo di searching sugli indici, tipicamente da consultare via servlet.

La parte più affascinante di Nutch è l'architettura concepita per lavorare in un cluster arbitrariamente grande di macchine e ispirata al paradigma Map/Reduce usato da Google.

Dopo la versione 0.6 di nutch il motore di Map/Reduce è stato implementato in un progetto a parte, chiamato Hadoop (giusto per la cronaca: i nomi li sceglie il capoprogetto ascoltando i mugugni del suo bambino mentre gioca, Hadoop è il nome del suo elefantino).
Il grosso del lavoro fatto in questi mesi è stato principalmente su Hadoop, ed è solo per questo motivo che i progressi di Nutch sembravano congelati.

Il capoprogetto di tutta la baracca e Doug Cutting, creatore di Lucene e attualmente dipendente di Yahoo. Partecipano al progetto molti programmatori di Yahoo e altra gente particolare come alcuni personaggi del JPL Nasa di Pasadena (quelli dei robotini andati su marte).

Hadoop infatti è sia un framework generico di computazione distribuita molto potente, che un file system distribuito efficiente e fault-tollerant liberamente ispirato al Google File System GFS. Va da sè che Hadoop può essere utilizzato per qualunque sistema di calcolo su terabyte di dati, a patto che che gli algoritmi siano disegnati secondo un paradigma Map/Reduce.

Ultima chicca: Nutch sarà il cuore di Wikia, il motore di ricerca libero che stanno costruendo i signori di wikipedia.


P.S. Attenzione, Nutch è un po' macchinoso da installare. La prima volta seguite passo passo questa pagina per evitare di farvi male

P.P.S. Potrebbe venirvi la voglia di creare un cluster con delle macchine virtuali (come feci io qualche mese fa)..... sappiate che l'overhead vi deluderà. Nutch inizia a pompare ferocemente dalle 3-4 macchine fisiche in su ;)

Tomcat 6 e le 16.000 connessioni concorrenti

Segnalo questo articolo sulle performance di Tomcat 6.
L'articolo descrive la nuova architettura di gestione delle connessione basata su NIO e java.concurrent.

Inoltre vengono illustrati i risultati di un test di stress comparato tra Tomcat, Jetty e Glassfish.
Tomcat svetta riuscendo a mantenere 16.000 connessioni keepalive contemporaneamente.
Impressionanti anche i tempi di accettazione di 4000 connessioni.
Tomcat le accetta praticamente senza ritardo, mentre gli altri due s'inceppano...

Non mi ero mai interessato a questo tipo di misura, ma immaginavo (sbagliando) che si riuscissero a gestire numeri molto più piccoli con un solo server.

Due notiziette per GWT e Hibernate

Oggi son di corsa e vi lascio solo due notiziole mignon.

Hibernate

E' stata rilasciata una nuova versione (minor) di Hibernate, la 3.2.3ga
Le novità sono:

• due nuovi generatori
  
• la certificazione per il database Teradata (non l'avevo mai sentito prima...)
• i soliti fix

Chiaramente se usate 3.2.x in qualche progetto, vi basta sostituire il jar con quest'ultimo per fixare i bug.

GWT

Dan Morrill, dello staff del Google Web Toolkit, ha scritto un interessante articolo sulla sicurezza per applicazioni ajax in GWT.
Sinceramente non ho ancora trovato il tempo di leggerlo completamente, ritornerò sull'argomento uno dei prossimi giorni.

Bye!

GWT 1.4: upgrade massivo in arrivo

Introduco rapidamente GWT per chi non lo conoscesse. Google Web Toolkit è un progetto opensource portato avanti da uno staff Google che consiste in un compilatore Java-to-Javascript e un insieme di componenti pronti all'uso.

Tallono costantemente l'avanzamento dei lavori, in quanto credo sarà uno dei framework che vincerà la pazza corsa verso lo standard de facto delle tecnologie Ajax.

In GWT l'interfaccia grafica viene realizzata in Java puro, in stile simil-Swing. Quindi i componenti grafici sono classi, il pattern observer è usato per gestire gli eventi, eccetera eccetera. In più, sono stati introdotti altri adattamenti al mondo dei browser, come le chiamate asincrone al web server e il wrapping del javascript.

Il vantaggio di GWT è che la programmazione è fatta in Java ed è quindi sottoposta a compilazione, per cui tutti i controlli di tipo sono strong e, inoltre, potendosi avvalere di un IDE standard (leggi Eclipse) è possibile costruire codice solido e complesso con facilità.
GWT fornisce inoltre un viewer, che altro non è che un interprete, che consente di testare il codice graficamente prima ancora di eseguire la compilazione in Javascript definitiva.
Una volta compilato il tutto, invece, si ottiene una serie di javascript pronti da deployare sul web-server, già adattati ai vari browser e coincidenti con quanto testato con il viewer di sviluppo.

Il mio parere è che l'uso di un compilatore così concepito va a favore non tanto della velocità di sviluppo (ci sono librerie javascript fatte meglio per questo scopo), ma dello sviluppo di applicazioni complesse (da GMail in sù, per capirci).

Ci sarebbero altre cose su cui soffermarsi, come le modalità di serializzazione verso il server o l'interfaccia nativa verso javascript. Ma non voglio dilungarmi ancora in questa introduzione, in quanto lo scopo di questo post è avvicinarvi a me nell'attesa della versione 1.4 ;)

Infatti ,se la 1.3 non ha portato grandi nuove features, perchè è stata incentrata sul completo rilascio opensource della suite, la 1.4 sarà una versione features-rich.

Qui trovate il tracking delle modifiche in corso. Come potete osservare sono un'enormità anche se notevolmente in ritardo rispetto alla data di rilascio (marzo).

Per avere un'idea più rapida (ma non allineata su tutti i fronti) delle novità in arrivo, date un occhio alla pagina di progetto del wiki.

Credo manchi solo una cosa per il boom definivo, una maggiore attenzione sui meccanismi di deploy. Intendo cioè, task ant dedicati e maggiore integrazione con l'IDE e gli application server. Se avete provato a metterci mano, credo converrete con me nella "macchinosità" necessaria per compilare e deployare il tutto in un AS.

Se nel frattempo non vi va di compilarvi il trunk... Buona attesa! ;)

Tutorial su Java 6 compiler API

Segnalo un interessante e chiaro tutorial sull'uso delle compiler API, introdotte in Java 6.

Le compiler API, definiscono un interfaccia unificata con cui interagire verso un compilatore Java. E' possibile cioè, a runtime, lanciare una compilazione verso un file di sorgente java oppure verso un qualsiasi stream o stringa di codice sorgente Java.

Ad esempio, potete pensare di scrivere un programma che genera codice Java al volo, lo compila tramite le suddette API (anche senza salvarlo da nessuna parte) e quindi lo esegue.

L'articolo è semplice e ricco di esempi. Inoltre introduce anche la feature variable argument anch'essa introdotta con Java 6, che consente di creare metodi che accettano un numero arbitrario di parametri.

Le proposte del papà di Hibernate per Java EE 6

Gavin King, per chi non lo conoscesse, è il papà di Hibernate, l'arcinoto framework di persistenza. Gavin, iniziò a scrivere hibernate per averla vinta con il suo capoufficio (come scrisse tempo fa in un post che non riesco a recuperare). Dopodichè Hibernate crebbe fino a diventare il più popolare e performante ORM java. Venne quindi acquisito da JBoss, di cui Gavin è ora dipendente. Allo stesso tempo l'autore entrò a far parte del gruppo che scrisse la JSR per Java EE 5... i famosi EJB3. Di fatto questi non furono altro che un set di annotation e specifiche cucite attorno ad hibernate.

Oggi Gavin ha pubblicato la sua (parziale) wish list di specifiche per la prossima versione di Java EE. La 6. Alcune, di fatto sono già implementate in JBoss Seam, per cui se la storia insegna, le vedremo nuovamente cucite in EJB4.

Ci aspettiamo a breve nuovi post sulla questione. Per adesso vi riassumo le proposte per i nuovi Session Bean, tutte specificabili via annotation:

Concorrenza

tre tipi di concorrenza forniti dal container

• session bean senza concorrenza (come adesso)
• session bean con concorrenza gestita dal container: la serializzazione delle chiamate è garantità dall'application server (esempio: Session Bean singleton)
  
• session bean con concorrenza gestita dal container: i synchronized sono a vostro carico

Metodi asincroni

Possibilità di marcare un metodo asincrono (con @Asynchronous), cioè in modo che la sua chiamata non sia bloccante per il chiamante e sia cura dell'application server aprire su un altro thread l'esecuzione del metodo. Direte: si può già fare con il sistema di messagging. Sì, ma quella suggerita da Gavin è un'infrastruttura più leggera di JMS.

Endpoit per webservice WS-blablabla

Possibilità di marcare uno stafeful bean come endpoint di un web-service con stato specificato da molte delle WS-qualcosa. Ad esempio WS-Transaction.
Qui il nostro caro, ha ancora le idee un po' confuse.

Interfaccia business opzionale

La rindondanza della @Local è roba nota, e non ve la ripeto. Gavin "pretende" di togliere il problema. Inoltre fa pubbliche scuse sull'implementazione attuale in EJB3... effettivamente è uno dei pochi che può farlo ;)

Loggers e JMS queues iniettabili

Possibilità di iniettare il classico logger o una coda di messaggi in modo semplice. In Seam già si fa.

Meta-annotation

Questa è bellissima. In un mondo dove ci saranno più annotation che codice, Gavin propone di introdurre una sorta annotation contenitore che esprima tutte le altre in un sol colpo. Direi che questa ci vorrà per forza.


Per ora questo è tutto. Vi terrò aggiornati sul proseguimento delle proposte.

Java 7: cosa c'è in ballo

Per chi è interessato a capire cosa ci si potrà aspettare dalla versione 7 di Java, segnalo questa pagina (inglese), dove sono raccolti per categorie link a numerosi blog di discussione delle singole features in gioco.

C'è un po' di tutto: dalle closure, alle NIO2, dal nuovo javadoc, ai superpackage.

Per chi, invece, volesse spulciare il javadoc dell'ultima build di Java 7 lo trova qui.

Buon divertimento!