In questo articolo parleremo di BlazeDS, un‘applicazione open source che facilita l‘integrazione tra applicativi Flex e Java. In particolare vedremo come sia possibile scrivere una Rich Internet Application (RIA) in Flex, linguaggio di Adobe, in grado di comunicare con un‘applicazione Java EE lato server.
Introduzione
Il Web 2.0 ci ha abituato a delle applicazioni web con un livello di interazione spiccato. Si parla ormai da tempo di Rich Internet Application, applicazioni costruite con tecnologie tali da superare tutti i limiti delle tradizionali applicazioni HTML, rendendo le applicazioni web sempre più simili (al limite indistinguibili) alle applicazioni desktop. Il risultato finale è che le Rich Internet Application (RIA) offrono all’utente un’esperienza avanzata e più accattivante che garantisce maggiore soddisfazione e un aumento della produttività.
Quando parliamo di Rich Internet Application ci riferiamo evidentemente al front-end di un’applicazione distribuita, che possiede tutte le caratteristiche grafiche delle applicazioni desktop tranne per il fatto che i dati risiedono su un server raggiungibile attraverso una rete (ad esempio Internet).
Java EE è una delle piattaforme più diffuse e complete per creare applicazioni di tipo enterprise; Adobe Flex, dal suo canto, è leader nel mondo delle RIA (Rich Internet Application). Puntare sull’integrazione delle due soluzioni significa puntare nello sviluppo di robuste applicazioni enterprise in grado di fornire delle interfacce accattivanti agli utenti. Inoltre, è possibile salvaguardare gli investimenti già fatti in soluzioni Java e dotare tali applicazioni preesistenti di interfacce web di nuova generazione.
L’integrazione è quindi un elemento chiave di ogni RIA, e nel presente articolo ci occuperemo proprio di questo: integrare un RIA in Flex con applicativi lato server Java-based.
Mokabyte si è già interessata in passato a Flex 2 e ai Flex Data Services, negli articoli di Marco Casario ([1], [2]): quindi faremo tesoro di quanto già detto e ci concentreremo sulle novità introdotte in Flex 3 e sull’evoluzione open source dei Flex Data Service, appunto BlazeDS.
Una veloce panoramica su Adobe Flex
Adobe Flex è un framework open source che permette di creare applicazioni RIA che girano su Adobe Flash Player [1].
Va messo bene in chiaro che, a differenza di Adobe Flash, con cui condivide il player, Flex non è quindi uno strumento di authoring: non ci sono timeline di animazione nel mondo Flex. Flex ha una struttura interamente a componenti (SDK), come DataGrid, Panel, Tree etc…, guidati da eventi e tenuti insieme tramite un robusto data binding. Inoltre ogni componente può essere personalizzato fin nei minimi dettagli, oltre a poter essere esteso per crearne di nuovi.
La programmazione in Flex consta di codice MXML e codice ActionScript 3 (AS3). AS3 è un linguaggio Object Oriented, simile a Java, mentre MXML è un linguaggio XML-based di tipo dichiarativo che viene successivamente tradotto in AS3.
Un’applicazione Flex, dopo la compilazione, può dare origine ad un file SWF da eseguire in un Flash Player, o un file SWC che può essere utilizzato all’interno di altri file .swf. I file .swf vengono inseriti dentro un application server (o web server) e, quando richiesti dagli utenti (all’interno delle pagine web visitate), vengono scaricati localmente nel PC dell’utente e eseguite nel flash player del browser.
Figura 1 – Parti essenziali del framework Flex.
Nonostante lo sviluppo in Flex e in Flash sia totalmente diverso, è importante capire che in entrambi i casi il risultato finale è la creazione di file SWF, il formato compilato della piattaforma Flash.
Flex non è un singolo prodotto, ma una combinazione di differenti tecnologie:
Linguaggi
ActionScript 3 e MXML
Framework di componenti: Flex SDK
L’SDK Flex (conosciuto anche come Flex framework) è un set di user interface components, come liste, pulsanti, grafici che vengono usati per costruire le applicazioni Flex. L’SDK Flex (con l’eccezione del package dei grafici) è open source.
Integrated Development Environment (IDE): Flex Builder
Con Flex Builder si può editare il codice, compilare le applicazioni, effettuare il debug del codice, e analizzare la performance. Flex Builder è un software di proprietà Adobe.
Cross-browser runtime: Flash Player
Le applicazioni Flex girano normalmente in un web browser con il plugin Flash Player. È possibile creare delle applicazioni Flex di tipo standalone usando l’Adobe Integrated Runtime (AIR).
La prossima versione Flex 4, con nome in codice Gumbo, è attualmente alla versione beta 2 e promette interessanti novità oltre a puntare sul potenziamento del ruolo del framework Flex, sia per gli sviluppatori di applicazioni Flex, che per i designer che usano Adobe Flash Catalisi per creare i design. Illustreremo tali importanti novità in un futuro articolo.
Flex 3 vs Flex 2
La prima e più importante osservazione relativa al confronto tra Flex 2 e Flex 3, è che i cambiamenti non sono stati così significativi se confrontati con il passaggio dalla versione 1 (o 1.5) alla versione 2. Con il passaggio da Flex 2 a Flex 3 sono stati effettuati dei miglioramenti e inseriti nuovi componenti, ma tutto quello che era stato scritto in Flex 2 lavora anche in Flex 3.
Con Flex 3 sono stati rilasciati con licenza open source sia il Flex SDK che il compilatore Flex. Vediamo quali sono le novità introdotte con Flex 3 [3][4]
Integrazione con Creative Suite 3 e 4
È stato creato un nuovo componente, il Flex Component Kit per Flash CS3 (e CS4) che permette agli utenti di Flash CS3 (e CS4) di creare componenti che possono essere integrati nelle applicazioni Flex. Gli utenti di Flash possono sviluppare componenti utilizzando il familiare modello a timeline di Flash e dopo possono permettere agli sviluppatori Flex di incorporare tali componenti senza codice aggiuntivo. Inoltre Flex Builder ha ora nuovi wizards per supportare facilmente lo skinning di un’applicazione. I deigners possono creare i loro template con le applicazioni del CS (Flash, Fireworks, Illustrator, o Photoshop) e successivamente uno sviluppatore Flex può importare il lavoro per utilizzarlo come skin dei componenti.
È stata migliorata anche la vista Design del Flex Builder in modo tale da fornire una preview più accurata delle interfacce. È stato introdotto un Editor CSS visuale che permette agli sviluppatori di modificare la grafica dei componenti.
Lavorare con i dati
Molto spesso le applicazioni RIA hanno la necessità di manipolare dati che si trovano su un server. Flex fornisce diversi servizi per accedere a questi dati incluso HTTPService, WebService, e RemoteObject ed inoltre sono stati aggiunti nuovi wizard in Flex Builder 3 per facilitare l’accesso ai dati.
Il Flex Data Services è stato rinominato in LiveCycle Data Service (LCDS) e sono state aggiunte nuove funzionalità come il supporto Ajax, la generazione di PDF, un adattatore SQL potenziato, migliorie sulla performance e la sicurezza, etc…
Oltre al LCDS che permette alle applicazioni RIA di comunicare con la business logic dei sistemi di back-end, esiste un altro progetto gratuito e open source, BlazeDS, che mette i servizi Flex Remoting e Flex Messaging a disposizione di tutti gli sviluppatori e di cui parleremo nel prossimo paragrafo. LCDS e BlazeDS sono molto simili nella forma e nella struttura e condividono parte del codice di base. BlazeDS può essere visto come una versione ridotta di LCDS.
Per quanto riguarda la visualizzazione dei dati, Flex 3 migliora il charting package aggiungendo diverse caratteristiche richieste dalla comunità di sviluppatori (supporta assi multipli, migliore formattazione e miglior supporto all’interazione con l’utente).
È stato introdotto un componente, l’Advanced DataGrid che estende il componente standard per supportare dati gerarchici, maggiori option come l’ordinamento multicolonna, e maggior controllo sulla formattazione.
Applicazioni Adobe AIR
L’Adobe Integrated Runtime (Adobe AIR) permette di sviluppare applicazioni che combinano i benefici delle applicazioni web (connettività, contenuto multimediale, facilità di sviluppo con la potenza delle applicazioni desktop, interattività, accesso alle risorse locali, interattività estesa). Le applicazioni Adobe AIR vengono eseguite come normali applicazioni desktop e non richiedono altri software per funzionare (come per le applicazioni web che richiedono un browser). Flex 3 introduce il supporto ufficiale per Adobe AIR incorporando gli strumenti di sviluppo di Adobe AIR nell’SDK Flex e in Flex Builder. Concetti come il drag and drop, che normalmente sono più funzionali con applicativi desktop che web, sono stati incorporati nel framework Flex così da permetterne l’uso in un’applicazione per Adobe AIR. L’SDK Flex include tutti gli strumenti necessari per compilare, debuggare, e confezionare applicazioni Adobe AIR. Anche Flex Builder è stato potenziato per fornire supporto allo sviluppo di applicazioni Adobe AIR e quindi gli sviluppatori utilizzeranno lo stesso strumento che utilizzano già per sviluppare applicazioni web.
Evoluzione della piattaforma
Uno dei problemi che si sentivano spesso con gli applicativi Flex 2 era la dimensione. Il flash player ora supporta una nuova cache per i componenti Adobe (solamente quelli firmati da Adobe), che è differente dalla cache del browser e che quindi non viene svuotata con la stessa frequenza della cache del browser.
La prima volta che un utente effettua il download di un’applicazione Flex configurata per usare una runtime shared library (RSL), riceve una copia permanente di quella RSL. La volta successiva che l’utente richiede un applicativo che usa la stessa RSL (indipendentemente da dove viene effettuato il download) il player userà la copia dell RSL presente in cache. Configurare un’applicazione Flex ad usare una RSL comporta una riduzione di dimensione notevole.
Flex Builder 3 include due nuovi profiler per migliorare la performance e l’uso della memoria. Il primo permette di tracciare le invocazioni dei metodi permettendo agli sviluppatori di valutare dove ottimizzare le performance, il secondo consente di catturare, durante l’esecuzione dell’applicativo, degli snapshots della memoria e seguire l’evoluzione degli oggetti in memoria.
Flex Builder è stato migliorato per consentire maggiore produttività introducendo il supporto al refactoring. Supporta il rename di tutte le istanze di variabili, classi e metodi a seguito del rename di una di esse.
Le applicazioni Flex sono spesso inserite in pagine HTML, e quindi è stata migliorata l’integrazione con i wrapper HTML. È stata inserita la libreria Flex-Ajax Bridge nell’SDK e Flex Builder ora ha degli wizard per generare JavaScript da chiamare dentro un applicativo Flex. Inoltre uno sviluppatore Flex può esporre proprietà e metodi così da permettere ad uno sviluppatore JavaScript di utilizzarli senza andare a guardare dentro l’applicazione Flex. Infine è stato introdotto una classe BrowserManager per permettere agli sviluppatori di interagire con il browser.
BlazeDS
Abbiamo già ricordato che l’integrazione è l’elemento chiave di ogni Rich Internet Application (RIA), dal momento che i dati normalmente risiedono su applicativi lato server dei quali i RIA costituiscono un interfaccia. Inoltre Java EE è una delle piattaforme più diffuse e complete per creare applicazioni di tipo enterprise e quindi potrebbe nascere l’esigenza di salvaguardare gli investimenti già fatti su applicazioni lato server e voler dotare tali applicativi solamente di interfacce web di nuova generazione.
Questa integrazione la si può ottenere con diversi strumenti tra i quali LifeCycle Data Services e BlazeDS [5]. Il primo è un prodotto commerciale di Adobe che offre una vasta gamma di servizi, mentre il secondo è un’alternativa open source. BlazeDS non è altro che un’applicazione web in tecnologia Java che viene inserita in un application server Java (o in un web server come Tomcat) la cui architettura viene mostrata nella figura 2:
Figura 2 – Modello Architetturale con BlazeDS.
Le principali funzionalità di BlazeDS includono i servizi RPC e di messaging. Nella figura 3 vengono illustrate le caratteristiche principali:
Abbiamo detto a livello generale che BlazeDS facilita l’integrazione di Flex e Java; ma ci chiediamo ora, cosa fa esattamente BlazeDS? Bene, BlazeDS permette:
- l’invocazione di metodi Java remoti da un’applicazione Flex;
- la conversione di oggetti Java ritornati da un server, in risposta a una chiamata di metodo remoto, nei corrispondenti oggetti AS3;
- la conversione di oggetti AS3 inviati da un’applicazione Flex nei corrispondenti oggetti Java per passarli come argomenti dei metodi chiamati;
- lo scambio di messaggi tra applicazioni Flex e server Java;
- la gestione dei canali di comunicazione tra Flex e Java;
- la comunicazione, tramite degli adattatori, con servizi JMS.
BlazeDS in definitiva permette due tipi di interazioni: RPC (Remote Procedure Call) e Messaging Service. Le RPC permettono ai client di effettuare delle chiamate asincrone di servizi remoti che effettuano determinate operazioni sul server e restituiscono i risultati direttamente al client. I componenti RPC lato client, messi a disposizione nell’SDK, forniscono servizi HTTP (componente HTTPService), web service (componenti WebService) e remote object service (componenti RemoteObject). Senza l’ausilio di BlazeDS, usando solamente l’SDK, è possibile effettuare delle chiamate HTTP o di web service, ma non è possibile invocare direttamente metodi di oggetti Java [2]. Una delle caratteristiche più interessanti è data proprio dal fatto che il componente RemoteObject (lato client) permette di accedere a oggetti Java remoti senza la necessità di configurarli come web service.
Il Messaging Service permette alle applicazioni client di comunicare fra di loro in maniera asincrona scambiando messaggi attraverso il server. I client che intendono inviare un messaggio sono chiamati producer e utilizzano il componente Producer, mentre i client che sfruttano un messaggio sono detti comsumer e utilizzano il componente Consumer che prevede la registrazione di una destinazione sul server. Il Messaging Service supporta anche il bridging verso server JMS attraverso un adattore (JMSAdapter).
Destinations, Channels, Endpoints
Uno dei principali vantaggi di BlazeDS è l’uso dell’AMF (Action Message Format) per la trasmissione dei dati tra Flex e Java. AMF è un protocollo binario supportato nativamente dal flash player e quindi il suo uso rende la trasmissione veloce ed efficiente. A rendere più agevole l’uso del protocollo è la definizione di livelli di astrazione superiori che permettono di focalizzare l’attenzione sulla business logic trascurando i dettagli della comunicazione.
Destinations, channels, endpoints sono appunto delle astrazioni di livello superiore e rappresentano concetti chiave del framework Flex. Le entità server side sono mappati a nomi logici (destination) e vengono invocati usando questi nomi. Quando un client interagisce con un servizio server-side tramite una destination, usa un canale di comunicazione (channel) per le comunicazioni da e verso il server. Un channel è l’astrazione di un canale di comunicazione che incapsula formato dei messaggi, protocollo di rete, gestisce l’ordine di consegna dei messaggi. Avremo ad esempio un AMF channel per gestire l’encoding e la comunicazione in AMF (proprietario di Adobe) e un HTTP channel per gestire l’encoding e la comunicazione in HTTP. Dal lato server un channel termina in un endpoint Java-based che ha il compito di effettuare l’unmarshalling dei messaggi e consegnarli al servizio opportuno.
Figura 4 – Channels ed Endpoints.
Quindi un channel è un oggetto lato client che rappresenta la connessione tra il componente Flex e il server BlazeDS, e terminano dal lato server in un oggetto endpoint. La configurazione di un canale e del relativo endpoint avviene tramite file di configurazione.
Installare BlazeDS
In questo paragrafo illustrerò i passi da eseguire per installare BlazeDS su JBoss. Abbiamo già detto che BlazeDS non è che un’applicazione web e quindi l’installazione equivale al deploying di una qualunque applicazione web in formato WAR. Partiamo innanzitutto con il download dell’ultima versione di BlazeDS dall’indirizzo
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS
Qui è possibile scegliere se scaricare solo i binari, la versione con i sorgenti, oppure la versione Turnkey, contenente anche un web server Tomcat all’interno del quale il blazeDS è già deployato assieme a diverse applicazioni di esempio.
Per i nostri scopi effettuiamo il download dei binari, disponibili come unico file ZIP. Dopo averlo scompattato troviamo all’interno il file “blazeds.war” che contiene tutto ciò che ci serve. In aggiunta ci sono pure altri due file (“blazeds-sample.war” e “blazeds-console.war”) contenenti alcuni esempi (utili soprattutto per verificare che il BlazeDS funzioni correttamente), ed una console per monitorare il deployment di BlazeDS.
In JBoss, il deploying di un’applicazione consiste nel copiare il file war nella cartella deploy del server avviato (in genere server -> default -> deploy). Copiamo allora il file “blazeds.war” e il file “blazeds-samples.war” e apriamo il browser per lanciare gli esempi (http://localhost:8080/blazeds-sample) e verificare che il server blazeds funzioni correttamente.
Configurare un servizio
Con BlazeDS c’è più da configurare che da scrivere codice. Per configurare un servizio occorre configurare una servlet, la servlet message broker, che si occupa di gestire tutte le comunicazioni e le invocazioni dei servizi. Scompattiamo il file “blazeds.war”(che è un’applicazione web) e nel file “web.xml” configuriamo questa servlet (in realtà è già configurata), settando il file di configurazione che la servlet deve usare:
MessageBrokerServlet MessageBrokerServlet flex.messaging.MessageBrokerServlet services.configuration.file /WEB-INF/flex/services-config.xml 1
Tutte le configurazioni vengono fatte in questo file, chiamato normalmente “services-config.xml”. Normalmente, poiche’ i servizi offerti sono di 4 tipi (RPC, Proxy Server, Messaging, e Manage Data), Adobe ha pensato di suddividere il file di configurazione in 4 pezzi differenti, uno per funzionalità fornita. Ognuno di questi pezzi viene poi incluso per riferimento nel file di configurazione “services-config.xml”. Il nome di questi file ricorda la funzionalità a cui sono adibiti:
- remoting-config.xml
- proxy-config.xml
- messaging-config.xml
- data-management-config.xml (BlazeDS non fornisce questo tipo di servizi, LCDS sì)
Nel file “services-config.xml” vengono inclusi i primi 3 file
...
Tutti gli aspetti comuni (logging, security, channel) vengono invece configurati nel file services-“config.xml”.
Nel caso in cui si voglia estendere un’applicazione Java EE già esistente, bisogna modificare il file “web.xml” di tale applicazione, aggiungere i file di configurazione sopra citati e lineare le librerie presenti nella cartella lib del blazeds.war.
Conclusioni
In questo primo articolo abbiamo fatto una breve panoramica su Flex 3 e su BlazeDS, un componente lato server che semplifica la comunicazione tra applicativi Flex e Java. Nei prossimi articoli vedremo esempi pratici su come installare e configurare il BlazeDS e come scrivere una semplice applicazione RIA in Flex in grado di sfruttare dati frutto di elaborazioni lato server.
Riferimenti
[1] Marco Casario, “Flex 2 e Java per sviluppare Rich Internet Application”, MokaByte 117, aprile 2007
https://www.mokabyte.it/cms/section.run?name=mb117
[2] Marco Casario, “Flex 2 e Java per sviluppare Rich Internet Application”, MokaByte 119, giugno 2007
https://www.mokabyte.it/cms/section.run?name=mb119
[3] Flex 3 SDK release Notes
http://www.adobe.com/support/documentation/en/flex/3/releasenotes_flex3_sdk.html
[4] Flex Builder release Notes
http://www.adobe.com/support/documentation/en/flex/3/releasenotes_flex3_fb.html
[5] BlazeDS development guide
http://livedocs.adobe.com/blazeds/1/blazeds_devguide/