Un framework che guardi al futuro

Intervista a Tom Yeh, creatore di ZK

Abstract: Tom Yeh è la persona più adatta a darci una visione di insieme e uno sguardo in prospettiva sul framework ZK. Ma il discorso non si ferma qui: in questa intervista si affrontano temi quali il futuro delle web application, le RIA e i paradigmi che sono alla base delle future evoluzioni delle tecnologie Web 2.0.

tags: ZK Server+Client Fusion framework RIA Rich Internet Application GWT Potix
Numero visite: 5405

di
  • Michele Mazzei
  • Giovanni Puliti

Il nostro "aperitivo" è questa volta una chiacchierata a distanza con Tom Yeh fondatore, insieme a Henri Chen, di Potix, l’azienda che sta dietro al framework ZK [1]. Da una discussione sull’argomento tra Michele Mazzei e Giovanni Puliti, sono nate una serie di domande da porre proprio ai protagonisti dello sviluppo di ZK. Tom Yeh, infatti, non è un generico manager, ma ha effettivamente creato ZK ed è quindi la persona più adatta a darci una visione di insieme e uno sguardo in prospettiva su questa interessante tecnologia, di cui ci siamo occupati su MokaByte [7], [8].
ZK è un web framework Ajax-oriented che consente di sviluppare un sito Web 2.0 con velocità, senza dover conoscere Ajax [6]. Ma la velocità e il "basso costo di utilizzo" non devono far pensare che ZK sia una tecnologia poco potente; si tratta invece di un solido framework per costruire applicazioni web complesse che permettano di affrontare i bisogni di oggi e di domani [2], [3]: gli sviluppatori possono ora scegliere liberamente se far eseguire il proprio codice sul lato server o client [4], dal momento che ZK consente di scrivere uno script in qualsiasi linguaggio: Groovy, Java, JavaScript, PHP, Python [2].
Inoltre ZK non supporta solamente Ajax nei moderni browser, ma anche Java Mobile, Android, BD-J [5], e pure Flash e JavaFX. C’è di che discutere...

 


MokaByte: Dunque, Tom... abbiamo trattato ZK sulle pagine della nostra rivista. Ma se tu dovessi usare solo poche parole per descriverlo, che cosa diresti?

Tom Yeh: Incentrato sullo sviluppatore (developer-centric).
Non può esserci un approccio unico buono per tutte le esigenze delle aziende moderne, esigenze che crescono e cambiano molto velocemente. Un vero framework Ajax non deve solo preoccuparsi di risolvere i problemi strettamente collegati ad Ajax, ma anche di rappresentare le fondamenta su cui le aziende moderne possano costruire le proprie applicazioni enterprise sia oggi che nel futuro. Questo è il concetto fondamentale di ZK: noi forniamo soluzioni intuitive e coerenti che gli sviluppatori possano applicare in maniera intercambiabile e in maniera fluida per venire incontro proprio al rapido cambiamento delle necessità. Siamo sempre in ascolto e facciamo innovazione per assicurare che ZK sia sempre un passo avanti, e possa essere veramente una base solida su cui gli sviluppatori possano costruire.

 


MB: In questo senso, qual è la tua visione rispetto alle tecnologie Web 2.0? Perche’ avete progettato e realizzato un nuovo framework web Java, nonostante ce ne siano già così tanti? Ci potresti indicare alcune caratteristiche possedute da ZK che gli altri prodotti non hanno (o che perlomeno hanno solo in misura minore)?

