Google Web Toolkit vs Echo 2: confronti

Per un progetto a cui sto lavorando mi sono ritrovato ad usare Google Web Toolkit, che per chi non lo sapesse consente di realizzare applicazioni web 2.0 (Ajax, in concreto html e javascript) partendo dal codice Java come è stato fatto per Google Maps o Gmail.

Google Web Toolkit si propone quindi come framework per applicazioni web accodandosi a Ruby on Rails, CakePHP, Zend Framework (in un prossimo articolo cerchero’ di parlare di Openlaszlo, che dovro’ studiare con molto piacere).

Indagando ho scoperto come parte di esso sia libero, essendo precisi solo le API sono rilasciate con licenza Apache 2.0 ma non il compilatore Java-to-Javascript. Ho quindi cercato qualcosa di simile ma effettivamente libero e ho trovato Echo2 (rilasciato con la Mozilla Public Licence), che ha delle differenze di base che vale la pena sottolineare, percio’ vi traduco un articolo che ho preso da qui (l’articolo è stato scritto dal capo sviluppatore di Echo2, potete pensare che è di parte ma non lo è):

“Google Web Toolkit (GWT) è stato confrontato a Echo2 da sempre. Qualcuno di questi confronti è stato equamente accurato, mentre altri contengono con informazioni non molto esatte. Questo articolo, scritto dal capo sviluppatore di Echo2, discute le somiglianze e le differenze tra questi 2 frameworks.

Panorama

Il confronto tra GWT e Echo2 è interessante. Entrambi questi framework hanno un non-tradizionale approccio verso lo sviluppo di applicazioni web, anche considerando l’ultimo genere di “framework basati su AJAX” disponibile ad oggi.

La più ovvia similitudine tra GWT e Echo2 è che entrambi permettono allo sviluppatore di creare interfacce web utente dinamiche AJAX usando solo Java. In entrambi i progetti, le UI (interfacce utente) sono sviluppate in modo simile a SWT o Swing: assemblando gerarchie di componenti e registrando gestori di eventi. Nessun progetto richiede allo sviluppatore di lavorare con HTML, Javascript o XML.

La più ovvia differenza tra GWT e Echo2 è che tutto il tuo codice GWT è eseguito sul client mentre il codice Echo2 è eseguito sul server. Ci sono vantaggi e svantaggi in entrambi gli approcci che saranno evidenziati attraverso l’articolo.

Il nucleo di GWT è il compilatore Java-to-Javascript. Questo compilatore ti permette di sviluppare l’interfaccia web alla tua applicazione in Java e quindi compilarlo in JavaScript. GWT limita lo sviluppatore ad un sottoinsieme delle librerie Java 1.4. Le applicazioni GWT possono essere servite da qualunque web server, come Apache, senza il bisogno di una elaborazione dal lato server.

Le applicazioni Echo2 sono compilate in byte code Java e vengono eseguite su un server Java. Il loro codice Java è eseguito dalllo strato “Web Application Container” di Echo2, che siede sopra una Servlet Java. Dal lato browser, il “Client Engine” di Echo comunica cio’ che è stato inviato dall’utente al Web Application Container tramite richieste AJAX, con il server che risponde con direttive in modo da apportare aggiornamenti incrementali allo stato del browser client.

Prestazioni dell’interfaccia utente

Con GWT, tutto il codice relativo alle interfacce utente esiste sul browser client. In operazioni che non richiedono la comunicazione con il server, — ovvero, che non richiedono il recupero dallo strato di mezzo (middle tier) — questa configurazione da luogo a tempi di risposta che non sono dipendenti dal server. Quando i dati devono essere recuperati dallo strato di mezzo o dallo strato business logic, il tempo di risposta è soggetto alle stesse condizioni come ogni altra applicazione Java, ad esempio, latenza di rete, banda e prestazioni del server.

Il codice di una applicazione Echo2 viene eseguito dal server, cosi per ogni interazione utente che richiede una chiamata allo strato di mezzo o una immediata esecuzione del codice Java dell’applicazione, una connessione AJAX è fatta al server. Le componenti Echo2 sono progettate per minimizzare una comunicazione client/server il più possibile, limitandola nei tempi in cui il server deve essere notificato immediatamente di eventi. Per esempio, semplici eventi cone un input dell’utente in un componente TextField non darà luogo ad un contatto al server. La risposta del server è il minimo insieme di istruzioni all’aggiornamento incrementale del client in modo da riflettere uno nuovo stato dello schermo.

