Tecnologie Software per il Web

Il modello MVC per le applicazioni web

Contesto di un'applicazione web

Un'applicazione web MVC è deployed (installata) su un Application Server o semplicemente un Servlet Container come Tomcat. Sia un Application Server che un Servlet Container sono HTTP servers. Tramite Tomcat è in grado di ricevere messaggi HTTP di richiesta e di inviare messaggi HTTP di risposta da/a un browser (HTTP client). L'applicazione interagisce con un database (server) per aggiornare/interrogare dati.

Componenti di un'applicazione web secondo il modello MVC

Controller

Servlets: classi Java che utilizzano la distribuzione di Tomcat per interagire con i messaggi di Request e Response (e tanto altro). Leggono i parametri inviati dal browser, aggiornano/interrogano il Model e mandano i risultati di ciò alla View.

Model

Classi Java sia per contenere dati (javabeans) che per gestire la logica dell'applicazione. Queste di solito aggiornano/interrogano la base dati tramite il DB manager e restituiscono i risultati al Controller.

View

JSP: particolari servlet che si presentano come template di pagine web (HTML). Vengono invocate dal Controller che dà loro anche accesso ai javabeans contenenti i dati risultanti dal Model. I template vengono istanziati con questi dati per formare le pagine finali (in HTML, CSS, Javascript, etc.) da inserire nella Response.

Comportamento di un'applicazione MVC

L'utente richiede una risorsa attivando una URL (cliccando su un link, inserendo un indirizzo web nel browser, cliccando submit in un form, etc.).

1. L'utente dopo aver ottenuto la homepage dall'app (magari con un form) inserisce dati e fa il submit del form.
2. Il browser costruisce una HTTP Request con informazioni prese dalla URL prodotta dal form e l'invia, tramite internet, al server HTTP interessato (Application server) che la traduce in oggetto java e la passa all'applicazione MVC ed in particolare alla sua componente Controller.
3. Il Controller riceve dall'Application server la HTTP Request tradotta dall'Application Server in oggetto Java.
4. Il Controller legge l'oggetto di richiesta HTTP, ed utilizza i dati estratti per invocare il codice costituente il Model. In particolare, predispone oggetti java che dovranno contenere le risposte del Model (javabean) ed invia le sue richieste al Model.
5. Il Model, utilizzando i parametri ricevuti, interroga la base di dati a cui è collegato e restituisce i risultati nei javabean.
6. A seconda di tali risultati il Controller invia i javabean ad una particolare componente della View e gli passa il controllo.
7. La View legge i dati dal javabean, li formatta in una pagina web, inserisce tale pagina nell'oggetto di risposta e invia questa all'Application Server.
8. L'Application Server traduce l'oggetto java di risposta ricevuto dalla View in un messaggio HTTP Response e lo invia al browser richiedente.
9. Il browser legge il messaggio HTTP Response, interpreta il codice HTML, CSS, javascript, etc. della pagina web e mostra a video il risultato finale.

Si noti che al passo 0, affinché l'utente ottenga la homepage dall'app deve esserci necessariamente un altro giro di request/response.

Applicazioni statiche e dinamiche

Un'applicazione web, fra le varie cose, a livello interfaccia, produce pagine web. È statica se tutte le pagine web prodotte sono statiche. È dinamica se almeno una pagina web è dinamica.

Una pagina web è statica se è codificata direttamente dal programmatore (usando di solito HTML e CSS). Una pagina web è dinamica se essa è generata totalmente, o solo in parte, a tempo di esecuzione (a runtime) in modo programmatico (da un programma, tramite servlet, jsp, javascript, php, etc.).

Lato client e lato server

Un'applicazione web statica esegue solo lato client. Infatti, l'HTML ed il CSS vengono interpretati e visualizzati (e quindi eseguiti) solo dal client (che di solito è il browser).

Un'applicazione web dinamica può eseguire solo lato client (se usa solo HTML, CSS e javascript) e lato server e lato client (se usa servlet, jsp, HTML, CSS, javascript, etc.).