TY: Per come la vedo io, il Web 2.0 sostanzialmente è comunicazione. Internet è diventato un gigantesco centro di interscambio di informazioni, che mette in connessione la tua famiglia, i tuoi amici, i tuoi colleghi di lavoro, e tante persone che hanno interessi comuni. Ajax, le "nuvole" di computer e i dispositivi tipo smart phone sono le tecnologie che mettono le persone in grado di comunicare in modo più efficiente e più efficace.
Come del resto tanta altra gente, lavoravamo su progetti che si basavano su "tecnologie Ajax" ben prima che Jesse James Garret coniasse il termine "Ajax". Alla fine, ci siamo resi conto che nessun framework Ajax, compreso quello che avevamo realizzato in proprio appositamente per noi, riusciva a rispondere alle necessità richieste per costruire applicazioni enterprise complesse. Cosa ancor più importante, Ajax rappresentava una tecnologia rivoluzionaria, capace di ridefinire il modo in cui costruivamo una web application, e non si trattava solo dell’aggiunta di qualche widget molto carina al solito modello di programmazione web basato sulla pagina.
Ecco perche’ abbiamo cominciato il progetto ZK nel 2005. Da allora, ZK ha dimostrato che Ajax non è solamente una tecnologia che consente di avere interfacce attraenti e interattive anche nelle applicazioni enterprise, ma che è anche un nuovo paradigma di programmazione che minimizza i costi di sviluppo legati alla progettazione dell’interfaccia utente, all’accesso al database, alle attività di verifica, e alla messa a punto delle prestazioni.
A differenza di altri framework Ajax, ZK intende fornire una base solida per costruire applicazioni enterprise, però non solo risolvendo i problemi che fronteggiamo oggi, ma anche anticipando le necessità del futuro. Per questo abbiamo tante innovazioni che si concentrano sull’architettura, sul modello di programmazione e sulle widget, semplici ma potenti. Per esempio, Server+Client Fusion consente agli sviluppatori di far funzionare il loro codice o sul lato server oppure sul client, sulla base di quelli che sono i requisiti e le preferenze della situazione. Un altro esempio è il linguaggio di scripting "pluggable" che cosente agli sviluppatori di lavorare con i loro linguaggi di scripting preferiti, come Groovy, Ruby e, sì, Java. Per estendere la portata della propria applicazione, ZK supporta Ajax non solo nei browser, ma anche su Java Mobile, su Android e su BD-J. ZK è l’unico framework che consente agli sviluppatori di annotare oggetti di interfaccia utente affinche’ accedano al database, senza bisogno di progammare quel codice. ZK è l’unico framework che fornisce un componente di foglio elettronico (Spreadsheet) in grado di realizzare report e analisi compatibili con Excel senza il bisogno di Excel o senza dover scrivere codice VBA. ZK è l’unico framework che unifica l’event model e il server push con la event queue per semplificare il codice dell’applicazione. E la lista di caratteristiche e di valide funzioni uniche è molto lunga e sta ancora crescendo... forse è meglio se i lettori se la guardano da soli con calma, prima che li facciamo addormentare con la lista della spesa :-)

 


MB: Parliamo di altri framework "leggeri". Quali sono le relazioni e le differenze tra ZK e le tecnologie usate per scrivere siti basati su AJAX/HTML? Come considerate l’evoluzione di tecnologie concorrenti, tipo GWT o IceFaces/JSF?

TY: Lo scopo finale o, se volete, la "filosofia" che sta alla base di un framework ci spiega le differenze operative. GWT è una tecnologia per consentire ai programmatori Java di controllare le widget sul browser senza conoscere JavaScript. Ajax JSF punta a consentire l’interazione di Ajax con il framework web basato sulle pagine. jQuery è una libreria concisa che permette l’accesso di elementi DOM in JavaScript.
Al contrario, ZK punta a fornire una architettura rivoluzionaria che massimizzi la soddisfazione dell’utente e minimizzi i costi di sviluppo, concentrandosi sulle sfide che gli sviluppatori fronteggiano in ogni fase del ciclo di sviluppo del software; e oltre a questo, ZK è dotato della versatilità necessaria per integrarsi in un ambiente IT enterprise. Per questo supportiamo Ajax, le piattaforme mobili, ZUL, Java puro, gli scripting basati su Java, JavaEE, CDI, Spring, JSP e appunto JSF.
E il supporto per GWT arriverà ben presto.

 


MB: Prendiamo allora in considerazione le tecnologie "pesanti" usate per il Web 2.0: JavaFX e Flash. Che tipo di integrazione con Flash e JavaFX viene offerta da ZK? Quando è meglio usare applet Flash invece di widget ZK?

TY: I livelli di integrazione possibili sono due. Il primo consiste nell’inglobare Flash e JavaFX come componenti ZK per consentire agli sviluppatori di controllarli in Java a livello server (e, ovviamente, in JavaScript sul lato client).
L’altro livello sta nel considerare Flash e JavaFX come piattaforme, ossia come un browser, analogamente a quanto abbiamo fatto per Java Mobile. Con questo secondo approccio, ZK genera il codice cliente in un formato compatibile che poi viene valutato dai motori Flash o JavaFX. A parte la differenza di aspetto delle widget, il codice risulta trasparente agli sviluppatori, a meno che essi non desiderino affinarlo con un ulteriore controllo a livello client. Abbiamo condotto alcuni esperimenti con questo secondo approccio all’integrazione e i primi risultati sembrano promettenti. Son proprio curioso di vedere quanto potrà risultare efficace descrivere un’interfaccia utente in JavaFX.
La scelta tra Flash/JavaFX e widget ZK Ajax dipende dai requisiti. Se il dispositivo per cui si programma dispone di un browser moderno, Ajax è una buona scelta. Se l’applicazione deve passare parecchio multimedia al client (tipo video in streaming o giochi in 3D), sarebbe meglio Flash/JavaFX. Se, infine, il dispositivo per cui il programma è inteso non dispone di un browser moderno ma supporta Java Mobile (come i telefoni Java o i lettori BluRay), allora la scelta buona è ZK Mobile.

 


