MokaByte 88 - 7mbre 2004 
Java: la piattaforma ideale per architetture "rich thin client"
di
Sandro
Pedrazzini

Soprattutto nelle intranet delle grosse aziende si stanno facendo strada da alcuni anni le architetture cosiddette “rich thin client” (RTC), ovvero architetture che pur lasciando l’applicazione interamente sul server, come le applicazioni Web tradizionali, offrono interfacce grafiche avanzate. Java rappresenta la piattaforma ideale per lo sviluppo di queste architetture.

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


MokaByte® è un marchio registrato da MokaByte s.r.l. 
Java®, Jini® e tutti i nomi derivati sono marchi registrati da Sun Microsystems.
Tutti i diritti riservati. E' vietata la riproduzione anche parziale.
Per comunicazioni inviare una mail a info@mokabyte.it