Un'applicazione web dinamica lato client può essere sviluppata e testata utilizzando solo il browser con il comando di menu Open... ed il protocollo file (invece che http - non c'è uso di server).

Un'applicazione web dinamica in generale è sviluppata e testata utilizzando un server http (come Tomcat), un linguaggio di programmazione (come Java) ed un client http (come il browser). Può essere organizzata secondo il modello MVC.

WWW = URL + HTTP + HTML

URL

Ogni risorsa sul web ha un indirizzo unico, nel formato URL (Uniform Resource Locators). Gli URL sono un particolare tipo di URI (Uniform Resource Identifier).

URI (Uniform Resource Identifier)

Gli URI forniscono un meccanismo semplice ed estensibile per identificare una risorsa. Un URI è una stringa di caratteri. Con il termine risorsa intendiamo qualunque entità abbia una identità: un documento, un’immagine, un servizio, una collezione di altre risorse.

Caratteristiche di un URI:

• È un concetto generale: non fa riferimento necessariamente a risorse accessibili tramite HTTP o ad entità disponibili in rete (quando lo fa, diventa URL).
• È un mapping concettuale ad una entità: non si riferisce necessariamente ad una particolare versione dell’entità esistente in un dato momento.
• Il mapping può rimanere inalterato anche se cambia il contenuto della risorsa.

URN e URL

Esistono due specializzazioni del concetto di URI:

• Uniform Resource Name (URN): identifica una risorsa per mezzo di un “nome” che deve essere e restare valido globalmente unico anche se la risorsa diventa non disponibile o cessa di esistere.
• Uniform Resource Locator (URL): identifica una risorsa per mezzo del suo meccanismo di accesso primario (es. locazione nella rete) piuttosto che sulla base del suo nome o dei suoi attributi.

Applicando questi concetti ad una persona:

• URN è come identificazione basata su nome+cognome, o meglio codice fiscale (la persona potrebbe essere ovunque, ed il suo URN non cambia).
• URL è come indirizzo di casa o numero di telefono (se univoci). L'identificativo si basa sulla locazione della persona.

URN

Un URN identifica una risorsa mediante un nome in un particolare dominio di nomi (namespace). Deve essere unico e duraturo. Consente di “parlare” di una risorsa prescindendo dalla sua ubicazione e dalle modalità con cui è possibile accedervi. Un esempio molto noto è il codice ISBN (International Standard Book Number) che identifica a livello internazionale in modo univoco e duraturo un libro o una edizione di un libro di un determinato editore. Non ci dice nulla su come e dove procurarci il libro.

Struttura di un URL

Per l’http sono obbligatori il protocol e l’hostname, tutti gli altri possono essere assenti. Ad esempio, http://unisa.it è un URL corretto.

Componenti di un URL con schema HTTP-like

• <protocol>: Descrive il protocollo da utilizzare per l'accesso al server (HTTP, HTTPS, FTP, MMS, ...).
• <username>:<password>@: credenziali per l'autenticazione.
• <host>: indirizzo server su cui risiede la risorsa. Può essere un indirizzo IP logico o fisico (esempio: www.unisa.it o 193.205.160.20).
• <port>: definisce la porta da utilizzare (TCP come protocollo di trasporto per HTTP). Se non viene indicata, si usa la porta standard per il protocollo specificato (per HTTP è 80).
• <path>: percorso (pathname) che identifica la risorsa nel file system del server. Se manca, tipicamente si accede alla risorsa predefinita (es. home page à index.html).
• <query>: una stringa di caratteri che consente di passare al server uno o più parametri. Di solito ha questo formato: parametro1=valore&parametro2=valore2...
• Fragment o hash: è una breve stringa di caratteri che si riferisce a una risorsa che è subordinata a un’altra risorsa primaria.

HTTP

HTTP è l’acronimo di HyperText Transfer Protocol. È il protocollo di livello applicativo utilizzato per trasferire le risorse Web (pagine o elementi di pagina) da server a client. Gestisce sia le richieste (URL) inviate al server che le risposte inviate al client (pagine). È un protocollo stateless: né il server né il client mantengono, a livello di protocollo, informazioni relative ai messaggi precedentemente scambiati.

