Capitolo 5 - Il ruolo del web server

Introduzione

Vediamo ora alcuni aspetti che interessano principalmente il web server all’interno delle nostre web applications. Partiamo con l’analisi del ruolo del web server nelle applicazioni precedentemente implementate in assenza dell’approccio Ajax, arrivando ad analizzare il ruolo nel web 2.0 che comunque viene mantenuto dal parte del web server.

Utilizzo del web server

Nel ciclo di vita delle nostre applicazioni Ajax, il web server deve adempiere a due ruoli principali, e quesi sono tra loro ben distinti.
Primo, deve caricare l’applicazione sul browser del client. Possiamo quindi assumere che la trasmissione iniziale delle librerie e dei file che compongono lo scheletro della nostra applicazione sia una fase abbastanza statica. Cioe’ scriviamo la nostra applicazione come un insieme di file .html, .css e .js che anche un web server elementare puo’ gestire.
Secondo , deve dialogare con il client, recuperando i dati eventalmente da un database server e rifornire il client con questi dati a fronte di una richiesta pervenuta da esso.
Poiche’ abbiamo a disposizione solo l’ HTTP come unico meccanismo di trasporto disponibile, solo il client puo’ effettuare delle richieste, mentre il server puo’ solo rispondere a tali richieste.

Progettazione lato server

In una applicazione web convenzionale la progettazione lato server tende a diventare piuttosto complessa, dovendo controllare e monitorare il flusso delle operazioni effettuate dall’utente attraverso l’applicazione, e mantenere uno stato consistente con esso.
Solitamente l’applicazione e’ progettata in un linguaggio particolare, tipo JSP o ASP.NET+C#, che possono a loro volta essere conseguenza di una determinata architettura utilizzata, o di un sistema operativo sottostante. Ad esempio, se optiamo per un application server su hardware Linux, non possiamo adoperare un web server IIS collegato al framework .NET, e probabilmente opteremo per l’utilizzo o di Tomcat + JSP oppure di Apache + PHP come infrastruttura lato server.
Non parliamo qui dei framework tipo JSF (Java Server Faces) o STRUTS, primo perche’ non li ho mai utilizzati, quindi non li conosco se non superficialmente, secondo perche’ non modificano di molto il nostro discorso.


Architetture ad N livelli


Un concetto solitamente utilizzato nelle applicazioni distribuite e’ quello di livello. Un livello spesso rappresenta un particolare insieme di responsabilita’ per una applicazione, ma descrive anche un sottosistema che puo’ essere isolato fisicamente su una particolare macchina o processo.

I primi sistemi distribuiti erano costituiti da un livello client e da un livello server. Il client era solitamente un programma desktop che utilizzava una libreria per il socket di rete per comunicare con il server. Ad esempio i form progettati con Oracle Developer 2000 erano form desktop che si connettevano al database server Oracle per recuperare i dati e per gestire la logica lato server con procedure pl/sql.

Allo stesso modo le prime applicazioni web consistevano di una applicazione sul browser che dialogava con il web server, che si occupava solo di inviare i files sulla rete prelevandoli dal proprio filesystem.

A mano a mano che le applicazioni diventavano piu’ complesse e cominciavano a richiedere l’accesso alle basi dati, il modello a due livelli e’ stato applicato al solo web server, arrivando cosi’ al modello a tre livelli comunemente utilizzato, in cui il web server si frappone tra il client e la base dati.

Raffinamenti successivi hanno portato alla separazione ulteriore tra livello di presentazione e regole di business, sia come processi separati, sia come progettazione modulare all’interno di un unico processo.

Le moderne applicazioni web hanno tipicamente due liveli principali. Il livello di business modellizza il dominio del business e dialoga direttamente con il database. Il livello di presentazione prende i dati dal livello di business e li presenta all’utente. Il browser agisce come client muto.

L’introduzione dell’approccio Ajax puo’ essere considerato come lo sviluppo di un livello client ulteriore, che separa le responsibilita’ del tradizionale livello di presentazione della gestione del flusso di lavoro e della sessione utente tra il web server ed il client.


Il ruolo del livello di presentazione lato server puo’ essere ulteriormente ridotto, e il controllo del workflow puo’ essere trasportato sul nuovo livello del client, scritto in Javascript ed eseguito all’interno del browser.



Manutenzione lato client e lato server dei domini di business


