Sessione 14

Web application

1
 Java web application
Tutte le applicazioni web possono essere rappresentate attraverso un modello client-server.

Nel modello client-server la parte client è identificata dall’utente che, attraverso un web browser, apre una pagina Html di un sito
presente su di un web server. La parte server, di contro, è rappresentata dalle componenti software che sono in esecuzione sul
web server.

Quando un utente inserisce un indirizzo di un sito web (url) nella barra degli indirizzi del browser e preme invio, tecnicamente,
sta inviando una richiesta Http al web-server. Il web server invierà una risposta Http che sarà costituita da una pagina Html che
verrà visualizzata sul browser dell’utente.

La navigazione dell’utente sul sito web tecnicamente viene definita sessione. Nella pratica, una sessione web viene aperta nel
momento in cui l’utente invia la prima richiesta Http al web server e viene mantenuta aperta finchè l’utente non chiude
esplicitamente il browser oppure dopo un determinato periodo di tempo di inattività dell’utente detto timeout della sessione web
(un parametro configurato sul web server). Ad esempio se sul web server è impostato un timeout della sessione web pari a 30
minuti, ciò vuol dire che passati 30 minuti dall’ultima richiesta Http inviata dal client, se non arrivano ulteriori richieste dal
client, la sessione viene automaticamente chiusa dal web server; questo serve per evitare di mantenere inutilmente aperte sessioni
con utenti che abbiano deciso di non voler navigare più sul sito web ma che non abbiano chiuso esplicitamente la sessione.

2
Nel caso più semplice, il sito web che stiamo contattando può essere costituito solamente da pagine Html statiche. In questa
ipotesi, l’unica attività che svolgerà il web server è quella di fornire le varie pagine Html che l’utente via via richiederà durante
la navigazione sul sito web.

Quando, invece, il sito web inizia ad essere leggermente più evoluto, è praticamente certo che per rispondere alle richieste Http il
web server abbia necessità di effettuare elaborazioni che richiedono la presenza di componenti software evolute, installate lato
server. Pensiamo, ad esempio, al caso in cui il web server per rispondere ad una richiesta Http debba effettuare una query SQL
sul database. In questi casi lato server saranno installate delle componenti software, tipicamente sviluppate in tecnologia Java,
piuttosto che Php o Microsoft .Net.

Lato web, avremo una web-application, costituita da una serie di file Html, Css, Javascript, classi Java compilate, librerie .jar,
file xml, immagini etc.

In Java, si parla di war, acronimo di Web Application Archive, ovvero l’archivio contenente tutti i file suddetti che costituiscono
la nostra applicazione web (in modo analogo a come parlavamo di jar, per gli archivi costituiti da sole classi Java).

La parte, lato server, in grado di mandare in esecuzione il war prende il nome di application server. Il processo di installazione
del pacchetto war nell’application server prende il nome di deployment della web application.

Tipicamente, per motivi di sicurezza che esulano da questo corso, lo schema di deployment di un’intera applicazione web
prevede la presenza di tre attori logici differenti:

3
 • web server

• application server

• database server

Parliamo non a caso di attori logici, perché in una reale applicazione web di una certa complessità ciascuno dei tre suddetti attori
è a sua volta costituito da una batteria di server fisici. Ovvero ci saranno n server che rappresentano il web server, n per
l’application server ed n per il database server; questo per avere dei livelli di ridondanza che garantiscano sia la sicurezza che le
performance. Sicurezza, in quanto se un server “va giù” (dall’espressione inglese “goes down”) non “va giù” l’intero sito e
performance perché attraverso tecniche di “load-balancing” (bilanciamento del carico) si possono gestire le richieste Http
provenienti dai client in maniera più efficiente sfruttando di volta in volta il server più scarico.

Quando si sviluppa un’applicazione web, infatti, bisogna sempre tenere in mente un concetto fondamentale: la concorrenza.

Gli utenti che si collegano ad un’applicazione pubblicata sul web possono essere in numero molto elevato e possono agire
simultaneamente.

La divisione logica tra web server ed application server è dovuta al fatto che per motivi di sicurezza di rete, tipicamente si
deployano le parti statiche della web-application, costituite dalle pagine Html statiche, dai file Css, dai file JavaScript e dalle
immagini, sul web server che è pubblico, ovvero accessibile a tutti sul web. Le parti dinamiche dell’applicazione, invece, poiché

4
tipicamente accedono al database e possono manipolare dati sensibili per l’applicazione sono mantenute su di un altro server
logico (come detto potrà essere una batteria di server) che viene posizionato in una zona della rete maggiormente protetta rispetto
al web server, in quanto generalmente non accessibile da tutti ma soltanto dal web server.

Accade, però, che quando l’applicazione non è particolarmente complessa e/o non deve manipolare informazioni particolarmente
sensibili, il livello di sicurezza viene abbassato e, conseguentemente, il web server e l’application server vengono fusi in un unico
server. Questo sarà anche il caso del nostro corso, dove ovviamente non siamo interessati a livelli di sicurezza di rete elevati.

