Introduzione
Nei giorni dal 6 all'8 Maggio a Las Vegas, si è svolta
la seconda edizione del Symposium Java organizzato da The
Middleware Company, la società di consulenza che "gestisce"
la community online TheServerSide.com. La conferenza è
uno degli appuntamenti più seguiti e rispettati dalla
comunità Enterprise Java.
Anche all'appuntamento di quest'anno, partecipavano al Symposium
molti membri degli Expert Group, molti lead Architect ed Executive
di Sun, alcuni tra i più importanti fondatori di progetti
Open Source (JBoss, Hibernate, Lucene, Apache Cactus solo
per citarne alcuni), almeno una dozzina di autori di libri
sul mondo Java ed Enterprise ed un gran numero di architetti
con Case Study ed esperienze di notevole livello.
La manifestazione era sponsorizzata da Java Community Process
(JCP), JBoss Group, Compuware, Macromedia e Candle, ma la
loro presenza non è stata per nulla invasiva e si è
limitata ad alcuni interventi durante i break per i pasti.
In un'atmosfera decisamente rilassata, agevolati dal contesto
surreale in cui si è svolto il Symposium - l'Hotel
Venetian è una riproduzione di Venezia con tanto di
gondole e gondolieri che cantano 'O sole mio' (?!?) - abbiamo
avuto modo di scambiare opinioni, confrontare esperienze e
raccogliere interessanti notizie ed anteprime relative al
mondo Java ed al mercato Enterprise in genere.
Andiamo ad esaminare quali sono stati i temi di maggiore interesse.
J2SE
1.5
Grande risalto è stato dato alla semplificazione del
linguaggio JAVA che porterà il rilascio del J2SE 1.5
ed alle forti implicazioni che questo avrà sulle specifiche
EJB 3.0. Nelle parole di Linda DeMichiel (SUN), Java continua
ad essere un linguaggio che richiede forti skill e competenze
superiori a quelle dello sviluppatore "medio". L'obiettivo
dichiarato del nuovo J2SE è quello di semplificare
le basi richieste allo sviluppatore ed agevolare chi produce
piattaforme di sviluppo pur mantenendo la tipica "consapevolezza"
cui ci ha abituati la piattaforma Java ed ovviamente senza
sacrificare la compatibilità e la portabilità.
Da quanto si è visto, per raggiungere questi obiettivi
SUN è disposta ad introdurre un numero veramente elevato
di nuove features (probabilmente il più alto da un
po' di anni a questa parte) ed a rivedere alcuni capisaldi
che sembravano inviolabili.
Come già visto in un precedente articolo (vedere [J15]
per approfondimenti), le novità più interessanti
che l'1.5 presenterà sono: Generics, Autoboxing/Unboxing,
una specie di costrutto "foreach", le "enumeration",
import statici, Metadata e Varargs.
Probabilmente anche per le ovvie necessità di retrocompatibilità,
non tutte le soluzioni hanno il livello di "eleganza"
cui SUN ci aveva abituato (si veda ad esempio il nuovo costrutto
"for") ed in realtà non è sempre così
evidente il livello di semplificazione che queste features
introdurranno per lo sviluppatore applicativo; sicuramente
queste novità non mancheranno di sollevare polemiche
e dubbi all'interno della comunità Java. E' sufficiente
però dare un'occhiata alle nuove specifiche EJB 3.0
per capire quanto caratteristiche come i Metadata siano fondamentali
per il futuro della piattaforma Java.
AOP
Enterprise / Persistenza
Durante il Symposium si è parlato molto di AOP. In
alcune sessioni è stata presentata questa tecnologia
come strumento efficace già adesso per lo sviluppo
applicativo medio. L'impressione è stata quella di
una tecnologia sicuramente utilizzabile in questi ambiti,
ma gli esempi d'uso mostrati non hanno colpito particolarmente
(i soliti aspetti, logging, security,
). In particolare
non sembra chiaro il vantaggio dell'utilizzo di soluzioni
"ad hoc" sviluppate con AOP in alternativa a soluzioni
middleware standard.
Come confermato dalle evoluzioni di JBoss e da EJB 3.0 è
invece chiaro l'impatto che l'approccio AOP sta avendo nell'implementazione
di Middleware (controllo delle transazioni, persistenza, sicurezza...).
Sono comunque interessantissimi gli scenari che si possono
sviluppare nell'utilizzo di questo approccio in combinazione
con i Metadata (anche se non è stato presentato nessun
esempio).
EJB
3.0
Linda DeMichiel (Spec lead di EJB 3.0) ha introdotto l'argomento
focalizzando l'attenzione sulla necessità di semplificare
la vita degli sviluppatori. L'obiettivo pare essere quello
di fornire una versione di EJB più maneggevole pur
mantenendo il modello EJB 2.0/2.1 per applicazioni Enterprise
più complesse.
La possibilità di utilizzare i Metadata (introdotti
in J2SE1.5) permette molte delle semplificazioni descritte,
evitando agli sviluppatori di scrivere (o gestire) i Deployment
Descriptor (precompilati dal codice java "annotato")
e di specificare le interfacce remote. Di fatto questo dovrebbe
comportare la possibilità di scrivere un EJB con una
sola classe (invece delle 3/5 più Deployment Descriptor
di adesso), in pratica "ufficializzando" l'approccio
allo sviluppo stile XDoclet. L'utilizzo delle annotazioni
consentirà inoltre di evitare la scrittura di metodi
con implementazioni vuote per soddisfare le interfacce (niente
più ejbActivate{} !).
Ad
esempio oggi per sviluppare un semplice Stateless Session
Bean Calculator è necessario scrivere due interfacce,
una classe ed il Deployment Descriptor
public
interface Calculator extends EJBObject {
int add(int a, int b) throws RemoteException;
}
public
interface CalculatorHome extends EJBHome {
Calculator create() throws CreateException, RemoteException;
}
public
class CalculatorBean implements SessionBean {
private SessionContext ctx;
public void setSessionContext(SessionContext ctx)
{
this.ctx=ctx ;
}
public void ejbCreate() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void ejbRemove() {}
public int add(int a, int b) {
return a+b;
}
}
...
<session>
<ejb-name>CalculatorEJB</ejb-name>
...
</session>
...
Con
EJB 3.0, sfruttando anche la generazione automatica delle
interfacce, tutto questo potrebbe tradursi semplicemente nel
codice seguente (nessuna interfaccia, nessun Descriptor)
@Session
public class CalculatorBean {
public int add(int a, int b) {
return a+b;
}
}
I
metadati permetteranno inoltre di configurare il recupero
delle risorse tramite l'utilizzo di una tecnica di "setter
injection" (in pratica un metodo setter appositamente
annotato); lo scopo è quello di eliminare l'utilizzo
di JNDI all'interno del codice e produrre classi più
facilmente testabili fuori dai container senza accorgimenti
particolari.
Un altro concetto interessante è il "configuring
by exception": la configurazione di un componente ha
dei default, lo sviluppatore dovrà solamente specificare
le differenze. Questo tipo di comportamento verrà facilmente
implementato utilizzando i defaults specificabili sulle annotazioni.
Un punto su cui le novità sembrano essere molto interessanti
è la modifica degli Entity Beans, trasformando il complesso
modello di programmazione precedente in un modello a "POJO".
Sullo stile di Hibernate, il nuovo modello prevedrà
l'utilizzo di un gestore della persistenza (EntityManager)
da utilizzare per degli entity beans ed utilizzabile fuori
dal container; sarà quindi possibile scrivere unit
tests con Entity Beans eseguibili come applicazioni java "normali"
(le specifiche in questo ambito non sono ancora completamente
definite).
Molte novità sono annunciate anche su EJBQL con l'obiettivo
di renderlo più flessibile; in questo ambito le specifiche
sono ancora ampiamente in evoluzione.
Figura 1 - Dion Almer modera un'accesa discussione
sul futuro di Java (tra gli altri sono
riconoscibili Marc Fleury e Rod Johnson)
Complessivamente
appare chiaro che l'obiettivo è semplificare lo sviluppo
senza rinunciare alla flessibilità cui gli architetti
J2EE sono abituati nelle loro soluzioni. I cambiamenti annunciati
sono in effetti tanti e sembrano essere decisamente ispirati
da prodotti OpenSource "di successo" come XDoclet
ed Hibernate, che in molti casi sono nati per "rimediare"
ad alcuni difetti delle versioni precedenti di J2EE.
Oltre
a Linda DeMichiel ha parlato di EJB 3.0 anche Gavin King,
sviluppatore di Hibernate ed impegnato anch'esso nella stesura
delle specifiche. Nel suo discorso, King è partito
dai problemi degli Entity Beans così come definiti
nelle specifiche fino alla 2.1 per introdurre Hibernate e
l'evoluzione seguente (EJB 3.0).
King ha fatto notare che in effetti Hibernate è ancora
dipendente dalle informazioni di mapping in xml su un file
"esterno" e che, non essendo uno standard, possiede
una sola implementazione. In questo EJB 3.0 promette di essere
migliore, mantenendo però lo stesso modello di programmazione
Hibernate, il cui successo è stato decretato dalla
comunità di sviluppatori Open Source.
Evidente comunque lo sforzo per mantenere la retrocompatibilità
a costo di compromessi in fase di design, strategia comprensibile,
ma contraria a molti "rumors" presenti nella community
che ad esempio richiedevano la deprecation degli Entity. La
specifica è ancora ben lontana dall'ufficializzazione
ed è ampiamente in discussione (molte domande hanno
avuto come risposta "...ne stiamo discutendo...").
Java
Community Process: lo stato
E' stato direttamente Onno Kluyt [ONN] di SUN, direttore del
JCP Program Management Office, a presentarci lo stato dell'arte
delle specifiche su cui i vari Expert Group stanno lavorando;
attraverso statistiche e numeri, è stato dato particolare
risalto al grande sforzo di aggiornamento/realizzazione che
i gruppi stanno facendo.
I numeri che ci sono stati presentati erano anche volti a
mostrare come dietro la maggior parte delle specifiche ci
sia un'attività realmente comunitaria . Ad esempio
Kluyt ha sottolineato che meno della metà dei gruppi
è condotta da personale SUN.
La descrizione estesa del processo di condivisione evidenzia
lo sforzo necessario per realizzare una JSR (Java Specification
Request) esaustiva e condivisa dai partecipanti. Ovviamente,
se da un lato questo è garanzia di tutela rispetto
ad eventuali interessi di parte, dall'altro implica una latenza
nella produzione di specifiche che piattaforme concorrenti
(es. .NET) non si trovano a pagare. Anche da questa consapevolezza
sembra nascere il risalto che viene dato allo sforzo produttivo
che i vari Expert Group stanno compiendo. Nonostante questa
accelerazione, i tempi medi mostrati sono comunque decisamente
alti.
Project
Management e Metodologie
Nulla di particolarmente interessante dal punto di vista metodologico;
particolarmente attivo Scott Ambler [SCO], uno dei fondatori
di Agile Modeling, che in un paio di interventi ha presentato
con grande enfasi i principi base delle metodologie e dei
processi Agile con particolare attenzione alle tecniche orientate
ai Database. Come purtroppo spesso capita gli interventi si
sono trasformati in sterili dibattiti tra le due fazioni "metodologie
tradizionali" vs "Agile". Nulla di originale
anche rispetto alle critiche evidenziate: queste metodologie
non scalano, non producono documentazione, ecc.
Più interessanti invece i Case Study presentati, prevalentemente
esperienze d'uso di JUnit, Ant e CheckStyle su progetti di
grandissima scala.
Rich
Front End (Flex)
Di particolare interesse la presentazione tenuta da Macromedia
sulla tecnologia Flex [FLE]. Flex è una tecnologia
basata su Flash, finalizzata alla creazione di Web Application
più ricche, dal punto di vista dell'ergonomia, rispetto
a quelle realizzabili via HTML/Javascript.
Flex consente di sviluppare Rich Client secondo un modello
di sviluppo ben noto agli sviluppatori che usano JSP, ASP,
ASP.NET o linguaggi di script similari: si crea uno script
contenente il codice sorgente, lo si rilascia sul Presentation
Server, alla prima richiesta il codice viene "compilato"
generando un "componente" applicativo. In questo
caso non viene generato codice HTML, ma un'interfaccia che
sarà eseguita sul client nella "virtual machine"
Flash (secondo le statistiche fornite nell'intervento, presente
sul 98% dei client Internet).
L'obiettivo chiaro è quello di fornire validi strumenti
per la realizzazione di Rich Internet Application e più
in generale di front end che non risentano dei tipici limiti
di ergonomia dati dalla tecnologia HTML. In più Macromedia
vuole fornire un modello di sviluppo che semplifichi il perverso
misto di tecnologie necessarie (HTML, Javascript CSS,
)
per realizzare GUI applicative.
Flex è stato intelligentemente presentato come un complemento
delle piattaforme enterprise più diffuse e quindi propone
un Framework sostanzialmente basato su standard ed un ricco
set di componenti. Grazie all'adozione di questi standard
è possibile sviluppare una presentation Flex su di
un modello N-Tier con un business tier sviluppato secondo
i più comuni pattern/tecnologie J2EE (EJB, Web Services,
XML) o .NET.
Secondo quanto dichiarato da Macromedia sarà fornita
un'integrazione con i più comuni tool di sviluppo Eclipse
(plugin già disponibile oggi), Visual Studio e Borland
JBuilder.
Naked
Objects
Molto interessante è stata anche la sessione relativa
a Naked Objects [NAK]. Questo framework presenta un modo "nuovo"
di disegnare l'interfaccia utente per applicazioni client/server.
L'idea è quella di esporre tramite un'interfaccia grafica
particolare i business objects del sistema, permettendo all'utente
di manipolarli direttamente.
Il Framework permette di definire oggetti che in questo modo
vengono "messi a nudo" e di specificarne, ad esempio,
i comportamenti che hanno quando vengono messi in relazione.
Una cosa che salta subito all'occhio è che un sistema
di questo tipo vincola in modo forte la scelta dell'interfaccia
utente dell'applicazione anche se il relatore ha sottolineato
che nei casi applicativi in cui questo approccio è
stato utilizzato (comunque non banali), i commitenti sono
rimasti assolutamente entusiasti. In ogni caso è stato
fatto notare il carattere sperimentale di queste librerie.
JBoss
L'ingresso in sala dei rappresentanti di JBoss Inc. travestiti
da nemici di Batman, ha dato inizio, con lo stupore di tutti,
alla presentazione di Marc Fleury.
Inizialmente Fleury ha presentato con sano entusiasmo le novità
di EJB 3.0 dando rilievo a tutti gli aspetti introdotti, per
poi passare a descrivere la visione di JBoss Inc.
Fleury non ha nascosto la volontà di creare un'azienda
con profitti basata su software Open Source, ed ha introdotto
un interessante (e divertente) parallelo tra "capitalistic
open source" vs "communist open source".
Ha inoltre descritto i progetti controllati dal gruppo (JBoss
Application Server, JBoss AOP, JBoss Cache, JBossIDE, Nukes)
che, come in realtà si sa già da tempo, utilizzeranno
in maniera pesante AOP.
Figura 2 - Marc Fleury (il Joker), Cedric Beust e Linda
DeMichiel si confrontano sul tema EJB 3.0
Interessante,
anche se non nello stesso contesto, è stata la presentazione
del Framework di cache transazionale distribuita di JBoss.
In particolare sono stati spiegati approfonditamente i meccanismi
con cui la cache viene mantenuta consistente su un ambiente
distribuito utilizzando un meccanismo di propagazione delle
modifiche della cache molto promettente in termini di prestazioni.
Architetture
di integrazione
Non molto estesa la parte dedicata alle tecnologie/strategie
di integrazione nel mondo Java. L'intervento clou è
stato quello di Mark Hapner (SUN, Spec lead di J2SEE 1.4)
che ha presentato JSR 208 (Java Business Integration, JBI)
e le sue relazioni con SOA. La specifica si pone l'obiettivo
di definire standard credibili nel contesto della business
integration definendo nuovi metadata sullo stack web services,
facendo confluire le specifiche che altri gruppi (es. WSCI
e W3C Choreography Working Group ) stanno portando avanti.
JBI chiaramente potrebbe rappresentare un'importante risposta
alle richieste dell'industria che sente fortemente l'esigenza
di un "business integration" protocol standard e
ben supportato. JBI potrebbe infatti consentire l'integrazione/aggegazione
di componenti generici e componenti J2EE ovunque dislocati
all'interno di business process definiti e configurati via
metadata standard e platform indipendent.
Purtroppo la specifica è parsa ancora molto astratta
e vaga alimentando perplessità sulle effettive possibilità
di proporre una piattaforma realmente efficace, che sia in
grado di omogeneizzare le tecnologie proprietarie oggi presenti
e che sia supportata dal mercato in tempi brevi.
Molto interessanti invece gli interventi di Gregor Hohpe [HOH],
autore del consigliatissimo "Enterprise Integration Patterns".
Nonostante l'aspetto da Groucho Marx, Hohpe ha affrontato
con grande chiarezza e buon dettaglio i temi associati allo
sviluppo asincrono di applicazioni Java di integrazione.
Nei suoi interventi, Hohpe ha mostrato il suo lavoro di formalizzazione
delle problematiche di integrazione tipiche delle soluzioni
basate su sistemi di Messaging Middleware. Molto pragmaticamente
(l'autore parla di Agile EAI), il problema complessivo è
stato scomposto in n problemi di dettaglio (Channel, Message
Construction, Routing, Transformation, EndPoint e System Management).
Secondo queste famiglie Hohpe cataloga un ampio set di pattern
(circe 60), concettualmente applicabili indipendentemente
dalla tecnologia usata (J2EE vs .NET, ma anche semplice messaging
o suite EAI).
Una volta tanto il tema è stato affrontato in maniera
fortemente pratica mostrando l'indispensabilità dell'integrazione
("No Escape From Integration") e demistificando
alcuni temi classici, uno per tutti: tra due applicazioni
da integrare, non sempre l'accoppiamento lasco è preferibile
all'accoppiamento stretto.
Lightweight
Containers
Grande attenzione è stata posta ai Lightweight Container
come modello di sviluppo alternativo/complementare a parte
di J2EE. E' stato in particolare Rod Johnson, l'autore di
Spring [SPR], a muovere le critiche più pesanti alle
specifiche J2EE. Particolare oggetto delle critiche ovviamente
il modello EJB (significativamente l'intervento portava il
titolo "J2EE without EJB") con particolare attenzione
agli Entity, ma le critiche mosse hanno colpito le specifiche
a 360 gradi.
Al di là di alcune parti specifiche (es. Sicurezza,
ruoli EJB, XML descriptor, limiti dal punto di vista OO,
)
è stato messo in risalto come sia proprio l'approccio
EJB SUN a differire alla base da quello dei lightweight container.
In generale l'esigenza principale espressa è quella
di semplificare lo sviluppo di business object, tornando a
lavorare in "pure" Java (ovviamente con abbondante
uso di POJO), mantenendo le possibilità OO offerte
dal linguaggio base, con migliori possibilità O/R ed
un più ampio supporto di SQL. Ulteriori temi messi
in luce sono stati: la testabilità al di fuori del
Container, configurazioni JavaBeans-based via Inversion-of-Control,
l'esigenza di Framework AOP quanto più possibile trasparenti
e "sostituibili".
Poiché Framework come Spring forniscono astrazioni
di aspetti tipici delle architetture MVC, Johnson ha evidenziato
come siano praticabili anche approcci misti: Spring più
Hibernate o Struts più Spring.
Per quanto spesso le motivazioni portate siano state estreme
e forzate, risulta evidente l'impulso alla discussione ed
all'evoluzione portato da queste realtà. Le specifiche
EJB 3.0 presentate da SUN, recepiscono in modo chiaro molte
delle esperienze e dei concetti di Hibernate, Spring o PicoContainer.
E' ovvio che, nel momento in cui esisteranno implementazioni
valide di queste specifiche, questi Framework avranno un futuro
incerto e potrebbero fornire meno benefici di quanti non ne
forniscano ora. Fino ad allora le tendenze evidenziate al
Symposium forniscono conferme sulla bontà di tali soluzioni.
Java
vs .NET
La presenza di .NET al Symposium è stata costante e
da più parti è stata associata la volontà/necessità
di semplificazione della piattaforma J2EE all'avvento della
piattaforma Microsoft sul mercato. D'altro canto, The Middleware
Company e la maggior parte degli speaker presenti, scrivono
e lavorano regolarmente su questa piattaforma.
L'ultimo giorno, il tema è stato affrontato esplicitamente
in un confronto condotto da Ted Neward [TED]. Neward, che
è un rappresentante autorevole sia della comunità
Java che di quella Microsoft, ha tenuto una interessante discussione,
organizzata come sessione di domande e risposte, su J2EE e
.NET.
Al di là delle domande tecniche su .NET (si è
parlato in particolare della piattaforma come ambiente multilinguaggio),
la tesi che Neward sostiene in maniera abbastanza convinta
(e convincente) è che, in definitiva, non sarà
possibile nei prossimi anni non conoscere sia J2EE che .NET
e che diventeranno critiche in breve tempo le tecnologie che
permettono l'integrazione tra i due "mondi". Si
è dato inoltre rilievo al "feedback" che
C# come linguaggio ha avuto sulla definizione delle nuove
funzionalità che verranno introdotte in Java.
Bibliografia
e Riferimenti
[HOH] http://www.enterpriseintegrationpatterns.com/index.html
[TED] http://www.neward.net/ted/index.html
[SPR] http://www.springframework.org
[SCO] http://www.ambysoft.com/
[GAV] http://blog.hibernate.org
[NAK] http://www.nakedobjects.org
[JCP] http://jcp.org/en/home/index
[ONN] http://jroller.com/page/OnnoKluyt
[FLE] http://www.macromedia.com/software/flex
[J15] http://www.mokabyte.it/2004/03/jdk1_5.htm
|