Il corso
Gli argomenti trattati sono stati veramente molti, ed alcuni sono stati affrontati con particolare: oltre all'interesse tecnologico per gli argomenti in se, la cosa è interessante perché a posteriori fornisce una interessante visione dello stack tecnologico che il gruppo ha in questo momento, e fornisce qualche indicazione per le possibili evoluzioni future.
Certamente AOP (Aspect Oriented Programming) è stata la sigla più utilizzata: tanto per capire l'interesse che il team nutre in questo nuovo paradigma di programmazione, ad ogni intervento su AOP, Marc si trasformava in Zorro (con tanto di mascherina e cappello nero) per parlare di questo importantissimo argomento…. AOP è il modo per liberare gli oppressi (programmatori) dalla schiavitù a cui soggetti (scrivere migliaia di righe di codice)?
Certamente un tocco di geniale follia aleggiava la stanza, e per certi versi era piuttosto strano vedere 20 persone che, giunte da tutta Europa e dopo aver pagato 3200 Euro per assistere al corso, stavano a bocca aperta a pendere dalle labbra del deus ex-machina di EJB e J2EE. Se fosse entrata una mamma, moglie o fidanzata di uno qualsiasi di noi, presumo che avremmo potuto perdere stima e reputazione in un sol colpo.
Altro argomento molto a cuore dei due speaker è quello della serializzazione: i due hanno a lungo parlato sugli aspetti legati a questo meccanismo, a come cercare di ridurne l'utilizzo e come all'interno di JBoss in realtà essa sia poco utilizzata.
Anche se la serializzazione rappresenta solo uno dei molti argomenti trattati, la sua ripetuta analisi e citazione ha fornito una indicazione importante per capire molte cose relative sia alla implementazione di JBoss, sia al rapporto del team con Sun e con le specifiche J2EE.
La conferenza infatti si teneva a pochi giorni di distanza dalla notizia che IBM e Bea hanno definito una serie di specifiche su EJB che hanno ufficialmente dichiarato di voler implementare senza avere interpellato Sun ed il JCP. Certamente questa è una notizia molto forte ed in un certo senso preoccupante (è ormai il tormentone di fine anno cercare di indovinare cosa ne sarà di Sun da qui ad un anno, se e chi vorrà comprare l'azienda), che fa il paio con la notizia data da Marc che quelli di JBoss Group sono stai invitati ufficialmente da IBM per far parte del team per il rilascio delle prossima specifiche EJB.
La nota di colore è che secondo un certo personaggio molto in alto di IBM (di cui non faccio il nome) nel prossimo futuro le aziende leader nel settore enterprise rimarranno 3: IBM, Microsoft, JBoss Group. Affermazione forte, sulla quale lo stesso Marc si è messo a ridere.
A parte queste considerazioni di fantapolitica e metatecnologia, riprendendo il discorso sulla serializzazione sono degne di nota alcune affermazioni fatte dai due:

"[..] non abbiamo utilizzato la serializzazione in alcuni punti dell'application server (vedi la discussione sul nostro forum [forum]) perché era lenta e poi nemmeno gli altri prodotti seguono alla lettera le specifiche.
"[…]Essere completamente aderenti alle specifiche J2EE non sempre è un bene. […] Noi abbiamo implementato alcuni pezzi seguendo una strada nostra […] le performance e la scalabilità sono più importanti degli standard [...]"
E poi anche "[…] la programmazione per pattern è una cosa molto bella ma non dovete seguirla alla lettera […] in certi casi è molto meglio non usarla […] il vostro codice deve essere molto semplice da leggere, come la lettura di un libro riga dopo riga deve essere possibile leggere i vostri sorgenti[…]".
Infine "[…]le specifiche J2EE sono troppo complesse e l'approccio intrapreso è lontano da quello che realmente serve ai programmatori: architetture orientate ai serivizi e AOP".

Certamente alcune di queste affermazioni sono discutibili, e presumo che un alone di mania di onnipotenza pervadesse l'aria, Zorro o non Zorro…
Personalmente non mi reputo allo stesso livello di conoscenza di J2EE e di padroneggiare EJB come Marc o Sacha, ma proprio per questo l'aderenza alle specifiche, l'aver potuto disporre di pattern programming, e di sapere che al mondo c'è un solo modo da seguire (il Java di Sun) mi ha molto aiutato a crescere e soprattutto a non perdere la strada ad ogni incrocio.
Certo per chi deve tracciare la via quando il sentiero finisce le cose sono un po' differenti, ma non so fino a che punto sia utile spingere per muoversi in una direzione autonoma e forzare le cose.
Il fatto che Sun per l'ennesima voci di sottofondo diano ormai per defunto l'application server di Sun (SunONE) non è certo incoraggiante per una azienda che invece dovrebbe segnare il passo.
Non so cosa riservi il futuro a Sun ma tutti in sala eravamo convinti che per il momento niente sarebbe successo.

Altro tormentone della 4 giorni è stato JMX: è la API più utilizzata in JBoss, la più amata da Marc e la più utile per tutta la parte di management. Esemplare l'esempio di utilizzo di JBoss in modalità embedded che ne viene fatto in AMD come container EJB ma anche come framework di management remoto (tramite JMX) nella catena di montaggio fatta dai robot che costruiscono i microchip (sorrisetto di Marc "Noi forniamo l'application server alla ditta che costruisce i processori per IBM").
E' forse questo un nuovo modo di intendere gli application server, ed il motivo per cui JBoss 3.x sia stato pesantemente progettato sul framework JMX è probabilmente proprio per andare in questa direzione: il settore embedded.

Un ulteriore importante argomento trattato a lungo è stato CMP: se si vede la risposta data da Marc relativamente a quale sarà il framework utilizzato per il mapping OR e per la gestione della persistenza, si capisce l'importanza di questo servizio. E'anche importante e rassicurante da questo punto di vista l'aderenza fedele alle specifiche.
Infine la parola cache ha rappresentato la scommessa vinta dal team in fatto di architetture J2EE. Avere in un application server quello che ormai tutti i programmatori in vario modo si implementavano manualmente è una cosa molto importante.

L'intervista
Al termine del secondo giorno Federico ed io abbiamo effettuato una mini intervista a Marc (questa volta senza mascherina e cappello da Zorro). Ecco le domande e le risposte fornite dal padre di JBoss.

[Giovanni] J2EE è un framework molto potente e complesso. Sembra che ormai abbia raggiunto una buona maturità, stabilità e completezza. Cosa pensi che manchi ancora alla specifica J2EE secondo voi?
[Marc] In una parola… semplicità. Ci sono un sacco di features molto importanti, ma come abbiamo avuto modo di vedere in questi due giorni quello che vorrei io e che reputo sia molto importante sono una serie di servizi e sistemi che mi nascondano la complessità che sta dietro un servizio. Vorrei qualcosa che semplicemente con un tag XML mi trasformi un meta oggetto in un sistema di servizi e sottosistemi in modo trasparente. In una parola vorrei AOP.
Alcuni aspetti di questa filosofia sono stati introdotti in C#, li vorrei anche in J2EE.

[Giovanni] Allora reputi che .net sia avanti a J2EE?
Non credo, mi piacciono molto alcune idee che ci sono li e l'approccio AOP-oriented che hanno intrapreso. Però non mi piace l'implementazione "A la" Microsoft.
Non ci sono cose come Hibernate per il cache dei dati. I PC devono fare reboot ad ogni installazione o re-deploy di componenti: non è una cosa accettabile in uno scenario enterprise di produzione.

[Giovanni] Credi che potranno competere con J2EE per il mondo enterprise?
[Marc] Fino a quando non implementeranno la portabilità fra le piattaforma no

[Giovanni] Credi che faranno mai questa scelta?
[Marc] …. No

[Giovanni] La mancanza di un container con servizi degno di questo nome non credi che sia una limitazione?
[Marc] E' vero, ma adesso la cosa concettualmente più importante è la mancanza di portabilità.

[Giovanni] AOP potrà essere una evoluzione di J2EE, una complementazione? Oppure la sostituirà?
[Marc] Non lo so. Abbiamo chiesto di far parte nel team di definizione delle specifiche EJB 3.0. Vedremo cosa ne uscirà.

[Federico] A che punto e' il processo di certificazione J2EE di JBoss e quando sarà disponibile la versione 4 ?
[Marc] JBOSS è stato da poco certificato J2EE Compliant (in dicembre ndr) , mentre il rilascio della versione 4 è prevista per la fine del primo trimestre del 2004

[Giovanni] Dato che avete inserito pesantemente JMX come sistema di invocazione anche internamente a JBoss quali garanzie sulle performance ci sono rispetto alle invocazioni tipate by contract.
[Marc] Per il momento non ho risposte ne numeri ufficiali. Non abbiamo fatto benchmark, ma il fatto stesso che JBoss utilizzi pesantemente JMX è una buona garanzia. Considera che ogni chiamata locale passa per JMX e non per RMI/IIOP.

[Federico] La JSR-175 prevista per il prossimo J2SE (tiger ndr) introdurrà nuove caratteristiche al linguaggio java. Una di queste è la possibilità di aggiungere tag alle classi Java sul modello di XDoclet. Consideri questa una caratteristica importante per la programmazione AOP e quindi per JBoss?
[Marc] Gestire i deployment descriptor come file XML è scomodo, potere aggiungere tag alle classi in modo standard (tipo XDoclet) sarà utile. Non una grande cosa, ma sicuramente utile. Alcuni delle mancanze della AOP rimarranno. Per esempio la JSR175 non risolve la mancanza di poter aggiungere comportamenti a livello di istanze di oggetti (come e' invece possibile a livello di JVM e classi).

[Federico] Che progetti avete per gestire il monitoring delle applicazioni e delle performance ? C'e' qualche novità all'orizzonte, come ad esempio qualche protocollo specifico (es ARM o PMI, ecc)?
[Marc] Ho fatto personalmente parte della JSR-77 (la JSR di JMX) e si è lavorato sul tema cercando di identificare un modello per il problema.
Alla fine penso che JMX sia la soluzione più semplice, flessibile e chiara al problema, anche se non la migliore. E per interfacciarsi con sistemi di monitoring sono disponibili JMX adpater come ad esempio quello per SNMP.

[Giovanni] Che futuro prevedete per i competitor principali su Java?
Non credo Sun sparirà e nemmeno BEA, anche se la situazione è critica. Sun diventerà forse come una Unisys. Microsoft non credo che diventerà il dominatore.

[Federico] Hybernate JDO o CMP?
I due standard JDO e CMP sono due specifiche che intendiamo continuare a supportare. Per quanto riguarda la loro implementazione intendiamo utilizzare Hybernate come motore di persistenza. Nella versione 4 sarà anche possibile utilizzare direttamente Hybernate senza passare da altre specifiche.

[Federico] Quale servlet container intendete supportare per il futuro (è spesso cambiato tra Jetty e Tomcat) ?
[Marc] Nel recente passato Jetty era sicuramente migliore di Tomcat nella versione 3.X, ma nonostante questo ci veniva chiesto di passare a Tomcat.
Per il futuro intendiamo continuare a supportare entrambi i web engine, mantenendo Tomcat con la distribuzione principale (Tomcat diventerà sempre più importante perché il project leader di Tomcat 5 sarà impiegato a tempo pieno nel team di JBoss, ndr).

[Federico] e Geronimo?
"It's a player"…. Il futuro ce lo dirà. Per adesso è presto. I ragazzi che hanno lasciato il progetto lo chiamano "Elba Project" (in riferimento l'isola in cui Napoleone era al confino, ndr)

[Giovanni] Quale è l'ambiente migliore per sviluppare EJB per JBoss? Immagino JBoss IDE? Ce ne puoi parlare?
Personalmente le preferenza di un ambiente di sviluppo è come decidere quale sia il mio colore preferito. Sono cose di cui non mi preoccupo o occupo (ovviamente la sua mente vola più in alto dei problemi di ogni comune programmatore, ndr). JBossIDE è buono ma non ho preferenze in tal senso. Abbiamo ottimi rapporti con tutti. Borland ci ha aiutato un bel po' anche a certificare JBoss. IntelliJ è un altro prodotto valido, ma ce ne sono molti.

[Federico] Puoi parlarci del recente lancio del programma JASP ?
[Marc] Il mercato europeo e' differente da quello americano. In Europa la consulenza è un fenomeno decisivo per il mercato. Per questo motivo intendiamo collaborare con consulenti, system integration system e ISP vendor per fornire il massimo supporto agli utenti finali. Legato a JBoss c'e' un business sommerso che abbiamo intenzione far emergere, con collaborazioni con partner qualificati. La nostra intenzione è di non inflazionare il mercato con moltissimi partner certificati, ma solo pochi e bravi team di consulenti in ogni paese.

Conclusione
Il corso è stato effettivamente molto interessante, e consente di andare a fondo su determinate tematiche progettuali e di programmazione non banali. Il confronto con progettisti e programmatori EJB venuti da mezza Europa è certamente una esperienza utile ed esaltante. Per chi volesse partecipare ad una delle prossime tappe del corso raccomandiamo una buona conoscenza di EJB, degli aspetti legate alle transazioni ed ovviamente una alta padronanza di JBoss perché tutta la parte introduttiva e di medio livello viene data per scontata.

Riferimenti
[forum] Thread di discussione sul forum MokaByte a proposito di Tomcat e JBoss http://www2.mokabyte.it/forum/thread.jsp?forum=6&thread=184
JBoss - www.jboss.org
JBoss Advanced Training
http://www.jbossgroup.com/index.html?module=html&op=userdisplay&id=services/training/advanced
JBossIDE - http://www.jboss.org/developers/projects/jboss/jbosside