Thin Client o Fat Client?

Il Fat Client

Uno dei problemi che uno sviluppatore di applicazioni web in Ajax deve affrontare quando inizia a progettare una nuova RIA, e' come architettare il sistema affinche' risulti veramente innovativo ed interattivo.

In poche parole il sistema deve rispondere idealmente in modo istantaneo alle richieste dell'utente, avendo dal lato opposto il fatto che le risposte dal server possono essere lente in modo avvertibile per l'utente a causa di overheads di processamento e di trasferimento dal server al client.

Il consiglio e' quindi quello di effettuare chiamate remote solo quando non c'e' modo efficiente di ottenere lo stesso risultato sul browser. All'estremo si potrebbe eseguire tutte le operazioni che non coinvolgono una base dati direttamente sul browser.

Solitamente una RIA e' composta da diversi livelli logici o moduli:

• L'interfaccia Utente (detta piu' comunemente GUI o Graphical User Interface)


• Il livello della logica dell'Applicazione o della logica applicativa


• Il livello della logica di Business


• Il modulo che si occupa dell'accesso ai dati


• Il modulo che si occupa della comunicazione esterna al sistema

La GUI e' l'insieme di oggetti che l'utente vede e con cui puo' interagire. La logica applicativa e' quell'insieme di funzioni che regolano il dialogo tra l'utente e il computer, la consequenzialita' delle azioni da compiere, la regolazione del flusso di informazioni verso e dal server. Il livello della logica di Business riguarda la conoscenza del dominio e delle policies dell'owner del sito. Il modulo per l'accesso ai dati riguarda l'interazione con un database. Infine l'ultimo livello riguarda un aspetto comune a molti sistemi aziendali.

Le applicazioni web tradizionali concentrano il codice dell'interfaccia utente nel browser sul client, con un mix di HTML e CSS, con un po' di Javascript utilizzato per eseguire qualche semplice task. Tutto il resto viene gestito sul server web.

Noi pero' in Ajax vogliamo fare di meglio, vogliamo migliorare la suddivisione di questi moduli tra web server e client per ottimizzare la reattivita' della nostra applicazione e minimizzare le latenze che possono esserci.

Se spostiamo l' Application Logic (sicuramente)e anche la Business Logic (forse) sul client si migliora la nostra web application Ajax rispetto ad una tradizionale. Adesso e' il browser che controlla il flusso delle attivita'. Quindi quando un utente compie una qualche azione usando la GUI, e' il browser che prende la decisione su come agire in risposta, e invia una richiesta al server solo se necessario, e per servizi specifici.

Riguardo lo spostamento della Business Logic, assolutamente da evitare nelle applicazioni tradizionali, occorre valutare attentamente i possibili pro e contro a causa di alcuni problemi che potrebbero presentarsi:

• Spostare una Business logic magari basata su PHP, Java o C# in Javascript puo' essere arduo perche' le API standard sono minime e non si hanno a disposizione molti costrutti dei tipici linguaggio che si possono utilizzare lato server.


• Ci puo' essere un problema di portabilita' dovendo aderire agli standard diversi che ogni browser implementa. Un aiuto a cio' puo' essere dato dall'utilizzo di un framework Javascript.


• Lo sviluppo di moduli Javascript complessi non ha ancora a disposizione il supporto di un buon ambente integrato di sviluppo come avviene lato server. Percio' si introduce un livello di difficolta' aggiuntiva per lo sviluppatore inesperto.


• Il codice Javascript puo' essere visionato liberamente rivelando la Business Logic sottostante, a meno di attuare strategie opportune di offuscamento del codice.


• I dati web non vengono generalmente salvati sul client. Percio' e' comunque necessario avere una parte della business logic sul server in connessione con il modulo dell'accesso al database.

Raccontata cosi' sembra una catastrofe. Per fortuna si possono risolvere questi problemi nei modi seguenti:

• Javascript si rivela essere un linguaggio molto potente, scoprendo che nelle applicazioni web tradizionali e' stato sostanzialmente sottoutilizzato. Se poi si utilizza un framework dedicato lo sviluppo in javascript diventa molto piu' semplice e puo' dispiegare appieno tutte le sue potenzialita' finora inespresse.


• Il problema dei diversi browser viene ovviato usando un framework che incapsula e nasconde le varie differenze allo sviluppatore finale.


• Ci sono librerie che forniscono molti ambienti di Logging, Debugging, DOM Inspection e Traffic Sniffing che semplificano lo sviluppo dell'applicazione javascript e la sua manutenzione.

Di sicuro la programmazione in Javascript non e' piu' "produttiva" rispetto all'utilizzo di un linguaggio lato server. I benefici che si ottengono pero' dallo spostamento dei moduli sul client possono portare a spostare anche la Business Logic oltre che l'Application Logic.

Occorre ancora ribadire che Javascript "gira" piu' lentamente delle equivalenti applicazioni desktop, cosi' che l'ottimizzazione e' molto importante. Occorre anche tenere presente l'utilizzo della memoria di sistema ed evitare i bachi specifici di ogni browser che possono portare a sprechi e inefficienze nella memoria utilizzata.

Alternative al Fat Client

Il Thin Client

Un client leggero contiene solo il codice Javascript basilare ed effettua frequenti richieste al server conseguenti all'interazione con l'utente. Questo approccio e' utile quando:

• La business logic richiede tecniche e librerie complesse che possono essere implementate solo lato server


• Ci sono degli impedimenti sullo spostamento verso il client dell' Application e della Business Logic

Il Desktop Client

E' sostanzialmente l'approccio tradizionale della creazione di applicazioni che vengono eseguite sul client direttamente, che hanno bisogno di una installazione preventiva e che si appoggiano direttamente al sistema operativo della macchina dell'utente.

Solitamente la connessione con un database server viene effettuata usando un connettore al database server o attraverso connessioni che si appoggiano su un socket di rete dedicato verso una parte server dell'applicazione.