Soluzione opensource per il clustering a livello di JVM.
Soddisfa i requisiti di scalabilità e affidabilità.
Clustering trasparente a livello applicativo.
Fa interagire le applicazioni distribuite come se fossero su una unica JVM.
In una JVM i threads interagiscono gli uni con gli altri attraverso il cambiamento degli oggetti residenti nell’HEAP e attraverso le primitive concorrenti. (‘synchronized’ keyword, wait(), notify() e notifyAll()).
Terracotta estende il loro significato per una sincronizzazione distribuita.

Ho scritto anche un articolo su terracotta “http://www.aldaran.org/press/java/terracotta-dso/”

Inoltre ho aperto un gruppo di discussione su yahoo
http://it.groups.yahoo.com/group/it_openterracotta/

Clicca qui per iscriverti a it_openterracotta

Ecco le slides del seminario Maven2

Presto metterò il link alla presentazione su youtube.

Articolo su Terracotta DSO

Scambio di messaggi a lunghezza variabile

le Unchecked Ex. rappresentano invece degli errori che avvengono a runtime (potremmo definirli dei difetti del programma). Spesso sono causate da errori o dimenticanze di programmazione, o errato modo di usare un proprio oggetto/metodo.

E’ importante programmare usando il minimo possibile le eccezioni, la loro gestione impiega una grande quantità di CPU, memoria e risorse macchina.

Ogni qualvolta è necessario gestirne una, stabilire a chi spetta la sua gestione è importantissimo.

La domanda da porsi è: “chi conosce il come e chi conosce solo il cosa…”

E’ chiaro che delegare la gestione (catch) di una eccezione ad un componente che non conosce l’implementazione implica la creazione di un accoppiamento di troppo.

Un esempio nella vita reale potrebbe essere: chiedo a un professionista di ripararmi la lavatrice, dopo qualche giorno torno e lui mi risponde che il suo bancomat è scaduto.
E’ chiaro che questa risposta non ha senso, ma proviamo a ricostruire cosa è successo: andando a comprare i pezzi necessari per la lavatrice, non è riuscito a pagare perché aveva il bancomat scaduto.

Se tentiamo di modellare questo evento, ci accorgeremmo che l’eccezione “Bancomat scaduto” non doveva arrivare a me, (come lo gestisco?), il professionista avrebbe dovuto filtrare l’eccezione e dirmi, “il pezzo non è ancora disponibile”. (Legge di Demetra)

Se non è Chiaro, la SQLException in una jsp non ci deve arrivare!

Nella modellazione, quindi, è fondamentale impiegare le Checked Ex. in modo molto attento. (valgono tutti i principi OOP)
L’uso delle Unchecked exception (le runtime) o meglio catturare una eccezione di runtime,
in un sistema perfetto non dovrebbe essere mai fatto. dico in un sistema perfetto perche poi per pigrizia spesso e volentieri se ne abusa.

essendo delle eccezioni non dichiarate nelle firme dei metodi, queste eccezioni sono in grado di attraversare tutti i tiers della applicazione fino ad arrivare all’utente. Giusto pensare un sistema per non far vedere l’errore all’utente finale (lo sviluppatore invece le deve vedere).

Quando si crea una firma di un metodo, senza implementarlo, la soluzione migliore è fargli rilanciare una Uncheked Exception tipo “throw new NotYetImplementatedException()”

Insomma, queste eccezioni esulano dalla progettazione di un software, sono molto potenti e anche molto pericolose se lasciate proliferare. Esse dovrebbero sparire nella messa in esercizio.
Citazione dell’anipattern “programming by exception”
Una volta in Sud Africa ho visto un MVC che faceva uso di Una ForwardException
dove il getMessage() restituiva la url della jsp dove forwardare….. esempio lampante di
antipattern NON FATELO…

Inversion of Control (IoC)
Anche detto Hollywood principle:
“don’t call us, we’ll call you”
“Non ci chiamate, vi chiamiamo noi”

Nel 1997 gia si parlava di IoC riferendosi alla gestione degli eventi sulle interfacce utente.
Il passaggio del mouse veniva gestito dalla finestra e poi passato a tutti i suoi figli (che ignoravano il messaggio se non diretto a loro). Mentre all’inverso il mouse poteva essere gestito dall’oggetto grafico che propagava il messaggio al suo contenitore.

Ho pubblicato le slide del seminario tenuto al JavaDay 2006
Slide: 2006 Spring 2.0 pdf

Pubblicate le slide di questo seminario
AntiPattern: se lo conosci lo eviti

Mentre la servlet genera una pagina la portlet genera un fragment
Le portlet non mappate da una specifica url
Le P. hanno un sofisticato schema di request action / render
Le P. hanno stati e “modes” standard che definiscono le regole di azione e visualizzazione
Le P. usano dei meccanismi di accesso e persistenza alle informazioni di configurazione
Le P. possono fare portlet rewriting cosi da essere indipendenti dall’implementazone del portale
Le P. hanno due differenti session scope: application e private.
Le P. non possono alterare l’HTTP header o setatre la response encoding.

Pubblicato il seminario sulle portlet tenuto al JIPDay 2005
Java Portlet: JSR 168

Java opensource per le aziende

Java open source per le aziende: gli strumenti e le potenzialità, rischi ed opportunità.

L’intervento è indirizzato alle realtà aziendali che intendono operare in uno scenario totalmente open source.Lo scopo principale è mostrare il dietro le quinte del linguaggio Java,limiti compresi, presentando le tecnologie che si sono sviluppate intorno a questo linguaggio, supportato, oltre che SUN ed altri colossi, da una ampia e attivissima communty. Verranno infatti mostrate le soluzioni open source che rispondono alle esigenze aziendali come sistemi *CRM* (Customer Relationship Management), *SCM* (Supply Chain Management), *ERP* (Enterprise Resource Planning), EAI(Enterprise Application Integration).