Anche quest'anno é finito, l'evento più importante dedicato a Java si e' appena concluso e sto già preparando l'articolo mentre sono sul volo di ritorno. Ricordo il viaggio di andata quando sull'aereo si potevano notare numerose magliette con loghi inequivocabili, le borse di JavaOne delle scorse edizioni posizionate nei vani portaoggetti, il mio vicino che stava consultando alcuni diagrammi UML. Erano tutti segni inequivocabili: ero seduto su un gigantesco pulmino volante che stava portando vari geek da mezza Europa nella sede mondiale di Java.
Adesso che tutto é finito mi sembra di essere invece sul treno che riporta in a casa i ragazzi dalla colonia estiva. Un po' di amarezza pervade quei viaggiatori che come me se ne rientrano con lo zaino-trolley di JavaOne 2002 al posto di quello dell'anno passato. Ma a parte questi sprazzi brutta copia di un film di Fellini, quello di quest'anno é stato JavaOne veramente interessate.
Diverse le novità presentate ex novo (o from scratch come si dice da quelle parti), ma soprattutto moltissime le modifiche apportate alle varie API e tecnologie già presenti all'interno della piattaforma Java2.
In questo articolo cercherò di presentare tutto quello che ho potuto vedere e che mi è parso particolarmente interessante. Premetto che purtroppo per mancanza di tempo non sono riuscito a seguire alcune presentazioni e che ad ora rimangono per me misteri termini come puzzling programming, remote w-services, ed OSGi. Spero di poter colmare queste lacune al mio rientro anche se immagino che in alcuni casi si tratti per lo più di buzzwords.

Figura 1 - James Gosling come ormai tradizione ha aperto
la conferenza dando un un po' di folklore e spettacolo alla conferenza.

Le novità di JavaOne
Quest'anno le novità più interessanti ruotavano tutte intorno alle parole Web Service e J2ME, avendo particolare attenzione al problema della integrazione con le nuove proposte da parte di Sun ma sopratutto con il resto della piattaforma J2EE giunta ormai ad un livello di affidabilità e potenza sicuramente invidiabile.

Figura 2 - uno schema riassuntivo della piattaforma J2EE

In tal senso il messaggio di Sun é quanto mai chiaro ed esplicito: partendo dalla piattaforma J2EE la parola d'ordine é astrarre maggiormente e spingere il processo di integrazione delle varie e tecnologie. Per questo moltissimo é stato detto a proposito di JMS (che sta diventando ormai la spina dorsale di tutto Java2) e su Connector Architecture.
Questi due strumenti dovranno essere pensati ed utilizzati in misura sempre maggiore per permettere l'interoperabilità dei vari moduli (tramite JMS) e la capacità di astrarsi dai dettagli implementativi sottostanti (l'architettura Connector).

Il nuovo processo di sviluppo e rilascio
JavaOne con i suoi 5 giorni di conferenza 8 ore al giorno (più le sessioni serali) é stata l'occasione per rispolverare tutto quello che Sun ha presentato di recente ed integrarlo sulla base di una filosofa fortemente spinta nella direzione della astrazione e della integrazione. Le molte tecnologie presentate negli ultimi 12 mesi sono state qui ripresentate e riviste a dimostrazione che Java2 é ormai una piattaforma quanto mai complessa, articolata e sicuramente ben progettata.
JMS ad esempio non é più un semplice meccanismo per la gestione della messaggistica asincrona ma anzi viene presentato da Sun sempre più come la colonna portante di tutto J2EE. Concetti come Java Server Faces, Portlets e Connector Architecture, pur non essendo recenti novità sono stati rivisti alla luce di questa nuova filosofia.
In questo nuovo scenario é sempre più evidente che le tre implementazione J2SE, J2ME e J2EE seguono un processo evolutivo parallelo ma non strettamente sincrono, tanto che ad esempio il rilascio di J2SE 1.4 (JDk 1.4) non é seguito di pari passo da J2EE fermo per il momento alla release 1.3.