Le classi Java che risiedono all’interno dell’application server e che si occupano di gestire le risposte Http alle richieste inviate
dai client hanno un proprio ciclo di vita che a grandi linee può essere schematizzato come: inizializzazione, esecuzione,
distruzione. Il componente software dell’application server che si occupa di gestire il ciclo di vita delle suddette classi Java
prende il nome di application container. Alcuni dei più famosi application server Java sono: JBoss, IBM WebSphere, GlassFish,
ColdFusion, Geronimo.

Nel caso in cui le classi Java che gestiscono l’elaborazione delle risposte Http siano delle servlet, ovvero delle sotto-classi che
ereditano da HttpServlet, il componente software dell’application server che gestisce il loro ciclo di vita prende il nome di
servlet container.

Il più utilizzato servlet container, completamente free ed open source, è Tomcat.

5
Da notare che molto spesso, impropriamente, si parla di Tomcat come application server e/o come web server, ma l’importante al
di là dei termini è aver chiaro il concetto.

Nel nostro corso, potendo fondere per i motivi detti prima web server ed application server ed essendo interessati solamente al
componente servlet container dell’application server utilizzeremo solamente Tomcat.

L’ultima release di Tomcat (la 8.0 a fine 2015) è scaricabile gratuitamente all’indirizzo: http://tomcat.apache.org/download-
80.cgi.

Vediamo adesso la struttura di directory tipica di una web application. A tale scopo si può anche prendere a riferimento una delle
web application di esempio pre-installate in Tomcat che si trovano all’interno della sotto-directory webapps.

La struttura suddetta tipicamente (ma non obbligatoriamente) è costituita da:

• html (opzionale): per i file Html

• css (opzionale): per i fogli di stile

• js (opzionale): per i file JavaScript

• img (opzionale): per le immagini

• WEB-INF (obbligatoria): contiene tra le altre cose:

6
 o web.xml: file principale di descrizione della web application

o lib: contiene le librerie utilizzate dalla web application

o classes: contiene le classi Java deployate singolarmente ed esternamente ai jar della directory lib

o META-INF: contiene il file MANIFEST.MF, che riporta ulteriori informazioni descrittive della web application

Tutte le directory ed i file suddetti devono essere inseriti all’interno di una directory principale il cui nome rappresenta il nome
della web application.

Nel caso di Tomcat, il deploy della web application può essere effettuato in due modi:

• creando un archivio compresso di nome nomeWebApplication.war e copiando il file .war sotto la directory webapps di
Tomcat

• copiando direttamente la struttura di directory e file suddetta, così com’è, sotto la directory webapps di Tomcat

Tomcat, se installato seguendo le opzioni di default sulla propria macchina, una volta avviato risponde all’indirizzo:

http://localhost:8080/.

7
Chiaramente, se è stato installato su di un’altra macchina e/o su di una porta diversa dalla 8080, l’url da contattare sarà
http://ip_macchina:porta/.

Come detto precedentemente, l’installazione di Tomcat porta con sé alcune web application pre-installate. Si tratta delle web
application posizionate sotto la directory webapps, come per esempio examples.

Se quindi volessimo contattare la web application examples dovremmo scrivere nella barra degli indirizzi del browser (con le
stesse ipotesi di prima riguardo l’installazione di Tomcat) l’indirizzo http://localhost:8080/examples.

Nel caso appena visto, examples è il nome della web application ed il nome della directory sotto webapps in cui è presente la
struttura di file e directory menzionata precedentemente.

Se vogliamo aprire una pagina Html che fa parte della web application, dovremo richiamare, da browser, l’url con il path relativo
del file Html rispetto alla radice della web application.

Ad esempio, se abbiamo creato una nostra web application di nome “Corso” e l’abbiamo deployata su Tomcat, per richiamare la
pagina index.html che abbiamo posizionato nella directory html sotto la radice della nostra web application dovremo richiamare,
da browser, l’url: http://localhost:8080/Corso/html/index.html.

8
Supponendo che la pagina index.html sia fatta nel seguente modo:

<html>
<head>
<meta charset="ISO-8859-1">
<title>Benvenuto</title>
</head>
<body>
<h1 style="text-align: center">Ciao!</h1>
</body>
</html>

Se con un qualsiasi browser inseriamo nella barra degli indirizzi l’url http://localhost:8080/Corso/html/index.html vedremo la
scritta a video “Ciao!”.

Il risultato sarà, quindi, identico a quello mostrato negli esempi relativi alla sessione sul linguaggio Html, la differenza
(sostanziale) è che la pagina questa volta ci viene restituita da un server, ovvero ha seguito un ciclo richiesta/risposta Http (anche
se tutto su computer locale, il concetto rimane invariato).