HTTP: terminologia

• Client: programma applicativo che stabilisce una connessione al fine di inviare delle richieste.
• Server: programma applicativo che accetta connessioni al fine di ricevere richieste ed inviare specifiche risposte con le risorse richieste.
• Connessione: circuito virtuale stabilito a livello di trasporto tra due applicazioni per fini di comunicazione.
• Messaggio: è l'unità base di comunicazione HTTP, definita come una specifica sequenza di byte concettualmente atomica.

Messaggi HTTP

• Request: messaggio HTTP di richiesta (Client a Server).
• Response: messaggio HTTP di risposta (Server a Client).

Un oggetto di tipo Resource è dato univocamente definito. URI è l’Uniform Resource Identifier – identificatore unico per una risorsa. Una Entity è la rappresentazione di una risorsa, può essere incapsulata in un messaggio, tipicamente di risposta. Una risorsa può essere una pagina X, mentre una entità corrispondente è il testo contenuto in essa. Se cambia il testo la risorsa resta comunque la pagina X.

Almeno per v1.0: protocollo request-response, stateless, one-shot. Sia le richieste al server che le risposte ai client sono trasmesse usando stream TCP.

• Segue uno schema di questo tipo:
• Server rimane in ascolto (server passivo), tipicamente sulla porta 80.
• Client apre una connessione TCP sulla porta 80.
• Server accetta la connessione.
• Client manda una richiesta.
• Server invia la risposta e chiude la connessione.

Differenze fra HTTP V1.0 e V1.1

• La stessa connessione HTTP può essere utilizzata per una serie di richieste e una serie corrispondente di risposte.
• La differenza principale tra HTTP 1.0 e 1.1 è la possibilità di specificare coppie multiple di richiesta e risposta nella stessa connessione.
• Le connessioni 1.0 vengono dette non persistenti mentre quelle 1.1 vengono definite persistenti.
• Il server lascia aperta la connessione TCP dopo aver spedito la risposta e può quindi ricevere le richieste successive sulla stessa connessione.
• Nell’esempio precedente l’intera pagina Web (file HTML + 10 immagini) può essere inviata sulla stessa connessione TCP.
• Il server HTTP chiude la connessione quando viene specificato nell’header del messaggio (desiderata da parte del cliente) oppure quando non è usata da un certo tempo (time out).

HTTP V1.1 e Pipelining

Per migliorare ulteriormente le prestazioni si può usare la tecnica del pipelining. Il pipelining consiste nell’invio di molteplici richieste da parte del client prima di terminare la ricezione delle risposte. Le risposte debbono però essere date nello stesso ordine delle richieste.

HTTP/2

Obiettivo fondamentale di HTTP/2: miglioramento performance complessiva con full backward compatibility con HTTP 1.1.

• Request-response multiplexing (è possibile per il server non inviare risposte nello stesso ordine delle richieste).
• Header compression (compressione in binario dei dati – trasferimento di dati non in formato ASCII).
• Server push (invio di pagine anche non richieste dal client ma che sicuramente lo saranno successivamente - prefetch).

Metodi HTTP

GET

Serve per richiedere una risorsa ad un server. È il metodo più frequente: è quello che viene attivato facendo click su un link ipertestuale di un documento HTML, o specificando un URL nell’apposito campo di un browser. È previsto il passaggio di parametri (la parte <query> dell’URL). Il numero di parametri è limitato dalla lunghezza massima di un URL.

POST

Progettato come il messaggio per richiedere una risorsa. A differenza di GET, i dettagli per identificazione ed elaborazione della risorsa stessa non sono nell’URL, ma sono contenuti nel corpo (body) del messaggio. Non ci sono limiti di lunghezza nei parametri di una richiesta.

Details on HTTP GET Request

The path to the resource, and any parameters added to the URL are all included on the “request line” /select/selectBeerTaste.jsp?color=dark&taste=malty HTTP/1.1 GET.