Le applicazioni GWT sono servite al client come un singolo file HTML/Javascript, contenendo la totalità dell’interfaccia utente. La dimensione di questo file srà proporzionale alla dimensione del codice della tua interfaccia utente e delle librerie del toolkit usate dalla tua applicazione.

I moduli Javascript di Echo2 sono caricati pigramente(lazy-loaded) al client e da li’ in poi messi in cache. Un modulo sarà recuperato quando un componente che appare sullo schermo lo richiede. Il codice dell’applicazione non è mai mandato al client, solo lo stato dell’interfaccia utente.

Strato di mezzo / Recupero dati

Per accedere ai busines data o effettuare un business process, una interfaccia utente GWT da una chiamata di procedura remota (RPC) dal browser alla Servlet. GWT fornisce un meccanisco per fare una invocazione RPC trasparente allo sviluppatore, permettendogli di costruire l’applicazione con “Plain Old Java Objects” (POJOs). Comunque, qualunque applicazione che fornisce una capacità RPC è una applicazione distribuita — anche quando l’RPC avviene trasparentemente allo sviluppatore. Applicazioni distribuite in ditte o aziende di solito prendono in considerazione la sicurezza e gli oggetti remoti che servono i client GWT devono essere progettati focalizzandosi sulla sicurezza in modo da deviare attacchi da applicazioni client imitate o ostili

Le applicazioni Echo2 supportano, ma non richiedono, l’uso di una logica di applicazione distribuita o un SOA (Service Oriented Architecture). Alternativamente, le applicazioni Echo2 possono essere costruite per girare interamente su una singola istanza della JVM, appoggiata da uno strato di mezzo di tipo POJO. Questo permette agli sviluppatori di Echo2 di costruire applicazioni senza preoccuparsi della sicurezza della logica di applicazione distribuita — facendo leva sul fatto che molti robusti framework vengono costruiti attorno allo sviluppo POJO come Spring Framework e Hibernate. Echo2 riesce in questo tenendo lo stato dell’interfaccia web dell’utente sul server cosi nessuno oggetto remoto ha bisono di essere esposto.

Prestazioni sotto carico

Il GWT è una tecnologia UI thick-client (l’applicazione gira sul client) mentre Echo2 è una tecnologia UI thin-client (le applicazioni girano sul server). Un thick-client avrà dunque meno carico sul server anche se il numero degli utenti aumenta. Questo vantaggio di GWT è molto pronunciato nei casi dove applicazioni sono semplici e l’accesso ai dati memorizzati è limitato, e meno con più applicazioni complesse che richiedo più frequenti richieste alla memorizzazione dei dati. In un tipico ambiente, dove ciascun framework satura la banda di rete prima dell’uso della risorsa dal server, ad esempio potenza di elaborazione e memoria, cio’ diventa un problema.

Ambiente Run-time

GWT ha qualche limitazione dovuta al fatto che le applicazioni devono essere eseguite sul browser client. Per primo, le applicazioni GWT sono limitate ad usare un sottoinsieme delle librerie Java, che consistono di 27 classi, 11 interfacce e 18 tipi di eccezioni che si trovano inei package java.util e java.lang (in GWT 1.0.21). Questa limitazione previene le applicazioni GWT dal linkare molte librerie Java esistenti. Inoltre, tutto il codice Java deve essere compatibile con le specifiche Java 1.4; 1.5 non è supportato. Porzioni di codice delle API Java relativo alla localizzazione non è fornito

Debugging

GWT fornisce un alternativo ambiente di deploy per le applicazioni al fine di facilitare il debugging. L’ambiente, chiamato “Hosted Mode”, permette ad una applicazione GWT di essere eseguito come byte code Java in una JVM locale, al quale un debugger di un IDE puo essere connesso. In questo modo, l’interfaccia utente dell’applicazione è mostrata in uno speciame browser web (derivato da Mozilla/Firefox).

