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 prendere 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:

<mx:Panel title="DataGrid Control Example" height="100%" width="100%"
  paddingTop="10" paddingLeft="10" paddingRight="10">
  <mx:Label width="100%" color="blue"
    text="Select a row in the DataGrid control."/>
  <mx:DataGrid id="dg" width="100%" height="100%" rowCount="5" dataProvider="{employees}">
    <mx:columns>
      <mx:DataGridColumn dataField="name" headerText="Name"/>
      <mx:DataGridColumn dataField="phone" headerText="Phone"/>
      <mx:DataGridColumn dataField="email" headerText="Email"/>
    </mx:columns>
  </mx:DataGrid>
</mx:Panel>
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
}
/**
 * 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;
  }
}