Server-side Programming: Java servlets Parte II

Transcript

1 Corso di Laurea Specialistica in Ingegneria Informatica Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni Corso di Reti di Applicazioni Telematiche a.a Server-side Programming: Java servlets Parte II Simon Pietro Romano

2 Agenda Servlet: Concetti introduttivi Ciclo di vita delle servlet; servlet request, servlet response, servlet config, servlet context Learn by Example Esempi di servlet generiche Configurazione delle web application Introspezione della richiesta HttpServlet: HttpServletRequest, HttpServletResponse Learn by Example Un esempio di servlet HTTP Introspezione della richiesta HTTP Parte II

3 Applicazione Web (web app) Una raccolta di: servlet Java Server Page (JSP) documenti HTML immagini template altre risorse web Concepita per permettere un deployment portabile su qualunque server web che supporti le servlet

4 Web apps: motivazioni Garantire la portabilità delle applicazioni basate sul web, grazie a specifici accordi su: Localizzazione dei file dell applicazione sul server Formato dei file di configurazione del server Archivi war Web Application Archive: Un archivio contenente tutti i file di un applicazione web Costruito mediante l utility di compressione jar (Java ARchive) Memorizzato in una specifica cartella del web server

5 Archivi war in Tomcat Tutti i file.war sono contenuti nella directory webapps del server Tomcat

6 Contenuto di un archivio war L archivio evidenziato nella slide precedente (visualizzato mediante Winrar )

7 La directory WEB-INF Una directory speciale: I file al suo interno non vengono inviati direttamente al client, dato che contengono: Classi java Informazioni di configurazione per la web app La cartella WEB-INF/classes contiene: i file di classe per le servlet della web app Le classi di supporto La cartella WEB-INF/lib contiene le classi memorizzate, per comodità, in archivi jar I caricatori di classi del server cercano automaticamente nelle suddette directory per caricare le classi invocate

8 Il descrittore di deployment Il file web.xml nella directory WEB-INF contiene informazioni di configurazione relative alla web app nella quale risiede: Registrazione delle servlet Mapping delle URL Tipi MIME Caratteristiche avanzate: Vincoli di protezione a livello di pagina Comportamento delle servlet in ambiente distribuito

9 Il file web.xml Nome simbolico dato alla servlet Classe della servlet

10 Invocazione della servlet pippozzo La servlet è stata invocata tramite il nome simbolico prescelto!

11 Mapping di servlet Consente di impostare pattern di URL che richiamano una determinata servlet registrata nel container Utile per: Nascondere l uso di servlet da parte di un sito web Sostituire in maniera indolore una pagina preesistente, corrispondente ad una determinata URL

12 Un esempio di mapping Qualsiasi richiesta della risorsa sarà gestita dalla servlet il cui nome simbolico è pippozzo

13 Invocazione della pagina ciao.html L invocazione della servlet è mascherata dalla pagina statica ciao.html

