Nel mondo delle interfacce Web c‘è un grande fermento. Dopo aver compreso i limiti di usabilità e di performance delle interfacce solo HTML si è passati a tecnologie RIA (Rich Internet Applications, dove “rich” indica una interattività grafica maggiore), basate su Java lato client o su Flash. Negli ultimi tempi va di moda AJAX. Vediamo un confronto tra prodotti basati su tecnologie eterogenee, come AJAX, e prodotti basati tecnologie più omogenee e affermate, come quelli 100% Java.

Introduzione

Da tempo volevo scrivere due righe riguardo l‘ultima tendenza del momento, AJAX, e il suo rapporto con il linguaggio al centro degli interessi dei lettori di questa rivista, cioè Java.
Lo stimolo per decidermi improvvisamente a farlo viene da un interessante articolo pubblicato sul numero di MokaByte del mese scorso ([1]) da Marco Ratto, in cui vengono spiegati alcuni concetti basilari della tecnologia.

Da quando Google ha annunciato di averla utilizzata per la realizzazione di alcune sue applicazioni Web (maps, gmail, ecc.), l‘interesse in AJAX è aumentato in modo esponenziale e altrettanto il suo utilizzo.
Nel nostro campo, a essere critici a proposito di una nuova tecnologia, c‘è sempre il rischio si essere smentiti dai numeri, se poi lo si fa a proposito di AJAX, cioè una tecnologia che i numeri li ha già  (in termini quantitativi, di interessati e di sviluppatori che la utilizzano), allora si rischia veramente di essere masochisti.

Per fortuna non ci sono solo i numeri a determinare la qualità  e la bontà  di una tecnologia. Si può spulciare i punti deboli anche di ciò che tutti sembrano ritenere la moda del momento. Del resto nessuno mette in dubbio oggi il passo indietro, in termini di usabilità  e interattività , delle interfacce Web tradizionali, anche se il Web in quanto tale ha rappresentato un‘indiscussa conquista e i suoi numeri sono impressionanti.

Limiti delle interfacce Web

In un articolo pubblicato su questa stessa rivista nel settembre del 2004, in tempi quindi non sospetti, da un punto di vista AJAX, dicevo che le tecnologie di tipo “rich thin client” (RTC) stavano lentamente passando da una prima fase pionieristica, iniziata alcuni anni prima, a una fase di maturazione.
Nel frattempo sono cambiate le sigle (si parla ora di RIA, “rich internet applications”), sono aumentati i prodotti (alcuni sono scomparsi…) e in più si parla di Javascript asincrono, combinato con XML.
Rimangono i limiti di Html, la necessità  di interfacce più ricche e la volontà  di mantenere il deployment su server, per evitare la distribuzione di codice specifico dell‘applicazione (il grosso vantaggio delle applicazioni Web).

Termini del confronto

Vediamo allora di definire i termini del confronto. Intendo confrontare la tecnologia AJAX con soluzioni 100% Java, con client generico (cioè client indipendente dall‘applicazione, che non richiede nuove installazioni, esattamente come un browser per le applicazioni Web tradizionali), come ne esistono sul mercato.
Sempre nell‘articolo del 2004, elencavo una serie di elementi caratteristici che una tecnologia RIA dovrebbe possedere.
Vediamoli e usiamoli come termini di confronto.

Thin client

Si tratta di distinguere tra installazione e contenuto.
Per quanto riguarda l‘installazione, si tratta della caratteristica che meglio si addice a un prodotto basato su AJAX. Partendo dal presupposto che ogni browser supporta JavaScript, sappiamo che un‘applicazione che utilizzi questa tecnologia non ha bisogno di nessuna installazione. Leggermente diverso è il discorso per un‘applicazione che necessiti un client Java (sia via browser, come applet, sia in altre modalità ): è necessario avere almeno il plugin Java installato sulla macchina client. Questo significa che un‘applicazione di questo tipo si presta meglio per Intranet, dove il controllo del software installato sulle macchine è maggiore.
Per quanto riguarda il contenuto, il giudizio andrebbe fatto non sulla tecnologia, ma sui singoli prodotti. Molti prodotti AJAX attualmente disponibili hanno bisogno di caricare informazioni dal business layer per poter gestire la visualizzazione dei dati e le loro dipendenze a livello di GUI. Essendo la tecnologia usata lato client completamente diversa da quella lato server, diventa più semplice, e a volte necessario, gestire le informazioni direttamente sul client. In questi casi non si può certo parlare di “thin client”. Se poi l‘intera gestione della comunicazione client/server è a carico dello sviluppatore, si tratta chiaramente di “fat client”.
La gestione dell‘applicazione sul server, in modo del tutto trasparente, delegando unicamente funzioni di rendering al client, è più semplice con i prodotti 100% Java (sia client che server). Un approccio interessante e di successo viene spiegato in [3].

