In questa prima puntata della serie su Flex 2 e Java, viene presentata una panoramica sul mondo delle Rich Internet Applications (RIA), sulle tecnologie oggi disponibili per realizzarle, sulla diffusione del Flash Player e sulle potenzialità che uno strumento come Flex 2 può offrire agli sviluppatori Java.
Una breve retrospettiva sulle RIA
Non è la prima volta che i lettori di MokaByte sentono parlare di Rich Internet Application.
Per Rich Internet Application (RIA) si intendono applicazioni web che hanno le caratteristiche e le funzionalità delle tradizionali applicazioni desktop (cioè residenti sul computer). Nelle RIA tipicamente è trasferita a livello client la parte dell‘applicazione che processa i dati e fornisce una pronta risposta all‘interfaccia utente, mentre la gran parte dei dati e dell‘applicazione rimane sul server.
Sviluppare applicazioni Internet con Java EE di solito consiste nell‘utilizzare, per lo strato di presentazione, framework quali Spring (http://www.springframework.org/), Struts (http://struts.apache.org/) o Tapestry (http://jakarta.apache.org/), solo per citarne alcuni. Tutti questi ambienti seguono l‘architettura del Model-View-Controller e generano come output codice HTML.
Ad ogni azione dell‘utente all‘interno dell‘applicazione, il server genera una nuova risposta che di nuovo espone all‘utente la possibilità di richiedere altre informazioni effettuando altre richieste al server. L‘approccio allo sviluppo di applicazioni web incarnato dal concetto RIA sta nel superare le limitazioni imposte dal classico modello request/response e nel gestire i limiti connessi al presentation layer. Il modello request/response prevede che l‘intera pagina HTML venga ricaricata per ogni click dell‘utente, anche se la richiesta al server era solo di pochi dati.
Anche se il termine Rich Internet Application non fa riferimento a nessuna tecnologia in particolare, non possiamo ignorare il fatto che è stato coniato nel lontano 2001 da ingegneri di Macromedia, e che per anni il termine è stato associato esclusivamente alla piattaforma Flash (e quindi al formato SWF).
La piattaforma Flash supporta la diffusione dei contenuti, delle applicazioni dinamiche e della comunicazione attraverso l‘interazione con una varietà di soluzioni (browser, dispositivo mobile, computer client desktop, set-top box, e così via) che rappresentano una vasta gamma di sistemi operativi, form factor e fornitori di contenuti.
L‘architettura di questa piattaforma non è solo un plug-in lato client, il Flash Player appunto, ma un sistema completo con una tecnologia server dedicata, un‘integrazione back-end, un modello di programmazione, uno strumento di sviluppo, soluzioni incorporate e, ovviamente, il runtime universale.
Il runtime client di Flash ha ottenuto un enorme successo: è installato sul 98% dei PC connessi ad Internet. Questo successo può essere attribuito alla ridotta struttura (inferiore a 1 MB), alla facilità di sviluppo e di aggiornamento, ai continui investimenti (prima di Macromedia, e adesso di Adobe che l‘ha inglobata) sulle prestazioni del prodotto, al tipo di sistema di sicurezza, al formato SWF che permette alle terze parti di uscire con il formato Flash e alla elevata qualità delle “esperienze” rilasciate.
Nota dolente di questo “ecosistema” erano il modello di programmazione e l‘ambiente forniti agli sviluppatori per creare questo tipo di “esperienze”: Flash. Flash offre un ambiente di sviluppo lontano anni luce dal classico modo di sviluppare in ambienti Java ma anche .NET. Il concetto di linea temporale su cui dovevano essere distribuiti gli elementi (grafici e non) dell‘applicazione, unito a un pessimo editor di scrittura (ma anche e soprattutto di debug) hanno presto fatto etichettare Flash come un IDE per designer. Senza parlare delle prima versione di ActionScript, un linguaggio di scripting che aveva non poche limitazioni e che non permetteva agli sviluppatori di applicare approcci di programmazione Object Oriented o di “best practices”.
Anche chi, come me, apprezza notevolmente Flash ha subito diverse frustrazioni durante lo sviluppo di applicazioni web create con quell‘IDE.
Adobe ha saputo ammettere i propri limiti e ha ascoltato la comunità degli sviluppatori, offrendo loro uno strumento diverso, più potente e uniforme agli altri ambienti per lo sviluppo di Rich Internet Application: Adobe Flex 2.
In questo articolo si intende fornire al lettore un approccio pratico per capire come, ma soprattutto perché, può essere conveniente integrare Adobe Flex 2 nelle proprie architetture Java EE.
perché non usare solo Java per le RIA
Quali sono le spinte che fanno evolvere e crescere un linguaggio di programmazione? Sun ha avuto molti spunti su cui riflettere in questo ultimo periodo e si è forse resa conto che portare avanti il concetto di ubiquità e di “deploy once” cominciava a non funzionare più così bene. Alla Sun non dimenticheranno facilmente la pesante dichiarazione di Steve Jobs durante la presentazione dell‘iPhone, in cui l‘amministratore delegato di Apple afferma che “Non vale la pena di sviluppare in Java. Nessuno più usa Java. È una gran palla al piede”. Per quanto criticabile, questa affermazione, che si riferisce specificamente al mondo Java ME, ha denunciato un malcontento che stava cominciando a diffondersi riguardo al mondo Java. Le applet Java sono state un altro esempio di tecnologia che ha deluso molte aspettative. Un duro colpo da incassare per Sun.
Un grande freno all‘adozione di questa e di altre modalità di sviluppo con Java sul web è stato il problema dell‘installazione, unito a una non esaltante “esperienza sensoriale” per gli utenti.
Se il Java Runtime Eviroment fosse stato nativamente presente sui browser, tutti avrebbero cominciato a sviluppare applicazioni web con Java. E invece la procedura di installazione del JRE continua ad essere ostica all‘utente medio-basso di internet. Un po‘ come è accaduto alle prime distribuzioni di Linux, che solo esperti del settore erano in grado di installare. Ma oltre al problema della penetrazione del JRE e della sua non facile procedura d‘installazione, bisogna anche considerare la scarsa “user experience” che è stata fornita agli utenti con le applet web.
Gli ultimi eventi hanno portato la Sun ad apportare delle modifiche alla sua strategia. La nuova versione EJB3, per esempio, ha preso lezioni da Hibernate e Struts, anche se ancora molti sviluppatori preferiscono questi due framework agli EJB3.
Le caratteristiche proposte per la versione di Java 7 fanno intuire come la Sun abbia capito di avere un vero rivale: Microsoft C#.
Nonostante questi sforzi, gran parte della comunità di sviluppatori sul web oggi si appoggia ad AJAX. La popolarità di AJAX è dovuta al fatto che tutto quello di cui l‘utente ha bisogno è già installato sul suo sistema. I browser supportano nativamente Javascript.
Ma quali sono le limitazione nell‘utilizzo di AJAX o anche di Java per il web che siamo costretti a subire quando cominciamo a sviluppare un‘applicazione web?
- HTML è “povero”: l‘HTML è nato come linguaggio dichiarativo per la navigazione tra documenti e svolge benissimo questo lavoro, ma dimostra limiti enormi in tutti gli altri scenari in cui gli si chiede di offrire e gestire interfacce utente complesse e “ricche”.
- Inconsistenza dei CSS: nonostante i CSS siano una tecnologia presente sul web da molti anni, ancora ci sono forti incompatibilità con i browser e funzionamenti incoerenti tra una versione e l‘altra.
- Tempi e costi nello sviluppo di applicazioni AJAX: è vero affermare che AJAX è Javascript. E che imparare a programmare bene in Javascript non è poi così difficile. Ma ben diverso è diventare un esperto di Javascript per farlo funzionare su tutte le varie versioni dei browser e su differenti sistemi operativi. Molti lettori in questo momento staranno pensando alla frustrazione che hanno provato nel rendere il proprio codice Javascript cross-platform e nel far funzionare tutte le features della propria applicazione sui vari browser.
- Lunghe fasi di testing e debugging: le applicazioni AJAX hanno una lunga e non semplice fase di debugging e di testing. Per il problema elencato sopra, tutto quello che sviluppiamo deve essere testato su differenti browser, differenti versioni e differenti sistemi operativi. Anche se è vero che esistono librerie già pronte per sviluppare in AJAX (la Google Web Toolkit fa un lavoro egregio nel compilare codice Java in Javascript lato client) e che risolvono i problemi legati alle incompatibilità con i browser, è pur vero che, se voglio crearmi degli oggetti non presenti nella libreria, devo essere un esperto del Javascript.
- Applicazioni Occasionally Connected: il modello request/response della applicazioni web classiche non supporta la possibilità di far funzionare l‘applicazione anche quando l‘utente non è connesso a Internet.
Alcune di questi punti sono stato superati con AJAX, sebbene questa tecnologia continui ad avere grosse limitazioni dovute alle inconsistenze dei browser.
Esiste tuttavia una soluzione tecnologica che risolve tutti i problemi elencati sopra: il Flash Player.
Il Flash Player
La fama e il successo del Flash Player è cresciuta esponenzialmente col tempo grazie alla massiccia adozione del player all‘interno dei browser ma soprattutto alla possibilità di creare interfacce per l‘utente ricche e interattive.
L‘aggiornamento del player è automatico e, nel momento in cui si carica un contenuto SWF compilato per una versione superiore, avviene in maniera contestuale al sito, senza dover mandare l‘utente su una pagina diversa per completare il download.
Il Flash Player esiste per 3 differenti piattaforme: Windows, Mac e Linux; a parte piccole differenze di prestazione, non ci sono hacking o accorgimenti da attuare per rendere l‘applicazione veramente cross platform.
Il formato SWF, quello che gira sul Flash Player, permette di caricare contenuti multimediali sia audio che video. Incorpora inoltre due codec per i video: Sorenson e On2.
Senza stare a spiegare tutti i vantaggi nell‘uso del formato Flash Video, basti considerare che YouTube e Google Video hanno scelto questo formato per la visualizzazione dei loro video.
In questo contesto, qual è lo strumento che permette in modo veloce ed efficace di creare Rich Internet Application basate sul formato SWF? È Adobe Flex 2.
La linea di prodotti Flex 2
Avendo l‘occasione di partecipare come presentatore alla maggior parte dei tour di Adobe sulle tematiche RIA, Flash e Flex 2, mi sono accorto che una grossa fetta dell‘utenza associa Flex a Flash.
Comprendo benissimo le lamentele dei programmatori, che vedono Flash come un ambiente di sviluppo privo di molte caratteristiche ormai usuali per gli sviluppatori provenienti da ambienti più classici (Java, C++, C#). Flash, del resto, è nato come strumento per creare animazioni in grafica vettoriale. Anche se si è evoluto in maniera esponenziale, sia dal punto di vista dell‘interfaccia che da quello del linguaggio di programmazione, conserva ancora il suo modello di authoring diretto da una linea temporale, da livelli, dalla libreria di oggetti grafici e multimediali.
Ma quando parliamo di Flex parliamo di tutt‘altra cosa. Cercherò quindi di fare chiarezza su cosa si nasconde dietro alla linea di prodotti Flex 2. La famiglia di prodotti Flex 2 consiste in una serie di tool che permettono lo sviluppo e il deploy di Rich Internet Application:
- Adobe Flex 2 SDK (Software Development Kit)
- Adobe Flex Builder 2
- Adobe Flex Data Services 2
- Adobe Flex Charting 2
Il Flex 2 SDK rappresenta un‘infrastruttura di sviluppo basata su componenti per la distribuzione di RIA per il client runtime Flash Player. Supportano tutti i metodi di connessione a dati e servizi di back-end. L‘SDK di Flex 2 è completamente gratuito e include la libreria di classi Flex e il compilatore per i linguaggi MXML e ActionScript 3.0 (http://www.adobe.com/products/flex/sdk/).
Il Flex Builder 2 è l‘ambiente di sviluppo integrato basato su Eclipse per la programmazione di RIA, che coniuga le funzionalità avanzate delle applicazioni desktop con le potenzialità multipiattaforma del Flash Player. La possibilità di usare un ambiente di programmazione come Eclipse fa già intuire l‘enorme differenza rispetto a un ambiente come Flash. Flex Builder consente agli sviluppatori di creare rapidamente logiche complesse per il lato client che integra XML, servizi web o chiamate a classi remote. L‘IDE, come i più evoluti ambienti di sviluppo, offre un approccio component-based. Utilizzando gli strumenti di progettazione e layout, si possono creare interfacce utente per applicazioni personalizzate, più semplici da utilizzare e più ricche di funzionalità .
La Flex Component Explorer è un‘applicazione Flex ottima per l‘apprendimento rapido di tutti i componenti messi a disposizione con le Flex 2 SDK e presenti nell‘ambiente Flex Builder 2 (http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html)
Il component Explorer permette di navigare e preder confidenza con tutti i componenti presenti nelle Flex 2 SDK
Il linguaggio utilizzato per definire l‘interfaccia utente dell‘applicazione è il linguaggio MXML, un linguaggio basato su XML che attraverso la dichiarazione di tag permette di inserire componenti e di interfacciarli ai Data Model. ActionScript 3 viene utilizzato per la programmazione lato client e la gestione degli eventi.
Nella seguente porzione di codice presa dal listato1.mxml (scaricabile come allegato dal menu in alto a sinistra) si può facilmente intuire la semplicità del linguaggio, che in questo esempio crea un pannello all‘interno del quale inserisce un‘etichetta e un DataGrid:
paddingTop="10" paddingLeft="10" paddingRight="10"> text="Select a row in the DataGrid control."/>
Il linguaggio a tag MXML e il codice ActionScript vengono poi compilati in SWF. Il Flex Builder 2 in fase di compilazione converte tutto il codice MXML in classi ActionScript (in Flex 2 ogni componente ha la sua corrispondente classe ActionScript); successivamente viene compilato il file SWF pronto per essere distribuito come applicazione.
Le applicazioni sviluppate con Flex 2 vengono eseguite all‘interno di un comune browser ma sfruttano la potenza del runtime enviroment del Flash Player 9 per eseguire la logica client side, effettuare il rendering degli elementi grafici e visuali, riprodurre animazioni, audio e video.
Il Flash Player 9 supporta una nuova e più performante versione di ActionScript 3, il linguaggio di programmazione che si usa per le RIA. Inoltre il Flash Player può dialogare e interagire con Javascript o elementi HTML caricati nel browser. È così che applicazioni AJAX possono integrarsi ad applicazioni Flex. Google Finance (http://finance.google.com/) è un classico esempio di integrazione tra le due tecnologie.
Con la versione 2 di Flex, non è richiesta l‘installazione di nessun software sul proprio Web Server. Infatti la compilazione in formato SWF avviene in fase di authoring, prima di fare il deploy dell‘applicazione. Si può decidere di compilare utilizzando il compilatore interno di Flex Builder 2 o il compilatore da command line mxmlc.exe, distribuito gratuitamente nelle Flex 2 SDK. Nel prossimo articolo vedremo che è anche possibile utilizzare il compilatore web dei Flex Data Services.
I Flex Charting sono un set di componenti dedicati ai grafici e diagrammi interattivi che consentono di realizzare interfacce dati complesse e analisi interattive.
L‘ultimo tassello della famiglia di prodotti Flex 2 sono i Flex Data Services, un‘applicazione server Java EE da integrare all‘interno dell‘esistente architettura Java EE per sviluppare applicazioni enterprise che comunicano con classi remote Java. Offrono inoltre una gamma di avanzate funzionalità per la gestione dati sul lato server, che consente agli sviluppatori di distribuire rapidamente applicazioni Flex che utilizzano un‘elevata quantità di dati. I Flex Data Services, basati su una solida architettura di messaggistica, si integrano con il middleware standard esistente e offrono servizi per l‘automazione della sincronizzazione dei dati tra client e server, per l‘ulteriore supporto del push dei dati in tempo reale e della messaggistica di pubblicazione/sottoscrizione e per l‘utilizzo di applicazioni di collaborazione connesse occasionalmente.
ActionScript 3 sempre più Java oriented
Dietro tutta l‘architettura delle Flex 2 SDK c‘è ActionScript 3, il nuovo linguaggio di programmazione che ha preso seriamente ripetizioni da Java e C# per fornire agli sviluppatori un nuovo e potente linguaggio OOP.
Semplicità sicurezza, performance e compatibilità . Sono questi gli obiettivi che hanno guidato il Flash Team per la creazione del nuovo ActionScript 3, il linguaggio Object Oriented che ha reso Flash un ambiente di sviluppo non solo per applicazioni ricche e interattive, ma anche per lo sviluppo di complessi e delicati progetti: le Rich Internet Application.
ActionScript 3 offre un robusto modello di programmazione che finalmente riduce le distanze con i linguaggi di programmazione più evoluti e diffusi come il Java e il C#.
Inoltre la nuova Virtual Machine denominata AVM2 che esegue il codice Actionscript 3.0, aumenta drasticamente le performance rispetto alla versione precedente (AVM1), che continuerà comunque ad essere supportata. Questo significa che le vecchie applicazioni scritte con Actionscript 2 continueranno a essere eseguite e caricate dalla nuova Virtual Machine.
L‘AVM2 fa parte del nuovo Flash Player 9, che ha già raggiunto ottime statistiche di penetrazione sulle macchine degli utenti mondiali raggiungendo a settembre del 2006 il 36% di media. A questo indirizzo è possibile recuperare in dettaglio tutte le statistiche divise per versione
http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
ActionScript 3 è basato sullo standard ECMAScript terza edizione e contiene anche alcune implementazioni che si trovano nella quarta edizione. Questo aggiunge nuove caratteristiche al linguaggio come il supporto al E4X, un potente sistema per la manipolazione di dati XML che riduce la quantità di codice da scrivere per effettuare il parsing e lavorare con XML.
Il supporto per le espressioni regolari è nativo, per aumentare l‘efficienza nella ricerca e manipolazione di stringhe.
È favorita la comunicazione delle applicazioni Flash con differenti protocolli, utilizzando la nuova classe flash.net.socket: sarà così possibile connettersi per esempio a una porta su un computer remoto e dialogare in qualsiasi linguaggio o con qualsiasi input.
Attraverso la classe flash.util.Proxy, è possibile controllare quello che accade nel momento in cui un metodo o una proprietà di una classe è stata creata, settata e cancellata.
L‘ultimo aspetto da mettere in luce in questa breve lista di novità è la classe Loader.loadBytes(), che permette di creare elementi da dati binari direttamente dalla display list.
Parlavamo prima di evoluzione di un linguaggio di programmazione. Sulla base delle richieste della comunità di utilizzatori, Adobe ha orientato il proprio linguaggio di programmazione in modo tale che ActionScript ha subito una notevole crescita, in tempi brevi e in sole tre versioni, trasformandosi da semplice linguaggio di scripting a robusto e potente linguaggio di programmazione.
Integrare Java con Flex 2
Avrete capito che Flex 2 si occupa del Presentation Layer della vostra applicazione definendo l‘interfaccia utente e il modo in cui essa interagisce con l‘utente o con il data model.
Permette inoltre di fare chiamate remote HTTP a qualsiasi linguaggio server side, di collegarsi a web services, di comunicare con classi remote Java, di interfacciarsi a Spring, Hibernate, Struts, migliorando notevolmente l‘esperienza dell‘utente che navigherà la vostra applicazione web.
Questa indipendenza rende Flex 2 uno strumento particolarmente integrabile all‘interno di architetture già esistenti, in quanto un presentation layer è designato a renderizzare l‘interfaccia utente collegandola con qualsiasi business/integration layer, aggiungendo per esempio un thin layer che agisca come delegate ai service components.
Ed ecco quindi che, se volessimo integrare il nostro front end Flex con Spring, basterebbe creare delegate objects che implementano le stesse interfacce che utilizzano i servizi di Spring.
Queste configurazioni avvengono attraverso file di configurazione XML che permettono di scambiare i dati automaticamente tra oggetti Java e classi ActionScript 3 attraverso il gateway AMF (ActionScript Messaging Format), un protocollo binario per lo scambio di dati.
Non avendo il Flash Player nessun componente Java runtime, la comunicazione deve passare attraverso Data Transfer Objects in ActionScript che vengono automaticamente mappati con le classi remote Java attraverso il compiler tag [RemoteAlias].
Ecco un esempio di classe Java remota :
package com.dto.Person;
/**
* Classe Java che rappresenta un utente.
* @hibernate.class table="TestOrder"
*/
public class Person {
private int id;
private String name;
private String surname;
// Getter/Setter functions
}
E questo è l‘equivalente ActionScript 3:
/**
* L‘equivalente classe ActionScript generata
*/
[Bindable]
[RemoteClass(alias="com.dto.Person")]
package com.dto.Person {
class Person {
public function Person(){}
private var id : Number;
private var name:String;
private var surname:String;
// Getter/Setter functions
}
}
Una volta che il Flash Player ha caricato il DTO ActionScript, tutte le informazioni sono scaricate sul client e possono essere collegate (data binding) ai componenti dell‘interfaccia utente.
Conclusioni
In questo primo articolo abbiamo solamente introdotto Flex 2. Abbiamo cercato di far capire la netta differenza con Flash, dal punto di vista dello sviluppo ma anche dell‘ambiente di programmazione.
Infine abbiamo dato i primi assaggi del modo in cui è possibile integrare Flex 2 come strato di presentazione all‘interno di architetture Java EE preesistenti.
Nella prossima parte approfondiremo l‘aspetto tecnico e mostreremo come effettuare chiamate remote a pagine JSP per passare e ricevere dati e come utilizzare i Flex Data Services per far comunicare Flex con EJB3.
Riferimenti
Home Page Adobe Flex 2
http://www.adobe.com/products/flex/
Flex 2 User Group ufficiale Adobe
http://www.augitaly.com/flexgala/
Blog italiano dedicato a RIA e Flex 2
http://blog.augitaly.com
Adobe Developer Center
http://www.adobe.com/devnet/flex
Blog dell‘autore
http://casario.blogs.com