Java2 ed i Web Services
A JavaOne è apparso chiaro quanto ormai tutte le aziende stiano puntando su questa tecnologia. Da molte parti é arrivato il segnale che indica i web services come un importantissimo strumento di integrazione: si pensi ad esempio alla nuova specifica EJB 2.1 alla quale é stato aggiunta la possibilità di invocare un web services da parte di un session bean (per adesso di tipo stateless). Altro esempio sicuramente molto importante è quello relativo all'annuncio della aggiunta alla J2ME di una serie di API che dovranno permettere l'invocazione di web services alle applicazioni basate sulle configurazioni CDC e CLDC.
I web services sono stati presentati più come strumento di standardizzazione ed evoluzione del protocollo SOAP tramite l'utilizzo di WSDL, che come meccanismo di integrazione fra imprese tramite lookup e discovery secondo la filosofia alla base di UDDI. A conferma di ciò si può trovare sicuramente quanto detto da Tim Roth di Sun nell'intervista di cui Giancarlo Crocetti nel suo articolo MokaAmerica (www.mokabyte.it/mokamerica) questo mese riporta un breve stralcio.

Figura 3 - Gli standard aperti basati su XML e SOAP rappresentano
lo strumento per la integrazione delle architetture del prossimo futuro

Figura 4 - I web services permetteranno di integrare architetture
e tipologie di applicazioni differenti in modo da offrire un più ampio
spettro di servizi in modo più semplice per l'utente finale

Personalmente sono perfettamente d'accordo con tale modo di vedere il futuro tecnologico di Java e non solo: immagino infatti ancora lontanissimo il momento in cui una azienda possa utilizzare dinamicamente i servizi messi a disposizione da altre aziende tramite l'utilizzo di registri comuni e remoti (e questo più per motivi culturali che tecnologici).