Le applicazioni Echo2 possono essere debuggate nel modo convenzionale, connettendo un debugger di un IDE alla JVM corrente che esegue la Servlet container.

Licenze

La primaria componente di GWT, il compilatore Java-to-Javascript, è proprietario, software distribuito solo in binario. Le librerie API Java sono libere, distribuite sotto licenza Apache. Le librerie API non hanno significato senza il compilatore proprietario. Il (non critico) browser hosted-mode è anche esso sotto licenza proprietaria. GWT è fornito senza alcuna spesa.

Echo2 è software libero, distribuito con licenza Mozilla Public License e fornito senza alcuna spesa.

Applicabilità

GWT puo’ essere usato come un mezzo per la creazione di componenti AJAX da incorporare nelle tradizionali applicazioni web (o anche in pagine web statiche) come anche per la creazione di complete applicazioni per interfacce utente. Ci sono alcuni problemi per la creazioni di grandi applicazioni, dove il download di un’intera applicazione verso un browser web in un colpo potrebbe essere non pratico. La perdita di localizzazione e la mancanza del pieno supporto alle API Java presenta un problema per grandi soluzioni.
Echo2 è pratico per la creazione di applicazioni web di ogni dimensione. E’ comunque non inteso all’uso di semplici funzioni per una piattaforma il cui scopo è la creazione di componenti AJAX in framework web (o siti web statici) tradizionali.”

Se siete arrivati fin qui nella lettura e siete incuriositi, ho trovato 2 link dove cominciare a scrivere il vostro Hello World con GWT e Echo2:

Hello World con GWT

Hello World con Echo2

Spero che con la traduzione e con i 2 esempi di avervi illuminato un po’

7 thoughts on “Google Web Toolkit vs Echo 2: confronti

  1. Ciao,

    mi sono limitato solo a tradurre, cmq sia alla fine ho usato Openlaszlo che ho poi descritto in uno degli articoli fatti e credo valga la pena provare.

  2. CIao mi servirebbe sapere!!! Una domanda secondo me banale ma a cui non riesco a trovare una risposta certa.
    Ho un problema nel far ritornare un oggetto piuttosto complesso ad un web service, la classe dell’oggetto è serializabile; uso le librerie di AXIS.

    Non è che dovro’ usare quelle di Axis2 se è così mi potresti indirizzare…

    Grazie

  3. Grazie tante per il tuo post. Sto facendo la tesi su un remoting di un’applicazione java desktop, sto studiando vari web framework e quest’analisi mi è stata molto utile. Credo che sceglierò Echo (la versione 3 permette anche di realizzare codice esclusivamente thick-client) anche se, essendo alle prime armi, configurare eclipse, tomcat ed echo è veramente problematico. (giustamente quelli di nextapp invogliano ad usare echostudio, semplice ma costoso per uno studente…)

  4. Ciao,

    mi sono imbattuto nel tuo post solo ora..! Anche se oramai un po’ datato è ben fatto..

    Noi (parlo della mia azienda) stiamo passando da Echo2 a GWT per tutta una serie di ragioni su cui adesso non mi dilungherò; posso dire solo che le cose ovviamente nel frattempo lato Echo e GWT sono cambiate parecchio… d’altra parte 3 anni nell’informatica sono un’abisso…

    Mi soffermo invece su un piccolissimo progetto che ho pubblicato da poco (è un abbozzo… ci ho dedicato pochissime ore, ma funzionicchia!) che agevola un po’ il compito di popolare i POJO in andata (dal server al client) e di restituire il “modello originale” al ritorno (dal client al server)… Questo argomento è forse quello che più mi ha lasciato perplesso nel passaggio da Echo a GWT, visto che abbiamo fior fiori di modelli e l’idea di replicare buone fette con dei POJO con il relativo sviluppo di adapter non mi ha fatto certo brillare di gioia, come potrete ben comprendere!

    Ad ogni modo, se a qualcuno dovesse interessare, il progettino è pubblicato con licenza Apache2 ed è ospitato presso Google Code a questo indirizzo:

    http://code.google.com/p/pojo-injector/

    Ciao e buon lavoro!

Leave a reply to kaosktrl Cancel reply