Introduzione
Chi
non si è mai trovato di fronte al dilemma di scegliere
se sviluppare un'applicazione con un'interfaccia grafica complessa,
tipo Swing, oppure modificare l'interattività dell'applicazione
per renderla un'applicazione Web a tutti gli effetti, con
interfaccia in Html? Chi non ha mai pensato che creare interfacce
in Html fosse più semplice che utilizzare un toolkit
in Java (ad esempio Swing), rendendosi conto solo a sviluppo
avanzato che più la complessità dell'applicazione
cresce, più il software che ne deriva diventa difficile
da gestire? Chi non si è mai chiesto se ributtarsi
su architetture di tipo "fat" client (cioè
con parte della logica residente sul client e con un ricco
set di elementi di interfaccia grafica) rinunciando anche
ai numerosi vantaggi dell'architettura Web, piuttosto che
dover convivere con i limiti di Html o, peggio, avere a che
fare con la manutenzione di elementi Javascript o altre combinazioni
esotiche? Chi non è stufo di dover inviare e ricevere
ad ogni interazione con l'applicazione diversi KBytes di materiale
(intere pagine Html), anche se la selezione effettuata riguarda
unicamente un elemento da aggiornare nella pagina stessa?
Ebbene, la buona notizia è che tecnologie di tipo "rich
thin client" (RTC) stanno lentamente passando da una
prima fase di early adopters, iniziata ormai da un paio d'anni,
a una fase di maturazione completa.
Tecnologie
RTC
Cosa si intende con tecnologie rich thin client? In due parole
si tratta di combinare gli indiscutibili vantaggi di deployment
e aggiornamento tipici di un'architettura Web-based con GUI
in Html ai vantaggi di utilizzo, di interattività e
omogeneità di sviluppo dati da soluzioni di tipo "fat
client". Il termine "thin" sta a significare
che sul client la logica dell'applicazione è nulla,
mentre l'intera applicazione risiede sul server.
Il termine "rich" serve invece ad informare che
non per questo l'interfaccia grafica dev'essere limitata e
il livello di interattività essere definito a pagine,
come si usa con applicazioni con interfacce utente in Html.
La quadratura del cerchio? Forse, anche se soluzioni simili,
pur se usate in contesti diversi e con altri limiti esistono
da tempo, basti pensare alle X Windows. Il fatto è
che l'onnipresenza di Java rappresenta un'opportunità
formidabile per rendere più snelle e performanti le
librerie RTC.
Il ruolo di Java
Java ricopre un ruolo fondamentale in questo tipo di architettura.
La disponibilità del JRE sia sul client che sul server
è il punto di partenza ideale per la distribuzione
di librerie RTC. Infatti la libreria può essere snella,
perché la maggior parte degli elementi è già
disponibile sul JRE delle singole macchine:
- Funzionalità
grafiche e gestioni di evento sul client vengono delegate
al JRE locale (sia sul desktop che come plug-in in un browser).
- Funzionalità
di gestione, comunicazione e integrazione con elementi esterni
all'applicazione vengono gestite interamente sul server
attraverso la piattaforma J2EE presente sul server stesso.
- Per
la distribuzione di elementi di libreria sul client si può
usare Java Web Start, senza con questo dover distribuire
l'applicazione, che rimane completamente server-side.
Esistono
varie librerie sul mercato, alcune basate al 100% su Java
(come Canoo ULC), altre con un approccio ibrido (come Droplet).
Vedremo più avanti una lista più esaustiva.
Per ora limitiamoci ad analizzare quali sono gli elementi
essenziali per una libreria che permetta lo sviluppo e la
gestione di applicazioni RTC.
Thin client
Dal punto di vista della distribuzione, una libreria RTC deve
essere più snella possibile, tanto piccola da poter
essere distribuita, se necessario, anche come applet. Inoltre
dev'essere indipendente da ogni tipo di applicazione, visto
che quest'ultima deve risiedere completamente sul server.
Rich client
Dal punto di vista dell'utilizzo, gli elementi di interfaccia
grafica devono garantire un livello elevato di caratteristiche
di tipo "rich", non presenti in Html.
Devono mettere a disposizione widget avanzati, quali strutture
ad albero, tabelle con vari tipi di allineamenti e ordinamenti,
editor, ecc.
Devono inoltre garantire un alto grado di interattività,
che minimizzi i round-trip verso il server (cosa che non succede
invece con le X-Windows, che vengono completamente disegnate,
senza che i widgets grafici risiedano sul client).
Non da ultimo l'applicazione deve potersi integrare nel desktop
come se si trattasse di una qualsiasi applicazione rich, con
possibilità di manipolazione diretta degli elementi.
Comunicazione
Abbiamo detto in precedenza che le interfacce grafiche in
Html sono organizzate a pagine. Ad ogni richiesta o modifica
ci sono dati inviati al server e pagine intere in Html che
ritornano al client (anche l'utilizzo di frame non serve più
di tanto a ridurre il traffico).
Se l'interfaccia è invece organizzata in widget, con
il server che tiene traccia dello stato di ogni widget, il
traffico è minimo, perché solo le modifiche
vanno inviate dal server al client, non l'intera pagina. Alcune
tecnologie presentano inoltre sofisticati meccanismi di enabler/disabler
per gestire dipendenze tra widgets ed evitare round-trips,
oppure meccanismi di lazy loading, in modo che il server invii
al client unicamente ciò di cui il client ha effettivamente
bisogno per la sua visualizzazione.
Facilità
di sviluppo
In realtà l'applicazione si trova unicamente sul server.
Solo in runtime è necessario spostare dati dal server
al client e viceversa. Sul client non deve però risiedere
nessun codice specifico dell'applicazione.
La libreria 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. A questo proposito è interessante
da un punto di vista architetturale la soluzione adottata
da Canoo ULC: attraverso il pattern half-object ([1]), mostrato
in fig. 1, ogni widget viene diviso in due parti: una metà
visibile sul client (user interface half object) e una metà
sul server (faceless half oject) che mette a disposizione
la API di utilizzo all'interno dell'applicazione.
Figura 1
In questo modo lo sviluppatore utilizza unicamente la parte
server del widget, che solo in runtime creerà e comunicherà
con la sua metà residente sul client.
Un approccio in cui il programmatore fosse responsabile anche
della comunicazione tra client e server sarebbe da considerare
di tipo "fat", mentre qui non è il caso.
Lavorare in questo modo, senza preoccuparsi degli aspetti
di separazione e comunicazione, permette uno sviluppo omogeneo,
puramente in Java e object-oriented, senza introdurre miscugli
di tecnologie, come Html, CSS, JSP, Javascript, Actionscript,
o altro, che oltre ad essere problematici da gestire, interferiscono
pesantemente sull'architettura finale.
Inoltre, proprio perché sia la parte client che la
parte server hanno bisogno di una VM, lo sviluppo può
essere fatto su un'unica macchina, in cui gli aspetti di comunicazione
vengono simulati. Questo faciliterebbe notevolmente i cicli
di sviluppo e test dell'applicazione.
Aspetti legati alla sicurezza
In uno scenario ideale come quello appena descritto, in cui
l'esecuzione dell'applicazione è completamente lato
server, tranne la parte di presentazione della GUI, anche
la gestione della sicurezza diventa senza dubbio più
semplice.
Data l'architettura object-oriented e l'omogeneità
tecnologica, diventa naturale isolare il protocollo di comunicazione
in un unico oggetto, permettendo così la sua sostituzione
senza intaccare il resto dell'applicazione. In questo modo,
la libreria RTC ideale dovrebbe permettere la scelta del protocollo
di comunicazione: HTTP, HTTPS, RMI/IIOP, o altro.
Il fatto poi di usare le piattaforme J2SE e J2EE permette
una facile integrazione con infrastrutture Web con meccanismi
preconfezionati di comunicazione, gestione di sessioni e sicurezza.
Prodotti sul mercato
Esistono vari prodotti sul mercato. I più noti sono:
AltioLive, AppProjector, Canoo ULC, Classic Blend, Droplets,
Thinlets.
Alcuni di questi sono 100% Java e sfruttano al meglio la piattaforma
Java presente su tutti i sistemi. Altri rappresentano soluzioni
ibride, meno pulite da un punto di vista architetturale. Tutti
questi prodotti stanno però a dimostrare la necessità
e la domanda crescente di librerie RTC.
Conclusioni
Abbiamo visto come per applicazioni complesse ci sia la necessità
di spostamento dall'approccio Web con interfaccia Html ad
un approccio di tipo rich client, in cui l'interfaccia utente
esca dai limiti del paradigma a portale e torni ad integrarsi
nella metafora del desktop.
Senza un'adeguata infrastruttura che permetta di realizzare
soluzioni rich client mantenendo l'applicazione sul server,
questo spostamento coinciderebbe però con un ritorno
ad architetture fat client, in cui parte dell'applicazione
risiederebbe sul client, con i problemi che questo comporta,
sia di sviluppo (definizione e gestione della separazione
client/server), sia di deployment. Chi sviluppa applicazioni
Web tradizionali, e conosce i vantaggi di deployment e manutenzione
legati a questa architettura, difficilmente decide di passare
a modelli di tipo fat client.
La soluzione auspicata sta quindi nel mezzo. Una soluzione
di tipo RTC, in cui vengano combinati e mantenuti i vantaggi
di entrambi gli approcci.
Non si tratta di idee utopiche. Esistono già parecchi
prodotti che permettono questo approccio e la piattaforma
Java è senza dubbio l'elemento essenziale che ha permesso
questo sviluppo e favorito questa tendenza.
I migliori prodotti sono già maturi, hanno superato
la fase di early adopters e vengono adottati per applicazioni
complesse in intranet di grosse aziende. Permettono uno sviluppo
stand-alone, object-oriented e puramente in Java, evitando
miscugli di tecnologie, tanto in voga (e necessarie) nel paradigma
Web con GUI in Html.
Riferimenti
[1] Meszaros G.: Pattern: Half-Object+Protocol Pattern, in
Coplien, Schmidt: "Patterns Languages of Program Design",
Addison-Wesley, Reading 1995.
[2]
- AltioLive: www.altio.com
[3] - AppProjector: www.asperon.com
[4] - Canoo ULC (UltraLightClient): www.canoo.com/ulc
[5] - Classic Blend: www.appliedreasoning.com
[6] - Droplets: www.droplets.com
[7] - Thinlets: www.thinlet.com
|