MB: Per la descrizione delle widget continuerete a usare XUL o lo sostituirete con un altro linguaggio (magari un linguaggio non basato su XML)?

TY: XUL è stata una scelta, ma è solo una delle scelte possibili. Le interfacce utente si possono programmare anche al 100% in Java. Molti dei nostri clienti usano XUL per gestire il layout delle UI e Java per generare i dettagli basati sui dati, per esempio, caricati dal database. Quando, in futuro, ci sarà anche il supporto per JavaFX, si potranno programmare le interfacce utente in JavaFX :-)
In termini di descrizione UI, XML è più facile da capire, ed è questa la ragione per cui nella maggior parte della nostra documentazione si usa XUL per illustrare gli esempi. Ed è anche la ragione per cui molte persone, specialmente i nostri concorrenti, pensano che ZK abbia il supporto solamente per la descrizione XML. Ma non è così...

 


MB: Veniamo ai "temi". Come è messa la nuova versione 5.0 per quanto riguarda i Themes? Ci sono dei temi già pronti all’uso? C’è uno strumento Java per generare automaticamente themes personalizzati?

TY: Sì, continueremo ad aggiungere nuovi temi. Ma proprio in questo periodo ci stiamo concentrando maggiormento sui tool. Jose L. Casas Serradilla ha scritto il codice di uno stupendo tool per la gestione dei temi, che si chiama ZKThemer, e che può generare un tema nuovo sulla base del proprio colore preferito. Stiamo inoltre lavorando su tool che consenta agli sviluppatori di caricare la snapshot di un elemento (per esempio un pulsante) e generi poi automaticamente il tema...

 


MB: Arriviamo allora al discorso delle prestazioni e dell’impiego di memoria. Come si colloca ZK in relazione ad altri framework Web 2.0? Quanta memoria usa, sia su lato server che su lato client, specialmente se messo a confronto con i framework basati su JSF?

TY: Su tale tema, Robbie Cheng ha scritto un articolo che mette a confronto le prestazioni e l’uso di memoria in ZK, RichFaces e IceFaces [9]. Ci sono state anche delle discussioni a tale riguardo, e proprio per evitare ulteriori inutili polemiche, invito i lettori interessati ad andarsi a leggere l’articolo e a farsi un’idea propria.
In ogni caso, vale la pena ricordare che il discorso sulle prestazioni e sull’uso della memoria dipende molto dall’approccio che si sceglie. Se si fa girare il codice dell’applicazione a livello server (server-centric), l’utilizzo di memoria è sicuramente maggiore. Se si fa girare il codice nel client (client-centric) il tempo necessario per caricare il codice JavaScript aumenta in proporzione alla complessità dell’applicazione stessa, e quindi diventa facile "ingolfare" il browser quando si devono creare molte widget.
JSF e Struts sono l’esempio tipico di soluzioni incentrate sul server, mentre GWT e jQuery sono incentrate sul client. Invece, il peculiare sistema Server+Client Fusion, che solo ZK possiede, consente allo sviluppatore di progettare pagine in base ai requisiti della particolare situazione. Per esempio, si può implementare la pagina di benvenuto con codice tutto sul client, visto che è semplice ed è visitata più frequentemente, e invece le pagine che necessitano di autorizzazione possono essere implementate con codice che gira tutto nel server, visto che tanto necessitano di accedere moltissimo al backend...

 


MB: Bene, e allora continuiamo a parlare di prestazioni, ma da un punto di vista "umano", cioè dello sviluppatore. Se si sceglie di usare ZK invece di altre tecnologie (JSF, Flash, Swing), si riesce a creare siti dalla scrittura e manutenzione più facili? E la curva di apprendimento di ZK è più difficile di quella dei tool appena citati?