Convesational Web Services
Una delle presentazioni alle quali ho potuto assistere e che mi ha particolarmente impressionato é stata quella dei web services che implementano meccanismi di comunicazione di tipo conversazionale con il client. Tale meccanismo, tramite poche istruzioni inserite in un file XML (per la verità l'ambiente di sviluppo di Bea permetta di fare tutto in modo visuale con una semplicità incredibile) é possibile raggruppare più web services in modo da creare una vera e propria conversazione. In questo modo, il client invoca il primo web service il quale non risponde direttamente al client ma passa il controllo agli altri della catena; l'ultimo servizio invocato invia una risposta al client.
Il meccanismo ricorda molto da vicino le servlet chain, ed anzi potrebbe essere visto come un modo per rivedere in chiave moderna quello che già si poteva fare in passato con tecniche differenti. Sempre utilizzando il tool di Bea é possibile realizzare sistemi temporizzati (ovvero introdurre un delay nella catena delle chiamate dei vari servizi); infine si possono implementare tecniche di buffering sulle chiamate dei servizi tramite l'utilizzo di code di messaggi JMS.
Per il momento i web services conversazionali non mi pare che possano essere considerati uno standard offerto da tutti i server (infatti é stata presentata in un workshop di Bea durante la presentazione del nuovo ambiente di sviluppo di Bea), ma presumo che non si dovrà attendere molto per vedere tale tecnica divenire uno standard accettato ed integrato in J2EE.

Figura 5 - Una esempio di unione di due web services per la
realizzazione di una conversazione con il client

Tutte queste novità hanno sicuramente l'obiettivo di proporre i web services come strumento di connessione nelle architetture distribuite, indipendente dal protocollo utilizzato. I WS consentono infatti di implementare sistemi di RPC asincrono multithread in modo semplice e leggero, è sicuramente un aspetto molto importante quando l'obiettivo del progettista non sono tanto le performance secche, ma piuttosto la scalabilità e la capacità di reggere grossi carichi di lavoro.
Queste considerazioni si sposano perfettamente con quanto Sun aveva già definito ad esempio all'interno della piattaforma EJB: il fatto quindi che tramite la specifica EJB 2.1 sia stata aggiunta la possibilità ad un bean EJB di interagire con un web services non e' casuale.

Web Services e la piattaforma .net
Sempre per quanto riguarda il mondo dei web services, interessante notare come in molte occasioni i vari speaker hanno mostrato come utilizzare tale tecnologia per l'integrazione con altre piattaforme, prima fra tutte la piattaforma .net di Microsoft.
In tal senso, nonostante l'indubbio vantaggio ormai accumulato da Java2 e la fiducia che le varie case produttrici di software ed hardware ripongono ormai in tale tecnologia, era palpabile nell'aria un certo nervosismo. Come ho più volte avuto modo di osservare, non credo che la imminente piattaforma .net possa impensierire quanto Java ha dimostrato di poter offrire: la casa di Seattle ha più o meno dichiaratamente espresso la volontà di aggredire, tramite .net, il terreno proprio adesso di Java e Unix.
Se da un lato il ritardo rispetto alla concorrenza è molto (Java ha ormai superato la fase in cui era una tecnologia embrionale e poco stabile, per diventare oggi una piattaforma potente ed universalmente accettata), Microsoft ha da sempre dimostrato di disporre del potere necessario per potersi permettere il lusso di compiere molti errori o di accumulare grosso ritardo. Il settore enterprise è però da sempre uno scenario dove standard aperti, portabilità, stabilità degli applicativi e della piattaforma sottostante ed infine gestione della sicurezza sono caratteristiche irrinunciabili. Tutto queste caratteristice rappresentano anche gli aspetti che da sempre caratterizzano in negativo la piattaforma Microsoft.
In conclusione prevedo che la spartizione/separazione dei due mondi (il lato server di fascia alta a Java, il client-desktop a MS) debba considerarsi ancora per molto tempo il tema dominante dello scenario IT mondiale.
Java da questo punto ha innegabilmente un vantaggio dato dalla dominante posizione nel mondo J2ME, zona dove Microsoft al momento è tagliata fuori.
Questo Sun lo sa bene, tanto che più volte i web services sono stati presentati come lo strumento per integrare i due mondi. É sorprendente come in una delle molte sessioni dimostrative si sia utilizzato l'ambiente VC++ di Microsoft per realizzare una applicazione stand alone in C++ che si interfacciasse con un web service scritto in Java.

JXTA
JXTA (pronuncia Jaxta) é una interessante materializzazione della mente geniale di Bill Joy, il padre di Java che già in passato aveva contribuito alla creazione di tecnologie distribuite come il famosissimo NFS.
Presentata quasi un anno fa' sembra che JXTA si appresti a diventare la prossima rivoluzione tecnologica legata alla rete.
Almeno questo é quello che sta proponendo Sun. In effetti la tecnologia é quanto mai interessante: un sistema peer to peer in grado di astrarsi dalla piattaforma sottostante e dal protocollo di esecuzione (HTTP, TCP, SMTP, RMI).
JXTA potrebbe essere semplicisticamente descritto come un Jini rivisto e corretto. In tal senso la scarsa diffusione del mago della lampada (Jini appunto) ed la limitata accettazione da parte dell'industria e dei vari produttori, sono probabilmente da imputarsi alla impostazione di base di Jini (protocollo proprietario, tecnologia non aperta ad altri standard differenti da Java, concetto di registry centralizzante); Sun sembra che abbia fatto tesoro delle esperienze del passato proponendo JXTA, una tecnologia altamente innovativa ma basata su un concetto rivisto di network cooperativo.
E' stato eliminato infatti il concetto centralizzato e centralizzante di reigistry (il modello di base é il peer to peer appunto) e non sono più utilizzati protocolli proprietari, per dar spazio a concetti come peer to peer, pipe, advertise, e multi hop cooperative network, che complessivamente dovrebbero dare un maggiore impulso alla diffusione di Java.
Personalmente credo che ancora molti siano aspetti lasciati in sospeso tali da richiedere approfondimenti e rivisitazioni: la mancanza di un registry e l'adozione del peer to peer comporta da un lato un notevole volume di traffico anche per le operazioni più semplici, ma anche il problema della identificazione dei peer. Tale carenza induce la mente a pensare alle questioni legate ai diritti d'autore sul software ed altri prodotti d'intelletto (si pensi ad un naptser peer to peer in cui nessun content provider possa essere univocamente identificato), o peggio ancora a peer aventi scopi illegali (riciclo di denaro, pedofilia etc..).
Sicuramente a parte gli scenari pessimistici appena citati, il modello rappresenta un ottimo punto di partenza su cui lavorare per le successive evoluzioni di questa tecnologia. Ad esempio un sistema di DNS dinamico e distribuito potrebbe risolvere la maggior parte dei problemi legati alle prestazioni (traffico di rete) e di sicurezza.
E' però vero che dopo un anno dalla sua presentazione, JXTA rappresenta una interessantissima tecnologia, ma che stenta ad affermarsi come rivoluzione prossima ventura.
La comunità degli sviluppatori é cresciuta moltissimo in questo periodo, ma ancora nessuno dei big sembra abbia fatto una qualche mossa ufficiale. Insomma l'idea é buona ma ancora grossi pezzi del muro sono mancanti. Positivo il fatto che non si intravede al momento nessun vincolo strutturale o progettuale che permetta di trovare i mattoni giusti.
JXTA mi ricorda una volta di più che troppo presto equivale in genere a troppo tardi; speriamo in questo caso che non sia così.

Figura 5 - Il logo di JXTA

Per chi fosse interessato ad approfondire l'argomento Sun ha realizzato un sito dedicato a JXTA che si trova all'url http://www.jxta.org.

J2ME
Moltissime le novità nel settore embedded-wireless. Finalmente sin sono viste molte implementazioni di JVM per diversi dispositivi: molti i cellulari presentati con JVM integrata, ma anche palmari (Sharp ha presentato il nuovo Zaurus basato su sistema operativo Linux).

Figura 6 - Zaurus, il palmare basato su Linux,
è stato presentato in anteprima da Sharp a JavaOne.
Da oggi Apache e sito web sul palmare non sono più fantascienza.

Elevato l'interesse dei produttori di cellulari si è finalmente concretizzato dando inizio al processo di rilascio di cellulari con JVM integrata. Sembra finalmente che la tanto attesa era del Java embedded sia iniziata.
Sun ha annunciato il rilascio del MIDP profile 2.0 con interessati novità, ma anche l'integrazione dei web services per la J2ME. Questa in particolare è una delle novità fra i le più interessanti di tutto JavaOne: è la dimostrazione della potenza di Java come tecnologia in grado di offrire soluzioni a 360° per la realizzazione di applicazioni enterprise. Dalle pagine JSP alla applicazione stand alone ai componenti EJB, dal database al telefono cellulare o palmare tutto può essere integrato tramite la medesima tecnologia.
Erano anni che si prometteva l'ottenimento di questo risultato e sembra che finalmente le promesse inizino a concretizzarsi.
Avendo passato un bel po' di ore a risolvere il problema della comunicazione client-palmare con applicazione EJB tramite XML e SOAP, valuto questo annuncio particolarmente interessante.
JXME (questo il nome che dovrebbe avere la nuova API) dovrebbe mettere a disposizione parser minimali XML e runtime per JAXRPC effettuando una operazione di subsetting delle API attualmente disponibili. Il tutto senza alterare quelli che sono gli standard definiti dai vari W3C e OASIS.
La cattiva notizia é che si dovrà attendere ancora un bel po' di tempo per poter utilizzare i web services, SOAP e quant'altro su un telefono o un palmare, (a patto di non fare tutto a mano) visto che la data del rilascio di queste API é stata annunciata per l'estate del 2003. JXME verrà rilasciata per le configurazioni CDC e CLDC.

EJB 2.1
Sebbene questa nuova release non rappresenti una novità presentata a JavaOne, alla conference se n'è parlato molto. Le innovazioni più interessanti introdotte con questa nuova specifica sono essenzialmente tre: la possibilità di creare bean message-driven basati su messaggistica JAXM, a fianco del sistema di comunicazione JMS; l'introduzione di un nuovo servizio di timer nel container che potrà essere utilizzato per effettuare chiamate in callback sui beans in particolari momenti della giornata oppure a periodi prederminati; l'ampliamento del linguaggio di interrogazione EJB QL (con il supporto per alcune delle più comuni operazioni di interrogazione come le aggregazioni e gli ordinamenti); la possibilità di definire in fase di deploy il legame fra ascoltatori e produttori di messaggi; il supporto per i web services, grazie al quale non solo è possibile invocare un web service da un enterprise bean, ma anche associare un business method ad un web service in modo da permetterne l'invocazione remota.
Quest'ultima associazione verrà effettuata in modo pressoché automatico dal contaier sulla base della interfaccia remota corrispondente al web services ed alle informazioni contenute nel file di deploy (il meccanismo è molto semplice e ne parleremo in uno dei prossimi articoli).
Fra tutte le presentazioni basate su XML (JAXM e WebServices) sono quelle di cui di più si é parlato e possono essere prese ad esempio dello sforzo di Sun di integrare le differenti tecnologie di fascia enterprise. Probabilmente l'accoppiamento EJB-web services rappresenta una delle innovazioni più interessanti e implica conseguenze non di poco conto. Si pensi ad esempio alla possibilità di mettere in comunicazioni più applicazioni basate su EJB tramite il supporto dei web services. Se XML e EJB possono spaventare per quanto riguarda le prestazioni, si pensi alla possibilità di scalare in modo semplice e veloce una architettura distribuita in modo da garantire maggiore tolleranza in caso di un aumento delle prestazioni.
Quando si potrà disporre di una implementazione di EJB 2.1 non é al momento dichiarato, anche se ufficialmente é stato annunciato il rilascio in contemporanea con il J2EE 1.4

Flash Gateway
Macromedia quest'anno era presente in qualità di sponsor platinum alla manifestazione. Se fino alla settimana scorsa non riuscivo a comprendere a fondo l'interessamento di questa azienda al mondo Java (tanto da farle acquisire JRun), tutti i dubbi sono spariti appena ho assistito alla presentazione di Flash Gateway. Il nuovo prodotto server, che si integra con il ben noto plugin client side, dovrebbe rappresentare una vera e propria rivoluzione proponendosi come sistema per la realizzazione di applicazioni in esecuzione in un browser, andando a prender il posto lasciato per il momento vacante dalle applet.
Flash Gateway fornisce accesso di alto livello tramite il protocollo HTTP ad applicazioni client side in esecuzione all'interno del browser. Il modulo server é rappresentato da uno o più servlet che consentono in modo automatico la comunicazione con il client.
Utilizzando una terminologia in voga in questo momento il prodotto di Macromedia consiste in una serie di web services per il momento compatibili con JRun e WebLogic; Macromedia a tal proposito afferma che presto la compatibilità verrà allargata anche agli altri application server dato che per adesso Flash Gatetway utilizza solo alcune classi proprietarie di JRun (quelle legate al meccanismo di autenticazione). Facendo le debite considerazioni ed adattamenti, già adesso Gateway potrebbe essere utilizzato con altri server.
La dimostrazione che ho avuto modo di vedere é stata realmente impressionante in quanto a potenza espressiva: le applicazioni Flash adesso non solo permettono la visualizzazione di accattivanti animazioni, ma altresì rappresentare una valida alternativa alle applet, non avendo in tal caso nessun vincolo di compatibilità con i browser. Il client deve infatti supportare il plugin Flash 6 (la prossima versione): si presume che in questo caso Microsoft non desideri ostacolarne la diffusione eliminando il plug in dal proprio browser ma non é detto, visto quello che è successo con il plugin Java o QuickTime.
La potenza espressiva del linguaggio di programmazione di Flash é sicuramente limitata (ambiente script based alla Visual Basic senza OOP, ma con il concetto della timeline); si deve però considerare che in questo caso il client deve essere considerato come un estensione minimale del server e che deve svolgere pochissime operazioni, nessuna funzione di business logic, ma piuttosto semplice visualizzazione dei dati e gestione della interazione con l'utente.
Per quello che ho potuto vedere questo obiettivo é stato brillantemente raggiunto grazie anche all'introduzione di una serie di widget nuovi molto belli e potenti. L'assunzione secondo la quale il client deve fare il client in questo caso é quanto mai adatta.
Maggiori informazioni su Flash Macromedia possono essere ottenute all'indirizzo http://betaprograms.macromedia.com/nozomi

La nota di colore
Come ormai sono uso fare ad ogni trasferta statunitense, scelgo un evento particolare come la nota di colore da raccontare ad amici e colleghi. Quest'anno la nota di colore è stata eletta ufficialmente una cosa capitatami in albergo la penultima notte: il venerdì sera, a termine della cinque giorni statunitense dedicata a Java, immerso nei miei pensieri relativi al futuro di Java ed alla probabile lotta che ci apprestiamo a vedere in atto fra J2EE e .net, mi accingevo ad andarmene a letto quando una delle emittenti della televisione via cavo dell'albergo é andata in crash, mostrando un notissimo blu screen tipico del sistema Windows NT. Anche se in genere non sono solito assecondare guerre di religione legate alla battaglia legale Sun vs Microsoft, la cosa in se mi è apparsa alquanto buffa, ed ho deciso che era mio preciso compito immortalare il bug televisivo.

Figura 7 - Vedere uno schermo blu anche alla televisione è
una esperienza che ricorda gli scenari da fantapolitica di George Orwell

Mi sono addormentato ripensando ad una frase di un collega italiano che affermava come Microsoft abbia indotto a considerare normale che un software possa essere non stabile. Non so se questa cosa sia vera, ma quando il sonno infine ha vinto ogni mia ultima resistenza, ricordo che stavo ironizzando sul fatto che probabilmente questa cosa non sarebbe mai successa se la televisione avesse utilizzato Unix e Java come piattaforma di base.
Buonanotte e sogni doro, anzi no, sweet dreams….

Conclusioni
Quest'anno JavaOne ha visto un pubblico sicuramente ridotto rispetto agli anni passati (si parla di appena 10.000 persone) sia per la crisi che ha stravolto il mondo dell'informatica, sia per l'organizzazione della edizione giapponese di JavaOne (e di fatti era del tutto assente il pubblico orientale).
Nonostante questo si sono notati alcuni importanti segnali di ripresa: innanzi tutto interessante il coinvolgimento di aziende che fino ad ieri seguivano solo marginalmente il mondo Java (solo per fare un nome Nokia quest'anno era uno degli sponsor principali, così come Motorola e Macromedia).
L'esplosione del settore wireless-embedded ha dato finalmente dimostrazione della supremazia di Java in questo settore dove non esistono tecnologie concorrenti in grado di offrire lo stesso livello di flessibilità ed integrazione con il lato server.
Insomma è stato un Java One sicuramente molto interessante, denso di novità e di segnali positivi. Sun da 6 mesi a questa parte ha iniziato nuovamente a correre e sfornare novità a ripetizione, una più interessante e promettente dell'altra. E' indubbio che sarà impossibile seguire tutte queste novità, e solo il tempo potrà far comprendere cosa effettivamente sia utile ed importante. La regola che si dovrebbe tenere a mente per i prossimi due anni é che probabilmente 24h al giorno potrebbero non bastare per rimanere allineati con tutte le nuove uscite.
Forte è però la sensazione che questa nuova attività produttiva abbia due scopi paralleli, oltre a quello prettamente legato al progresso tecnologico. Da un lato cercare di dare nuovamente fiducia ad un settore che risente ancora della crisi appena passata, dall'altro fornire un segnale forte alla comunità degli sviluppatori Java circa lo stato di salute (buono) della piattaforma Java2 ora che Microsoft sta per rilasciare il suo .net.