14 Regole di mapping Mapping esplicito: Tipo esempio precedente: Utile per sostituire una singola pagina esistente Mapping con prefisso di percorso: Es: /prefisso/* : Gestisce tutte le richieste che iniziano con il prefisso specificato Mapping di estensione: Es: *.jsp, *.do : Gestisce tutte le richieste che terminano con una particolare estensione Mapping predefinito: / : Specifica la servlet predefinita per la web app: Da utilizzare nel caso non si verifichi nessun altra corrispondenza Identico al mapping con prefisso: /*

15 Esempi di mapping Tutte le richieste aventi AT-Samples come prefisso devono essere gestite dalla servlet avente nome simbolico pippozzo Tutte le richieste aventi comestai come estensione devono essere gestite dalla servlet avente nome simbolico pippozzo

16 Effetti del mapping (1/2) Qualsiasi richiesta avente AT-Samples come prefisso viene servita dalla servlet avente nome simbolico pippozzo Mod ulo

17 Effetti del mapping (2/2) Qualsiasi richiesta avente comestai come estensione viene Qualsiasi richiesta avente comestai come estensione viene servita dalla servlet avente nome simbolico pippozzo

18 La comunicazione tra servlet e container All attivazione di una servlet, il container: Passa alla servlet un oggetto, chiamato ServletConfig,contenente informazioni necessarie per una corretta inizializzazione ServletConfig consente di accedere ad un ulteriore oggetto, chiamato ServletContext, che viene utilizzato dalla servlet per gestire eventuali successive comunicazioni con il container: Determinare il tipo MIME di un file; Inoltrare le richieste (dispatching); Scrivere informazioni in un file di logging; Ecc NB: Esiste un context per ogni web application e per ogni Java Virtual Machine!

19 L interfaccia ServletConfig E implementata dalla classe GenericServlet: In tal modo, è possibile gestire le informazioni di configurazione in maniera semplice ed immediata

20 Un occhio alla documentazione

21 Inizializzazione: l oggetto ServletConfig Quando la servlet viene attivata dal container: Viene invocato il metodo init(), il quale ha, come parametro, l oggetto ServletConfig E compito della servlet salvare tale oggetto come propria variabile di istanza La classe GenericServlet effettua tale operazione nell implementazione del metodo init()

22 Esempio di inizializzazione La servlet è dotata di una variabile di istanza, di tipo ServletConfig Nel metodo init(), tale variabile è settata al valore passato dal container

23 Informazioni di contesto: un esempio

24 Esecuzione della servlet NB: Non compare alcun parametro di inizializzazione, né per la servlet, né per il contesto

25 Passaggio dei parametri di inizializzazione in Tomcat Si può utilizzare il descrittore di deployment web.xml: Per il context: <context-param> <param-name> nome_del_parametro </param-name> <param-value> valore_del_parametro </param-value> <description> descrizione_del_parametro </description> </context-param> Per le servlet: <init-param> <param-name> nome_del_parametro </param-name> <param-value> valore_del_parametro <description> descrizione_del_parametro </description> </param-value> </init-param>

26 Un esempio

27 Esecuzione della servlet NB: In tal caso, i parametri di inizializzazione del contesto e della servlet vengono stampati nella risposta

28 Introspezione della request L oggetto ServletRequest mette a disposizione tutta una serie di metodi per reperire informazioni sulla richiesta effettuata dal client: Protocollo; Nome del server; Porto del server; Indirizzo dell host client; Nome dell host client;

29 Un esempio Un frammento di codice che effettua introspezione della richiesta NB: Si provi ad aggiungere tale frammento al codice della precedente servlet

30 Esecuzione della servlet Risultato dell introspezione Mod ulo

31 HttpServlet Molto spesso, le servlet utilizzano il protocollo HTTP: Il package javax.servlet.http è stato concepito proprio per fornire un ulteriore supporto agli sviluppatori di questo tipo di servlet Tale package semplifica la gestione dei principali messaggi HTTP: GET POST HEAD TRACE

32 Il metodo HTTP GET Il metodo HTTP GET è utilizzato per ricevere informazioni da un web server, sotto forma di: File: Testo, html, ecc. Output proveniente da un particolare dispositivo presente sul server: Es: telecamera, ecc. Output proveniente da un particolare programma in esecuzione sul server: Una servlet, uno script CGI, ecc.

33 HTTP GET: passaggio dei parametri Un esempio: L URL in questa richiesta GET invoca la servlet MiaServlet e contiene due parametri, chiamati, rispettivamente, parametro1 e parametro2: Ogni parametro è costituito da una coppia nome/valore, secondo il formato: Nome=valore I parametri seguono il nome della servlet e sono preceduti da un punto interrogativo ('?') Ogni parametro è separato dai precedenti tramite un ampersand ('&').

34 HTTP GET: limitazioni La maggior parte dei server Web limita la quantità massima di dati che possono essere scambiati all interno di una URL (solitamente il limite è pari a qualche centinaio di byte ) Nel caso in cui si presenti la necessità di Nel caso in cui si presenti la necessità di passare molti dati al server all interno della richiesta, bisogna ricorrere al metodo HTTP POST

35 HTTP GET: particolarità E importante notare che ci si aspetta che l implementazione del metodo GET da parte di qualsiasi server sia: Sicura (safe): Vale a dire, priva di effetti collaterali (side effects) Idempotente: Cioè, capace di produrre il medesimo output in seguito ad invocazioni successive

36 Il metodo HTTP POST Con il metodo POST, tutti i parametri di input per il server web sono passati all interno di un input stream: Non esiste più, dunque, la limitazione sulla dimensione massima delle informazioni scambiate tra client e server I parametri si trovano all interno della richiesta, subito dopo l header A differenza del metodo GET, il metodo POST non è concepito per essere né sicuro, né idempotente: Sono ammesse modifiche ai dati Non è richiesto il requisito di ripetibilità delle transazioni tra client e server

37 Il metodo HTTP HEAD E molto simile al metodo GET La richiesta è identica, eccezion fatta per la parola chiave HEAD al posto di GET Nella risposta, il server restituisce solo le informazioni relative all header HEAD è spesso utilizzato per controllare: La data di ultima modifica di un documento presente sul server: utile per gestire il caching La dimensione di un documento prima di scaricarlo dal server: Per consentire al browser di mostrare, successivamente, una barra relativa allo stato di avanzamento della procedura Il tipo di server: Per consentire al client di customizzare le richieste inviate ad un particolare server Web Il tipo di documento richiesto: Per consentire al client di verificare se per esso sia disponibile il necessario supporto

38 Le classi di supporto per HTTP Il package javax.servlet.http semplifica notevolmente la scrittura di servlet HTTP: La classe astratta HttpServlet eredita tutte le caratteristiche della classe GenericServlet ed include funzionalità specifiche del protocollo HTTP: L implementazione del metodo service() si occupa di gestire in maniera opportuna il dispatching (cioè la consegna) dei messaggi HTTP ad uno dei metodi speciali disponibili per tale protocollo Per tale motivo, non è necessario (anzi, è sconsigliato!) reimplementare il metodo service()

39 I metodi speciali per HTTP doget() Per gestire richieste di tipo GET dohead() Per gestire richieste di tipo HEAD dodelete() Permette ad un client di eliminare un documento da un Web server dooptions() Restituisce informazioni relative ai metodi supportati dal server dopost() Per gestire richieste di tipo POST doput() Permette ad un client di salvare un documento su un Web server (simile al trasferimento di file mediante FTP ) dotrace() Utilizzato per il debugging

40 HttpServlet: gestione delle richieste Web server Sottoclasse HttpServlet richiesta GET risposta richiesta POST risposta richiesta TRACE risposta service() doget() dopost().. dotrace()

41 Utilizzo delle classi di supporto Quando si usano le classi di supporto per HTTP, generalmente occorre creare una nuova servlet che estende HttpServlet e sovrascrivere : o il metodo doget() o il metodo dopost() o entrambi. I metodi di elaborazione dei messaggi HTTP ricevono in ingresso due parametri: Un oggetto HttpServletRequest: Contenente numerosi metodi di ausilio nell analisi della richiesta Un oggetto HttpServletResponse: Contenente numerosi metodi di ausilio nella preparazione della risposta

42 Introspezione della richiesta HTTP Utilizzando l oggetto HttpServletRequest è possibile accedere in maniera semplice ed efficace ai campi dell header HTTP:

43 Esecuzione della servlet