TY: Se non è il più semplice, ZK è comunque uno dei framework più facili da imparare, nonostante sia pieno di funzionalità. Esagerando un po’, in fondo se si sa scrivere una pagina HTML, si è sostanzialmente già in grado di scrivere una UI Ajax con ZUL; se si sa come scrivere una applicazione Swing/SWT, si è sostanzialmente già in grado di scrivere una UI Ajax con Java...
La costruzione delle widget è un altro esempio della flessibilità di ZK. A differenza dei framework che sono pieni di API sofisticate, ZK consente agli sviluppatori di collocare quasi ogni widget dentro quasi ogni altra widget, un po’ come se si usasse il Lego. Per esempio, mettendo una griglia master-detail dentro un’altra grid, si può creare una sofisticata vista ad albero. Il supporto per "stampi" (molds) multipli è un altro esempio del modo in cui cerchiamo di rendere semplici le cose per gli sviluppatori. Senza dover imparare un nuovo set di API, si può cambiare l’aspetto di una widget modificando il suo mold; per esempio scegliendo il mold "accordion" si ottiene il noto effetto "a fisarmonica" in un elenco a elementi verticali che possono essere espansi o allungati per rivelarne il contenuto.
Inoltre ZK Studio, con tutte le sue funzionalità, semplifica la curva di apprendimento di ZK. Per esempio, con la funzionalità di assistenza legata al contenuto e i popup JavaDoc, non c’è più la necessità di memorizzare tutte le complessità delle varie API, indipendentemente dal fatto che si stia lavorando con ZUL o Java. La palette ZUL consente di fare il drag and drop di componenti ZK sulla propria pagina ZUL, per costruire la propria interfaccia utente. Inoltre, l’editor visuale mostra i risultati WYSIWYG in maniera immediata, proprio mentre si sta disegnando l’interfaccia.

 


MB: Hai fatto accenno al tool ZK Studio. Come si evolverà? Pensate di farne un porting verso NetBeans?


TY: Al momento stiamo lavorando in particolare su una nuova generazione dell’UI Designer, sul componente Zeta (per l’automazione dell’accesso al DB) e sul Theme Designer. Per quanto riguarda NetBeans, Sotohiro Terashima ha sviluppato un ottimo plugin che si chiama REM. Funziona bene, e quindi non abbiamo intenzione di fare un porting di ZK Studio verso NetBeans. Piuttosto, la nuova generazione dell’UI Designer, di Zeta e del Theme Designer sarà web-based e quindi questi tool verranno resi più semplici per integrarsi dentro ambienti di sviluppo diversi.

 


MB: Passiamo a parlare di piattaforma mobile: Android, iPhone e in generale i telefonini che supportano Java. Al momento, come si pone ZK nei confronti delle tecnologie web per i dispositivi mobili?

TY: ZK Mobile non punta a sostituirsi agli strumenti di sviluppo per questi dispositivi mobili. Se la propria attività professionale si concentra, per esempio, specificamente sullo sviluppo di applicazioni per iPhone, di sicuro è molto meglio lavorare con il SDK per iPhone. Tuttavia, ZK Mobile punta a estendere il "campo d’azione" delle nostre applicazioni RIA. Serve per rendere più facile (e più trasparente possibile) agli sviluppatori la realizzazione di applicazioni che possano funzionare su dispositivi che potrebbero anche non supportare browser compatibili con Ajax.

 


MB: Spesso c’è la necessità di fornire web service allo stesso tempo sia per una workstation che per un dispositivo mobile. In che misura ZK riesce a rispondere a questo doppio requisito?

TY: Per un’applicazione, non è facile, anzi è quasi impossibile, supportare una workstation e un dispositivo mobile senza che il suo codice debba subire delle modifiche, non fosse altro perche’ cambiano le dimensioni dello schermo.
ZK non fornisce una soluzione trasparente, ma consente agli sviluppatori di usare lo stesso insieme di tecnologie e codice base. La sola differenza diventa il set di widget che viene usato dall’una o dall’altra versione dell’applicazione. Con un giusto approccio MVC, tutto quel che lo sviluppatore deve fare per superare questo problema si riduce nel preparare pagine con widget specificamente tarate in vista dei dispositivi su cui gireranno. A parte questo aspetto, lo sviluppo di interfacce mobili, quindi, fa affidamento sulla stessa tecnologia, sugli stessi servizi di backend e sulla stessa base di codice, senza alcuna modifica.

 


MB: Ci avviciniamo al termine di questa nostra chiacchierata. Dicci qualcosa in più sulla diffusione di ZK nel mondo Web 2.0. Che tipo di pervasività ha in termini di numero e tipologia di utenti? Quali strategie intendete adottare per promuoverne la diffusione?

TY: Il numero globale di download di ZK e dei suoi prodotti correlati ha superato il milione e mezzo. La tipologia di utenti è molto variegata: il Web 2.0 raccoglie le esigenze di quasi ogni industria. Tuttavia, se andiamo ad analizzare gli utenti che hanno con noi rapporti diretti e contatti più approfonditi, ci rendiamo conto che la maggior parte è rappresentata da società che si occupano di finanza, da aziende di consulenza IT, da produttori di software, e dal settore della sanità e dell’amministrazione pubblica.
Riteniamo che un buon prodotto sia la migliore pubblicità: il passaparola, la licenza open source e il contributo entusiasta di tanti competenti appassionati sono la forza motrice del progetto. La nostra strategia per la promozione è semplice: non preoccuparsi tanto della promozione, ma concentrarsi sulla realizzazione del miglior prodotto possibile, sviluppando uno stretto rapporto con la nostra community.

 


