|
Nell'incredibile
cornice del Venetian Hotel di Las Vegas, si è
svolta la seconda edizione del Java TheServerSide Symposium.
Un'occasione d'oro per verificare tendenze di mercato,
confrontarsi con le figure di riferimento del mondo
Java e scoprire, direttamente dagli autori delle specifiche,
le succose novità che si prospettano nel mondo
J2EE.
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 committenti 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
|
