Terracotta semplifica lo sviluppo delle applicazioni:

• Il cluster TC non è applicativo ma lavora a livello di JVM.
• Permette una netta separazione tra Business Logic e Infrastructure Object.
• NESSUNA API Java NUOVA da imparare.
• Non c’è serializzazione, la replicazione è a livello di field.
• Non ci sono metodi CUSTOM da implementare per la replicazione.
• In poche parole RISOLVE i problemi del CLUSTERING in una sola soluzione

Terracotta features:

• Utilizzo della rete ottimizzato, ridotto trasporto delle informazioni (non c’è serializzazione).
• E’ possibile fare l’update degli oggetti (new deploy)
• Monitor del server e degli oggetti condivisi tramite JMX (Admin console)
• Aumento della massima capacita di memoria di una singola JVM.
• Eventi distribuiti.

Tipici scenari:

• HTTP Session Replication
• Distributed Cache
• POJO Clustering
• Spring integration
• Collaboration, Coordination, and Events

L’architettura è composta da un server centrale (è possibile ridondarlo con una serie di server inattivi) e un insieme scalabile di JVM o Application Server.
 Ogni JVM comunica con il server tramite delle librerie, caricate in fase di avvio dal boot-classloader, usando un protocollo TCP.

 
Generalmente in una JVM i threads interagiscono gli uni con gli altri attraverso il cambiamento degli oggetti residenti nell’HEAP e attraverso le primitive concorrenti native in java (‘synchronized’, wait(), notify() e notifyAll()). Terracotta permette ai threads appartenenti alle diverse JVM del cluster di interagire gli uni con gli altri, modificando gli oggetti di un HEAP “condiviso”, attraverso le stesse primitive di Java, aggiungendo a queste un significato distribuito.

Le librerie lette a boot-time dai clients servono a dare, in modo trasparente, un comportamento di cluster a livello di JVM. Prima di tutto aggiungono dei comportamenti distribuiti alle operazioni di salvataggio e cancellazione degli oggetti dell’HEAP, in secondo luogo forniscono uno scambio di informazioni (SIGNALS) centralizzato per avere una sincronizzazione multi JVM.

In una JVM, ogni oggetto è salvato in memoria tramite le istruzioni bytecode PUTFIELD e GETFIELD. Terracotta modifica queste istruzioni a runtime, tramite ASM (libreria per la bytecode injection), nelle classi “configurate” che vengono caricate nell’application classloader. Grazie a queste istruzioni, terracotta è in grado di tenere replicati sui server del cluster, interi o parziali grafi di oggetti, comunicando le modifiche degli oggetti e le richieste di lock e unlock al server centrale terracotta.

Questo è l’elenco delle istruzioni bytecode modificate:
GETFIELD, PUTFIEL, AASTORE, AALOAD, MONITORENTRY, MONITOREXIT, INVOKE0 e INVOKESPECIAL

Il Terracotta Server è una applicazione java che usa Berkley DB come database di oggetti. Salva i dati degli oggetti e coordina i threads concorrenti delle diverse JVMs. Tramite un protocollo TCP (p2p) le JVMs comunicano con il TC Server per lo scambio e la sincronizzazione degli oggetti condivisi. TC Server si occupa poi di inviare i dati cambiati a tutti gli altri membri del cluster (se essi ne hanno bisogno).

Ogni JVM ha un HEAP dove risiedono gli oggetti. Ogni cambiamento ad un oggetto condiviso lo possiamo vedere come una transazione terracotta, questa contiene i cambiamenti degli oggetti, o meglio solo i dati dei campi cambiati. Queste transazioni sono inviate al server e questo immediatamente, invia i cambiamenti a tutte le altre JVM coinvolte lasciando quindi il cluster consistente. Il server filtra ovviamente i dati delle transazioni in modo da mandare i cambiamenti dei soli oggetti posseduti dalle singole JVM. (se una JVM conosce uno solo degli oggetti coinvolti nella transazione, il server gli manderà i soli dati relativi a questo oggetto).

Terracotta non usa la Java Serialization per replicare i cambiamenti, gli oggetti sono tracciati e replicati a livello di campo e le transazioni contengono solo dei frammenti di un oggetto anziché tutto il grafo degli oggetti.

La Java Serialization ha come principio il salvataggio di un oggetto su uno stream, quindi anche un cambiamento ad un singolo valore, provoca la serializzazione a partire dall’oggetto radice (root) da replicare e quindi la serializzazione di tutto il grafo degli oggetti coinvolti.
L’approccio di terracotta è chiaramente molto più efficiente per mantenere sincronizzati due oggetti, infatti essa sposta attraverso il cluster, solo i dati che sono cambiati anziché ogni volta replicare tutto il grafo. La differenza di performance aumentano a dismisura se si pensa ad una struttura condivisa molto profonda.

Comunque questo approccio, a parte l’efficienza, risolve un grande problema del clustering: preservare l’identità di un oggetto.

Se la serializzazione è usata per spostare un oggetto tra i componenti di un cluster, un oggetto cambiato dovrà quindi essere deserializzato nella JVM remota e “qualcosa” dovrà sostituire l’oggetto esistente con quello passato. Questo è il motivo per cui molte altre tecniche di clustering/caching necessitano di esplicite API (GET/PUT) per la replicazione di un oggetto nel cluster.

Terracotta non ha queste restrizioni. Un oggetto condiviso nel cluster, vive nell’HEAP come qualsiasi altro oggetto. Quando un cambiamento ad un oggetto è fatto nella JVM locale, i cambiamenti sono fatti direttamente sull’oggetto dell’HEAP. Quando i cambiamenti sono fatti da una JVM remota, la transazione è ricevuta dalla JVM locale che applica questi cambiamenti sull’oggetto locale (che risiede nell’HEAP). Questo significa che c’è una e solo una istanza di un oggetto condiviso nell’HEAP di ogni JVM.

Con TC non bisogna mai richiedere la copia “fresca” dell’oggetto, e nemmeno l’inverso, non è necessario informare nessuno che l’oggetto è stato modificato. Questo perché non ci sono copie, un oggetto condiviso nel cluster è solo un semplice oggetto nell’HEAP e un oggetto condiviso si comporta come ogni altro oggetto: ogni cambiamento effettuato è disponibile immediatamente su tutti gli oggetti che posseggono la reference ad esso, che siano locali alla JVM o remoti.

Quindi è importante capire che un oggetto conserva la propria identità in una applicazione eseguita su un cluster TC (multi-JVM) come se fosse eseguita in una singola JVM.

La semplicità di Terracotta e la conservazione dell’identità di un oggetto nel cluster, rende i problemi del cluster completamente separati dai problemi di design e implementativi di una applicazione. Le capacità del cluster sono inserite a livello di JVM, fondendosi quindi con l’infrastruttura.

Cosi come il garbage collection permette la gestione della memoria in modo trasparente alla programmazione, Terracotta permette la clusterizzazione in modo ugualmente trasparente.