HTTP Request: Altri metodi

PUT e DELETE

• PUT: Chiede la memorizzazione sul server di una risorsa all’URL specificato. Il metodo PUT serve quindi per trasmettere delle informazioni dal client al server. A differenza del POST però si ha la creazione di una risorsa (o la sua sostituzione se esisteva già). L’argomento del metodo PUT è la risorsa che ci si aspetta di ottenere facendo un GET con lo stesso nome in seguito.
• DELETE: Richiede la cancellazione della risorsa riferita dall’URL specificato. Sono normalmente disabilitati sui server pubblici.

HEAD, OPTIONS e TRACE

• HEAD: è simile al metodo GET, ma il server deve rispondere soltanto con gli header relativi, senza body. Viene usato per verificare un URL.
• Validità: la risorsa esiste e non è di lunghezza zero. Accessibilità: è richiesta autenticazione non.
• OPTIONS: serve per richiedere informazioni sulle opzioni disponibili per la comunicazione.
• TRACE: è usato per invocare il loop-back remoto a livello applicativo del messaggio di richiesta. Consente al client di vedere che cosa è stato ricevuto dal server: viene usato nella diagnostica e nel testing dei servizi Web.

MIME: Multipurpose Internet Mail Extensions

Inizialmente sviluppato per la posta elettronica. Usato per specificare al browser la forma di un file inviato dal server, è inserito dal server all’inizio del documento. Specifica del tipo. Formato: Tipo/sottotipo. Esempi: text/plain, text/html, image/gif, image/jpeg. È possibile estendere i tipi MIME esistenti con dei tipi sperimentali. Il tipo o sottotipo inizia con una x-- video/x-nuovoformato, audio/x-wav. I tipi sperimentali richiedono che il server invii al browser un’applicazione o plug-in per poter far interpretare correttamente i nuovi tipi di dati al browser.

HTTP Response: Codici di stato

Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta e le altre due la risposta specifica. Ci sono 5 classi:

• 1xx: Informational. Una risposta temporanea alla richiesta, durante il suo svolgimento (sconsigliata a partire da HTTP 1.0).
• 2xx: Successful. Il server ha ricevuto, capito e accettato la richiesta.
• 3xx: Redirection. Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte del client per portare a termine la richiesta.
• 4xx: Client error. La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non autorizzata).
• 5xx: Server error. La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un problema (suo).

HTTP Response: Esempi di codici di stato

• 100 Continue (se il client non ha ancora mandato il body, deprecato da HTTPv1.0).
• 200 Ok (GET con successo).
• 201 Created (PUT con successo).
• 301 Moved permanently (URL non valida, il server conosce la nuova posizione).
• 400 Bad request (problemi del Client, errore sintattico nella richiesta).
• 401 Unauthorized (manca l’autorizzazione).
• 403 Forbidden (richiesta non autorizzabile).
• 404 Not found (URL errato).
• 500 Internal server error (problemi del Server, tipicamente un’applicazione su server malfatta).
• 501 Not implemented (metodo non conosciuto dal server).

Tomcat

Tomcat è costituito da:

1. Tomcat Web server (accetta le richieste e restituisce pagine statiche – a volte è un software a parte come Apache).
2. Servlet container (permette l’esecuzione di servlet e jsp aggiunte ad esso in web apps).

Tomcat non è (del tutto) un Application server in quanto anche se include un web server e un servlet container manca di altre tecnologie web più avanzate.

Web server e Servlet container

Un web server riceve la HTTP request e controlla se la risorsa richiesta è statica (per esempio, una pagina html) o dinamica (chiamata a una servlet). Nel caso sia statica, il web server restituisce la risorsa richiesta. Nel caso sia dinamica, il web server passa la richiesta al servlet container per l'esecuzione della servlet.

What is a real Container?

Servlets don’t have a main() method. They’re under the control of another Java application called a Container. Tomcat is an example of a Servlet Container. When your Web Server application (like Apache) gets a request for a Servlet, the server hands the request not to the Servlet itself, but to the Container.