Portabilità

Chi credeva che la portabilità  di Javascript sui vari browser fosse ormai acquisita, è stato smentito dall‘articolo di Ratto. L‘articolo mostra che per l‘instanziazione dell‘oggetto XMLHttpRequest sono necessarie 3 condizioni, oltre a quella del browser che non supporta questo tipo di richiesta. Cito l‘articolo: “(…) con Mozilla, Firefox e Safari, l‘oggetto XMLHttpRequest è definito nel linguaggio javascript, mentre con Internet Explorer deve essere caricato un opportuno ActiveX (diverso inoltre tra versioni precedenti alla 5.5 o superiore).”

Facilità  di sviluppo

Nell‘articolo del 2004 dicevo che la tecnologia ideale deve permettere allo sviluppatore di realizzare un‘applicazione come se si trattasse di un‘applicazione stand-alone, residente su un‘unica macchina. Questo evita al programmatore di dover definire e gestire la separazione e la comunicazione tra client e server, che vanno invece gestite interamente dal prodotto.

Questo sembra per il momento uno dei punti deboli dei prodotti AJAX in circolazione, pur ammettendo che ci sono un paio di tentativi (Echo2, [6] su tutti) che puntano a questo tipo di trasparenza.
La difficoltà  qui consiste nell‘approccio completamente eterogeneo a cui spinge l‘utilizzo di AJAX. Dall‘articolo di Mokabyte del mese scorso si deduce che ci sono almeno 6 tecnologie coinvolte: Javascript, XML, HTML, CSS, DHTML, con, in più, il linguaggio utilizzato sul server. Alla faccia della semplicità !
Cosa succederà  in fase di debugging? Come coordinare processi di refactoring tra client e server? È forse per questo che Google non fa sapere quanto tempo e quante risorse sono state necessarie per realizzare le sue applicazioni?

I prodotti 100% Java puntano evidentemente all‘omogeneità  di tecnologia, facilitando il processo di sviluppo, quello di refactoring e quello di debugging. Alcuni, come Canoo ULC ([7]), permettono lo sviluppo in standalone, permettendo cicli brevi, senza necessità  di deployment. Quando poi ci si decide per il tipo di deployment, ci sono parecchie varianti, sia lato client che lato server, senza dover intervenire sul codice.

Una stessa applicazione può essere vista sul client come applet all‘interno di un browser (Fig. 1) o come applicazione (Fig. 2).

Entrambe le versioni, installate come servlet lato server, sono in grado di colloquiare e integrarsi con applicazioni Web tradizionali.

Sarebbe troppo facile confrontare ora il codice dell‘esempio mostrato in [1] (verifica del codice fiscale), con il codice necessario in una qualunque versione Java con programmazione lato server completamente trasparente. Con un paio di linee di codice si riuscirebbe a sostituire le decine di linee mostrate per AJAX nell‘articolo in questione.
Alcuni prodotti RIA basati su Java utilizzano lato server classi corrispondenti alle classi della GUI, permettendo, sempre lato server, e in modo del tutto trasparente, operazioni di questo tipo, con impatto sul client:

MyRIATextField textField = new MyRIATextField(...);CodiceFiscale cf = new CodiceFiscale();...cf.verifica(textField.getText());

È vero che un confronto più realistico dovrebbe essere fatto con un prodotto AJAX corrispondente, cioè con un prodotto che realizzi la trasparenza allo stesso livello. La difficoltà  attuale è trovarne uno sufficientemente maturo.

Sicurezza

Lato client, all‘interno di un browser, sia Java che Javascript si basano su un modello di sicurezza simile (sandbox). Per quanto riguarda Javascript in particolare, rimando ad un articolo in devarticles.com ([5]). Ciò non toglie che i pericoli per un linguaggio di script, combinato oltretutto con parecchie tecnologie, siano maggiori.
Il problema maggiore è però quello di riuscire a gestire le informazioni il più possibile sul server. Finchà© i dati del business layer rimangono sul server, anche i problemi di sicurezza sono minori. Se questi devono invece essere gestiti in modo esplicito anche sul client, come nella maggior parte delle soluzioni AJAX attuali, le cose si complicano.

Affidabilità