MB: L’ultima domanda è quella più generale, e riguarda l’evoluzione delle applicazioni web, specialmente per il mondo Java EE. Che scenario prevedi per i prossimi cinque anni, riguardo allo sviluppo delle Web Application?

TY: Eh... mi ci vorrebbe la sfera di cristallo :-) In termini di evoluzione di Internet, cinque anni sono un periodo piuttosto lungo. In ogni caso, una cosa è sicura: i dispositivi che accederanno a Internet saranno sempre più diversificati, con differenze di potenza di calcolo tra i vari device che potranno raggiungere l’ordine del migliaio. Alcuni dispositivi magari avranno dei browser adatti a HTML 5, mentre su altre macchine magari girerà ancora Internet Explorer 6. Alcuni dispositivi avranno un touch-screen, mentre altri saranno gestiti da altri sistemi di controllo.
Persino la definizione di "applicazione" o "servizio" sta cambiando. Potrebbe essere un mashup di servizi diffusi in diverse parti del mondo. Potrebbe trattarsi di un piccolo servizio che gira su un dispositivo embedded. Tutti questi aspetti rappresentano grosse sfide, ma anche grosse opportunità, per i fornitori di applicazioni, servizi e framework.
L’introduzione di CDI (Context and Dependency Injection) mi sembra la giusta direzione per Java EE. La separazione di CDI e layout di presentazione è anch’essa una buona mossa. In risposta al veloce cambiamento cui assistiamo, Java EE deve essere più agile e leggero. Visto il nuovo sviluppo di Internet, Java EE dovrebbe rinunciare a mettere delle pezze alle JSF, che comunque sono pesanti e basate sul vecchio paradigma "della pagina", e dovrebbe invece prendere in cosiderazione un sistema più generale che permetta agli sviluppatori di scegliere diversi framework di presentazione a seconda delle necessità contingenti.

 



[1] ZK Home page
http://www.zkoss.org/

[2] Presentazione di ZK
http://www.zkoss.org/Steps/learn.dsp

[3] Supporto a CDI in ZK
http://docs.zkoss.org/wiki/Getting_started_with_ZK_CDI

[4] Server+Client Fusion
http://docs.zkoss.org/wiki/ZK_5.0_and_Client%2BServer_Fusion

[5] Blue Ray Disc Java
http://it.wikipedia.org/wiki/BD-J

[6] ZK user guide
http://www.zkoss.org/zkdemo/userguide/

[7] M. Mazzei, "ZK, un semplice e potente web framework basato su Ajax - I parte: Simplicity matters!", MokaByte 143, Settembre 2009
http://www2.mokabyte.it/cms/article.run?articleId=RSD-89N-1MJ-RN7_7f000001_18359738_bce062e1

[8] M. Mazzei, "ZK, un semplice e potente web framework basato su Ajax - II parte: Il pattern MVC in ZK con Spring", MokaByte 144, Ottobre 2009
http://www2.mokabyte.it/cms/article.run?articleId=24O-7SB-COK-R48_7f000001_18359738_47dff45a

[9] Robbie Cheng, "Performance Report of Server Side RIA Frameworks"
http://ria.dzone.com/articles/performance-report-server-side

 

Michele Mazzei

Michele Mazzei

Michele Mazzei si è laureato in Scienze dell’Informazione nell’ormai lontano 1998. Si occupa di progettazione e scrittura di software in Java/Java EE e in C/C++ sul mondo Linux. Lavora a Roma in ambito spaziale maturando esperienze in ambito OGC, GIS, Map Server, Payload Data Ground Segment (PDGS). Si interessa di tecnologie web basate su Java/Java EE, ma anche di tecnologie C/C++ del mondo Linux.

Giovanni Puliti

Giovanni Puliti

È uno dei fondatori di MokaByte ed è attualmente il suo direttore. Svolge regolare attività di consulente Java EE e di Project Management presso importanti aziende italiane. Laureato in informatica, segue la piattaforma Java fin dalla prima apparizione del JDK 0.9 alfa. Ha maturata esperienza di tecnologie distribuite EJB e applicazioni web, con le quali unisce le conoscenze Java a quelle di usabilità web e grafica digitale.