In una applicazione Ajax dobbiamo ancora modellizzare il dominio del business sul server, vicino alla base dati e ad altre risorse vitali centralizzate. Comunque, per dare al codice lato client la sufficiente intelligenza e reattivita’, dobbiamo mantenere un modello parziale del dominio di business nel browser. Cio’ genera il problema di manterere sincronnizzati questi due modelli tra di loro.
In realta’ e’ un problema che era gia’ noto sugli application server J2EE, per cui si utilizzavano degli oggetti dedicati al trasferimento dei dati tra i livelli, formati da semplici oggetti JAVA di intercomunicazione.
Nelle nostre applicazioni queste comunicazioni tra livelli si riducono a leggere dati dal server e a scrivere dati sul server. Abbiamo gia’ affontato le metodologie per leggere dati dal web server. E i formati di trasporto dati che possiamo utilizzare. Sappiamo anche gia’ come poter inviare dati al web server. Vedremo successivamente come scrivere dati sulla base dati, ovvero sul livello piu’ lontano rispetto al client.



Web server senza alcun framework

Il modo piu’ semplice di avere un framework lato webserver e’ quello di non averne affatto.
Come abbiamo visto finora, definiamo una pagina master che conterra’ le librerie Javascript, i fogli di stile, e tutte le altre risorse, compreso l’ajax engine. Per fornire i dati a questa pagina dobbiamo semplicemente sostituire o popolare i vari layer con i flussi di dati di nostra scelta.

La controindicazione principale di questo approccio in una applicazione web classica e’ data dal fatto che i collegamenti tra i vari documenti sono sparpagliati nei documenti stessi. Cioe’ il ruolo del Controllore del modello MVC (Model View Controller) non e’ definito con chiarezza in un unico posto.
Se occorre ridefinire il flusso di lavoro occorrera’ di certo modificare i collegamenti in piu’ posizioni su piu’ documenti.

Usando invece i frameworks come Apache Struts si usa la variante Model2, per cui si centralizza il ruolo del Controllore in un unico servizio o pagina che diventa responsabile del routing delle richieste verso i servizi di back-end e della presentazione delle Viste corrette.

Il problema e’ dato dal fatto che questi frameworks non gestiscono il rilascio del client in fase di startup.


Utilizzo di un framework lato server basato su Componenti


Widgets per le web applicatioins

I frameworks basati sui componenti aiutano ad innalzare il livello di astrazione per la progettazione delle interfacce grafiche per il web, fornendo un toolkit di componenti lato server (o anche lato client, come vedremo in seguito) le cui Application Programming Interfaces (o API) assomigliano a quelle usate per i widget set di una GUI desktop.
Quando i widget web vengono visualizzati generano automaticamente un flusso di istruzioni HTML e un gestore Javascript che fornisce la funzionalita’ equivalente a quelli desktop all’interno del browser, liberando il progettista da un mare di codifica di base.

Molti frameworks di questo tipo descrivono l’interazione con l’utente usando analogie con il mondo desktop. Cioe’ un componente Button avra’ un event handler per l’evento click, e cosi’ via.

I frameworks piu’ intelligenti gestiscono il processing degli eventi sul server in modo nascosto, mentre quelli piu’ grossolani attiveranno una chiamata al server ad ogni evento attivato.

I frameworks piu’ noti sono i Form Windows per IIS/.NET e le Java Server Faces sotto Tomcat.

Oggigiorno questi framework hanno integrate funzionalita’ di tipo Ajax, strettamente legate comunque al framework stesso, come ad esempio la libreria AJAX.NET.


Conclusione

Abbiamo analizzato piu’ da vicino gli elementi architetturali che possono costituire la nostra web application. Questi elementi sono indipendenti dall’approccio che utilizzeremo in ultima istanza per costruire la nostra applicazione seguendo l’approccio Ajax. Seguiremo comunque lo schema a piu’ livelli di separazione, con la presenza di un ajax engine lato client appoggiato al browser web, un application server intermedio con un framework lato server che possa agire come Controller distribuito solo per il web server in congiunzione con il Controller dato dall’ajax engine sul client, un database server, ed un framework basato sui componenti, pero’ lato client e strettamente legato all’ajax engine vero e proprio.

In realta’ il Controller e’ composto da due moduli. Uno lato client ed uno lato server. Questa struttura permette di poter riutilizzare la parte client del Controller, e di utilizzare la parte server usando la stessa architettura su piattaforme diverse, cambiando solo il modo di implementazione che deve adattarsi alla piattaforma utilizzata.

Il Controller lato web server e’ dipendente dalla piattaforma server usata (.NET , JSP o PHP ad esempio), mentre la porzione di Controller collegata all’ajax engine sul client e’ grossomodo indipendente e riutilizzabile per qualunque piattaforma.

Come framework lato client basato sui componenti, ovvero come widgets per il web, vedremo l’utilizzo sia della libreria di ActiveWidgets v2.5.1 , sia di quella Ext.js 2.0.