Più che di affidabilità  preferirei parlare di ciò che in [4] viene chiamato “industrial strength”. Comprende certamente il concetto di affidabilità , ma non solo. Con questo termine si intende coprire caratteristiche come manutenibilità , scalabilità , performance, ecc.
Java è usato per grosse applicazioni, anche critiche, nei più svariati settori. Ha dimostrato essere una tecnologia affidabile in molti campi, bancario, logistico, industriale, ecc.
Chi deve sviluppare un prodotto critico, che sia una vera applicazione, con Java va ormai a colpo sicuro. Con una combinazione di tecnologie eterogenee, con alla base un linguaggio di script la scelta sarebbe più difficile e rischiosa.

Java e l‘approccio omogeneo

Utilizzare Java lato client significa quindi proporre un approccio omogeneo, che meglio si combina con le fasi essenziali di un‘applicazione matura e affidabile, che sono la manutenzione e la sua crescita evolutiva.
Un altro aspetto importante, poco considerato nelle piccole demo, ma determinante per applicazioni reali, consiste nella complementarietà  tra client e server che un approccio omogeneo permette. I meccanismi di lazy loading sono un esempio su tutti della maggiore semplicità  che un approccio 100% Java permette in questo contesto. Prodotti come ULC, consentono di mostrare sul client liste di milioni di elementi in modo istantaneo. Come? Gestendo le enormi liste sul server, inviando al client unicamente la parte visibile.

Oltre a ciò dobbiamo sottolineare che i toolkit di interfacciamento grafico a disposizione di Java (SWT e, soprattutto, Swing, con la sua capacità  di adattare il proprio look & feel) hanno raggiunto col tempo un grado di maturità , di ricchezza e, soprattutto, di estendibilità  al momento ancora difficilmente avvicinabile da soluzioni Javascript.

Conclusioni

Con questo articolo ho voluto mostrare come i prodotti RIA basati interamente su Java (client e server) siano al momento una scelta più sicura per chi intenda sviluppare applicazioni importanti, affidabili, di più facile sviluppo e di più semplice manutenzione. Gli accessori a disposizione oggi per sviluppo, debugging, test e refactoring con Java ci permettono di affermare questo.
Inoltre, applicazioni con client basato su Java possono presentarsi sul client sia attraverso un browser (applet), combinandosi quindi con applicazioni Web tradizionali anche lato client, sia come client desktop, permettendo una migliore integrazione con la piattaforma.

AJAX ha ricevuto un grosso impulso grazie al suo utilizzo da parte di Google, si basa però su tecnologie eterogenee, meno adatte per lo sviluppo di grosse applicazioni, più problematiche in fase di debugging e di manutenzione.
Richiedono inoltre parecchio tempo di sviluppo (di nuovo la domanda: quanto hanno impiegato gli sviluppatori di Google?). La tecnologia di base (Javascript, XML) non è nuova, ma probabilmente bisognerà  attendere prodotti che facilitino lo sviluppo e si basino su approcci server-based e trasparenti per veramente sfruttarne le capacità  senza dover investire risorse in modo esagerato.
In un certo senso, possiamo dire che le implementazioni attuali di AJAX permettono di estendere e migliorare l‘interattività  di applicazioni Web come le conosciamo ora con interfaccia Html, ma non sono consigliate per applicazioni enterprise importanti e altamente critiche.

Da ultimo segnalo un riferimento. In [4] viene proposto un albero decisionale allo scopo di scegliere la migliore tecnologia in vari ambiti di sviluppo RIA, considerando non solo Java e Javascript, ma anche tecnologie basate su Flash. Anche qui, quando si tratta di dare importanza ad aspetti come affidabilità , scalabilità , performance, ecc. non esistono dubbi sui prodotti RIA 100% Java.

Riferimenti bibliografici

[1]
Marco Ratto, “Sviluppare Applicazioni AJAX – Parte I”, MokaByte 107, Maggio 2006

[2]
Sandro Pedrazzini, “Java, la piattaforma ideale per architetture ‘rich thin client‘ “, MokaByte 88, settembre 2004

[3] Alessandro Trivilini, “Utilizzo di architetture ‘rich thin client‘ e benefici del pattern Half-Object”, MokaByte 89, ottobre 2004

[4]
Marc Domenig “Rich Internet Applications and AJAX – Selecting the best product”
http://www.javalobby.org/articles/ajax-ria-overview/

[5]
http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/

[6]
Echo2
http://www.nextapp.com/platform/echo2/echo/

[7]
Canoo ULC
http://www.canoo.com/ulc