Applicazioni Web in Java

Transcript

1 Applicazioni Web in Java Programmazione di Applicazioni Data Intensive Laurea in Ingegneria e Scienze Informatiche DISI Università di Bologna, Cesena Giacomo Domeniconi, Gianluca Moro, Roberto Pasolini DISI Università di Bologna, Cesena name.surname@unibo.it

2 Ripasso: Applicazioni Web Un applicazione web è un insieme di risorse fruibile attraverso un browser web con capacità di elaborazione lato web browser e/o lato web server Qualsiasi utente, eventualmente autenticato, può usufruire dell applicazione conoscendone il relativo URL L applicazione si basa su tecnologie standard W3C implementate dai browser e utilizzate nel World Wide Web protocollo HTTP per lo scambio di informazioni (richiesta-risposta) linguaggi HTML e CSS per la presentazione linguaggio JavaScript per l interattività e la logica lato client Lato server si usano linguaggi quali PHP, Python, Java, 2

3 Ripasso: Vantaggi delle applicazioni Web Rispetto ad applicazioni tradizionali compilate ed eseguite localmente al dispositivo in cui sono installate, ad es. app per smartphone)... Un applicazione Web si scrive una volta per tutte le piattaforme utilizzando tecnologie standard Gli standard (in particolare HTML5) stanno progressivamente fornendo funzionalità che in precedenza erano specifiche per ogni OS (localizzazione, notifiche ecc.) Si può usare da qualsiasi dispositivo dotato di un browser PC, smartphone, tablet, smart TV ecc. L avvio iniziale e gli aggiornamenti dell applicazione non richiedono installazioni o altri interventi sui client 3

4 Ripasso: modello client-server e HTTP Le applicazioni web si basano sul modello client-server Un server ospita una o più applicazioni Molteplici client si connettono al server per utilizzarne le applicazioni La comunicazione avviene attraverso HTTP (HyperText Transfer Protocol), basato su scambio di richieste e risposte Il client invia una richiesta al server per una risorsa (es. una pagina) Il server risponde inviando la risorsa o un errore (es. 404 Not found ) HTTP è stateless: ogni richiesta è indipendente dalle precedenti poiché non mantiene lo stato della connessione Nella pratica, si usano le sessioni per mantenere memoria dello stato Client richiesta Internet risposta Server 4

5 Ripasso: tecnologie lato client Esistono diversi linguaggi interpretati dal browser (client) che permettono la fruizione di contenuti e servizi del WWW HTML (HyperText Markup Language) è usato per strutturare e definire il contenuto di una pagina Può includere anche altri aspetti (stile di presentazione ecc.), che però sono per buona prassi gestiti in file separati CSS (Cascading Style Sheet) si usa per definire lo stile di presentazione e il layout della pagina JavaScript fornisce capacità computazionale alla pagina web, pagine dinamiche (animazioni, contenuto interattivo ecc.) AJAX (Asynchronous JavaScript and XML) prevede l uso di JavaScript per aggiornare in modo asincrono singole parti di una pagina 5

6 Ripasso: tecnologie lato server I siti web più semplici ( Web 1.0 ) sono statici, ossia senza capacità computazionale Le pagine sono file passivi non aggiornati in modo automatico Il loro contenuto è gestito da chi amministra il sito La maggior parte dei siti moderni ( Web 2.0 ) sono dinamici Le pagine web sono generate con elaborazioni lato server e/o client Gli utenti forniscono dei contenuti mediante piattaforme di blogging, social network ecc. che le elaborano e le pubblicano Nei siti dinamici, il server deve generare una pagina di risposta ad ogni richiesta La risposta dipende dallo stato dell applicazione: la stessa richiesta in tempi diversi può generare risposte diverse Varie tecnologie per generare pagine: PHP, ASP.NET, JSP, Python ecc. 6

7 Sviluppo Web in Java Java è tra i linguaggi utilizzati per lo sviluppo server-side di applicazioni web Poco adatto per applicazioni semplici, per cui soluzioni più ad alto livello consentono uno sviluppo rapido (es. Ruby on Rails, Python,...) Appropriato invece per applicazioni enterprise: complesse e con stringenti requisiti di affidabilità, efficienza, sicurezza, scalabilità Es.: Twitter è migrato da Ruby on Rails a tecnologie Java per migliorare la scalabilità [ Diverse tecnologie Java sono utilizzate nello sviluppo Web Alcune tecnologie sono di basso livello: sono state introdotte per prime e forniscono le funzionalità di base (servlet e JSP) Su queste sono state poi costruite tecnologie ad alto livello per facilitare lo sviluppo di applicazioni complesse: Expression Language (EL), JSP Standard Tag Library (JSTL), JavaServer Faces (JSF),... 7

8 Java Enterprise Edition Java Enterprise Edition (Java EE) è una piattaforma basata su Java SE per lo sviluppo di applicazioni server-based complesse Sviluppata inizialmente da Sun Microsystems, oggi rilasciata da Oracle Architettura multi-tier: client Web e EJB Container DB Definisce un insieme di API per gestire diversi servizi di base transazioni, scambio di messaggi tra moduli, persistenza etc. Le applicazioni Java EE girano su appositi application server, che implementano le API EE per fornirne i servizi alle app GlassFish è l implementazione di riferimento rilasciata da Oracle 8

9 Applicazioni Web Java Java EE definisce concetti specifici per applicazioni Web Le servlet accettano le richieste dai client e generano risposte ad esse JSP e specifiche correlate si usano per realizzare pagine dinamiche Un applicazione Web Java è costituita da servlet, pagine JSP, classi Java e altre risorse interdipendenti tra loro È distribuita in forma di file WAR (Web Archive), simile a JAR Un servlet container (o web container) è un server su cui è possibile caricare ed eseguire applicazioni Web Java Utilizzato anche come componente negli application server Java EE Il container riceve richieste dai client e le inoltra alla specifica applicazione in grado di gestirla (se disponibile) Java EE definisce le modalità d interazione tra container e applicazioni 9

10 Laboratorio: sviluppo del caso di studio Realizzeremo un sito di e-commerce semplificato, ma con dati reali, come caso di studio di applicazioni data intensive secondo metodi, modelli e algoritmi tipici di queste applicazioni Nelle esercitazioni di lab, vedremo le parti di cui il sito è composto e ne completeremo design e implementazione Tecnologie impiegate: JSP, Java e l ambiente di esecuzione Apache Tomcat, un servlet container tra i più diffusi L estensione Web Tools Platform di Eclipse fornisce supporto specifico per lo sviluppo e deployment di applicazioni Web Java su diversi servlet container, incluso Tomcat Le applicazioni realizzate sono indipendenti dal browser, pertanto possono essere testate su uno qualsiasi (es. Firefox) 10

11 Pagina iniziale della webapp Header (mostrato in tutte le pagine) con form di autenticazione Ricerca testuale di prodotti Albero delle categorie: cliccare sui pulsanti +/- per espandere/comprimere i nodi 11

12 Model-View-Controller Il pattern MVC prevede la netta separazione dei componenti di un applicazione in questi tre aspetti model: rappresentazione dei dati dell applicazione view: presentazione dei contenuti controller: elaborazione dei dati e dei contenuti (business logic) Questa divisione facilita lo sviluppo e il mantenimento dell applicazione È possibile separare e parallelizzare il lavoro, assegnando lo sviluppo dei componenti a personale con ruoli distinti In un applicazione Java Web tipica i tre aspetti si trovano in... model: classi Java, in particolare bean view: pagine JSP+HTML, CSS (cascading style sheet), JavaScript controller: servlet e altre classi Java 12

13 Organizzazione generale del progetto Un package Java model contiene le classi che modellano le entità gestite dell applicazione (prodotto, utente,...) La parte controller include il package servlet con le servlet che rispondono ai client e altri package di supporto dao: interfaccia per astrarre l accesso al database dao.jdbc: implementazione di dao basata su JDBC session: gestione dei dati di sessione (autenticazione e carrello) La parte view è costituita da pagine JSP invocate dalle servlet e da risorse statiche usate nelle pagine generate (es. file CSS) L applicazione contiene inoltre dei file di configurazione, letti dal container per eseguirla correttamente 13

14 UML: package del progetto servlet usa / crea usa / crea model session usa SessionManager (metodi gestione sessione) implementa SessionManagerImpl usa usa usa / crea dao GeneralDAO (metodi accesso database) dao.jdbc implementa JDBCGeneralDAO 14

15 Tomcat: Contesto Tomcat esegue ciascuna applicazione in un contesto diverso Ciascun contesto costituisce uno scope separato da altre applicazioni ed è utile ad es. per evitare conflitti tra risorse con lo stesso nome A ciascun contesto è associato un percorso, il context path Tomcat inoltra ciascuna richiesta HTTP all applicazione il cui percorso coincide col prefisso dell URL richiesto L applicazione invocata dal server sceglie poi come rispondere in base alla parte dell URL successiva (servlet path) indirizzo e porta del server context path servlet path Le proprietà del contesto, incluso il percorso, sono configurate in un file context.xml incluso nella webapp <Context path="/estore" > </Context> 15

16 Configurazione dell'applicazione Web Ogni applicazione Web contiene la sua configurazione in un file web.xml, detto anche deployment descriptor Il formato del file è standard, dettato da Java EE e letto da qualsiasi servlet container al caricamento dell applicazione al contrario di context.xml, specifico di Tomcat Il file può includere diversi elementi, tra cui definizione delle servlet e loro mapping ai servlet path definizione dei filtri servlet e loro associazioni alle servlet configurazione delle pagine JSP, ad es. possibilità di scripting e applicazione di intestazione e piè di pagina massimo tempo di inattività nelle sessioni Alcuni di questi elementi possono in alternativa essere configurati tramite annotazioni nelle opportune classi Java 16

17 Configurazione Applicazione: Elementi Principali Il file web.xml contiene un tag web-app come elemento radice, che contiene i vari dettagli della configurazione <web-app [elementi standard XML] > elementi configurazione... </web-app> Col tag display-name si indica il nome della webapp usato ad es. nella GUI di amministrazione del servlet container <display-name>estore</display-name> In welcome-file-list si indica il percorso dell home page della webapp, (usato se il servlet path richiesto è vuoto) <welcome-file-list> <welcome-file>home</welcome-file> </welcome-file-list> 17

18 Risorse della Web App accessibili ai Client Ogni applicazione contiene una directory webapp di file che il container rende accessibili ai client tramite richieste HTTP Quando richiesti, i file JSP (pagine dinamiche) nella directory sono elaborati dal servlet container, come spiegato in seguito Gli altri file costituiscono risorse statiche, che sono restituite ai client così come sono, spesso usate all interno delle pagine Ad es. un file CSS style.css usato da tutte le pagine dell app Ad ogni file è associato in automatico un URL dato dal nome Il nome nell URL è preceduto dal context path dell applicazione es.: Alcuni file (dentro le directory WEB-INF e META-INF) sono privati all applicazione, non accessibili via HTTP 18

19 Modello del dominio: classi bean Nel design di applicazioni object-oriented è buona prassi definire classi apposite per rappresentare gli oggetti del dominio applicativo Ben distinte da classi con altre funzioni, ad es. per l interfaccia utente Nel nostro caso di studio: utenti, prodotti, ordini, categorie,... Queste classi costituiscono il model nello schema MVC I bean sono uno standard in Java per oggetti di questo tipo Detti anche POJO (Plain Old Java Object) lo standard definisce convensioni per metodi, loro nomi, semantica... I bean espongono proprietà di vari tipi che incapsulano le caratteristiche di un oggetto Ad es. le proprietà di un prodotto sono il nome, la descrizione, la marca, il prezzo ecc. 19

20 UML: classi del package Model User + nam e: string + password: st ring + m ailaddress: st ring 1 0..n Invoice + date: date 1 1..n Invoice Ent ry + quantity: int 0..n Review + score: int + sum m ary: string + text: string 1 ShoppingCart CartEntry ry 1 0..n + quantity: int 0..n 1 Product + nam e: string + descript ion: st ring n 0..n Cat egory n parent 20

21 Convenzioni da usare nelle classi bean Le classi bean devono avere un costruttore senza argomenti Opzionalmente possono definirne altri per comodità Per ogni proprietà prop di tipo T, devono essere definiti un metodo getprop per ottenerne il valore (getter) public T getprop() {... } per proprietà di tipo boolean, il metodo può avere nome isprop un metodo setprop per impostarne il valore (setter) public void setprop( T newvalue ) {... } si può omettere per avere una proprietà in sola lettura L uso di queste convenzioni garantisce compatibilità con tutte le librerie basate sul modello dei bean Java fornisce API per l introspezione, ovvero l estrazione dei metadati dei bean (quali proprietà sono definite, di che tipo,...) 21

22 Esempio: classe bean per i prodotti Un oggetto della classe Product rappresenta un prodotto Definiamo una proprietà id di tipo int per il numero identificativo (chiave primaria nel DB), una name di tipo String per il nome del prodotto e varie altre (vedi codice completo nel progetto) Per memorizzare i valori delle proprietà, si usano dei campi privati (non accessibili dall esterno della classe) public class Product { } // campi privati con valori proprietà private int id; private String name; private String description; campi per altre proprietà... // costruttore pubblico senza argomenti public Product() {} // getter e setter per la proprietà id public int getid() { return id; // leggo valore dal campo } public void setid( int newid ) { id = newid; // aggiorno il campo } altri getter e setter... 22

23 Accesso al database: DAO Il resto dell applicazione delega l accesso al database ad un oggetto specifico, detto Data Access Object (DAO) L uso del DAO serve ad astrarre l accesso al database Un interfaccia è definita con le operazioni possibili di lettura e scrittura Possono esistere diverse implementazioni di questa interfaccia I controller ottengono un DAO e lo usano in modo indipendente dall implementazione specifica Nel progetto è definita l interfaccia GeneralDAO, di cui è già fornita un implementazione basata su JDBC Il DAO è una soluzione semplice per l object-relational mapping (ORM), che sarà oggetto di una prossima lezione 23

24 Esempi di metodi dell interfaccia DAO /** Interfaccia unica per tutti gli oggetti del Model. Questa interfaccia usa il package model poiché i metodi elencati hanno come output e input oggetti del package model */ public interface GeneralDAO { /** Restituisce il prodotto con ID dato. */ public Product getproduct( int id ); /** Restituisce l utente con nome dato. */ public User getuserbyname( String name ); /** Ottiene la lista di categorie di primo livello. */ public List<Category> gettoplevelcategories(); /** Registra un ordine nel database, restituendone l ID. */ public int insertinvoice( Invoice invoice ); } e altri metodi del genere... 24

25 Controller In un applicazione MVC, i controller ne contengono la business logic, l insieme delle operazioni che può compiere Le classi controller sono dipendenti dalle classi model, in quanto ne utilizzano gli oggetti (li creano, li restituiscono,...) Nel caso di un applicazione Web, la parte controller definisce quali richieste sono accettate dai client e come rispondere Nel seguito, distingueremo due tipi di richieste con richieste di sola lettura si ottengono informazioni dall applicazione senza alterarne lo stato (es. richiesta della pagina di un prodotto) con altre richieste, se accettate dall applicazione, si cambia lo stato dell applicazione stessa e/o del database sottostante (es. salvataggio di una recensione, che apparirà nella pagina del prodotto relativo) 25

26 Servlet Una servlet è in generale un oggetto Java di tipo Servlet che accetta richieste e genera risposte ad esse Si usa per implementare le funzionalità di un applicazione web, costituendone un controller Java EE definisce l interfaccia delle servlet e le loro interazioni con il servlet container (package javax.servlet) Le servlet sono inizializzate e finalizzate dal servlet container contestualmente all applicazione che le contiene Tramite la configurazione dell applicazione, si indica quali servlet devono rispondere a ciascuna possibile richiesta Per ciascuna richiesta, alla servlet sono forniti due oggetti ServletRequest: fornisce tutte le informazioni sulla richiesta ServletResponse: permette di definire la risposta da inviare 26

27 Servlet HTTP Le servlet generiche astraggono il mezzo attraverso cui richieste e risposte sono scambiate Le HttpServlet sono servlet che gestiscono nello specifico richieste e risposte in HTTP, usate nelle applicazioni Web Queste servlet forniscono funzionalità specifiche di HTTP, ad es. la gestione delle sessioni (che vedremo in seguito) La risposta data da una servlet può dipendere dal metodo HTTP usato nella richiesta, per il quale vediamo due possibilità GET è il metodo più comune, usato per ottenere dati senza causare alcun side effect (variazione dello stato) richieste di sola lettura POST richiede al server di immagazzinare dei dati forniti nel corpo della richiesta operazioni di scrittura che modidficano lo stato 27

28 View In un applicazione MVC, le parti di view sono quelle che realizzano l interfaccia grafica presentata all utente La view visualizza informazioni contenute in oggetti definiti nel model e generalmente forniti dal controller In un applicazione Web, l interfaccia è costituita da pagine Web, spesso generate dinamicamente dal server Le pagine usano lo standard WWW consortium (W3C): HTML, CSS, JavaScript L approccio tipico consiste nello scrivere modelli di pagine (template), che definiscono la struttura delle pagine generate e contengono dei segnaposto dove inserire i dati del model Per scrivere i modelli di pagine ci basiamo su JSP, parte di Java EE e supportato dai servlet container 28

29 JavaServer Pages (JSP) JSP è una tecnologia per sviluppare pagine Web dinamiche elaborate lato server Un file JSP può contenere un mix di codice eseguibile (di solito Java) e contenuto statico (di solito HTML) Dei delimitatori (es. <%... %> ) separano il codice dal contenuto Sono definiti azioni e tag speciali per funzionalità di uso comune Un apposito compilatore converte i file JSP in servlet La compilazione avviene una sola volta per ogni modifica del file JSP Ad ogni richiesta, la servlet esegue le parti di codice della pagina e restituisce il contenuto in output nella risposta L uso di Java in JSP è deprecato perché non favorisce la separazione tra contenuto e logica dell applicazione 29

30 Modelli di Pagine Web in JSP Dopo le prime versioni, a JSP sono state aggiunte nuove specifiche per evitare l'uso diretto di codice Java Expression Language (EL) definisce una semplice sintassi per integrare risultati di espressioni nella pagina JSP Standard Tag Library (JSTL) è un insieme di tag che forniscono funzionalità solitamente implementate in Java Contiene ad es. tag per il controllo del flusso che selezionano ed iterano parti di contenuto, sostituendo costrutti come if e for Nell applicazione abbiamo usato questi standard per definire i modelli delle pagine Web mostrate all utente Ogni pagina ricevuta dai client della nostra webapp è una combinazione tra un modello di pagina JSP (view) e i dati forniti da un controller 30

31 Gestione delle richieste di lettura In genere la maggioranza delle richieste dei client sono per pagine che mostrano i dati dell applicazione senza modificarli Le richieste di sola lettura utilizzano il metodo HTTP GET usato dal browser quando si clicca su un link o si digita un URL Queste richieste sono gestite in due passaggi distinti: una servlet ottiene gli oggetti (bean) che rappresentano i dati d interesse, di solito reperendoli dal database attraverso il DAO il controllo è quindi ceduto tramite forwarding ad una pagina JSP, che mostra i dati reperiti dal controller in una pagina HTML il forward è interno alla webapp accesso a risorse private (WEB-INF) Ci sono quindi due componenti con responsabilità separate la servlet (controller) recupera i dati, non influisce sulla visualizzazione JSP (view) mostra i dati in modo user-friendly senza usare codice Java 31

32 Gestione delle richieste di scrittura Altre richieste dai client comportano esplicitamente (salvo errori) dei side effect sull applicazione modifica dei dati nel database (es. registrazione di un nuovo ordine) modifica dello stato della sessione (es. aggiunta di prodotto al carrello) Queste richieste usano il metodo HTTP POST Anche queste richieste sono gestite in due passaggi: un controller esegue le azioni richieste, manipolando oggetti del model e interagendo col DAO (es. aggiunta di prodotto al carrello) il client è poi reindirizzato (redirect) ad una delle pagine di sola lettura al contrario del forwarding, il redirect è una risposta inviata al client che comporta l esecuzione di una nuova richiesta così l utente ottiene una pagina dove sono visibili i risultati dell azione e può aggiornarla senza rieseguire l azione (es. pagina di conferma di prodotto inserito nel carrello) 32

33 Schema delle interazioni nell applicazione applicazione client JSP HTML (view) forward Servlet lettura (controller) Oggeti modello dati (model) new, get, set Servlet scrittura (controller) Accesso ai dati (DAO) database 33

34 Implementazione di una Servlet HTTP Una servlet HTTP deve estendere la classe HttpServlet Va implementato il metodo doxxx a seconda del metodo HTTP supportato (nei nostri casi doget o dopost) doget per le servlet di sola lettura dopost per le servlet che alterano i dati e/o lo stato della sessione Entrambi questi metodi hanno per parametri una HttpServletRequest (la richiesta) una HttpServletResponse (la risposta da inviare) public class MyServlet extends HttpServlet { // gestione specifica per il metodo GET public void doget( HttpServletRequest request, HttpServletResponse response ) {... } } 34

35 Mapping di una Servlet ad un Percorso La configurazione dell applicazione deve indicare quali servlet sono definite ed a quali richieste deve rispondere ciascuna Ad ogni servlet si associa un percorso (servlet path), che insieme al context path dell applicazione ne determina l URL È possibile configurare le servlet nel descriptor web.xml <servlet> dichiara una classe servlet e gli associa un nome <servlet-mapping> associa una servlet ad un percorso Per maggiore comodità, possiamo dichiarare una servlet e specificarne il path annotando la classe Il container scansiona in automatico le annotazioni di tutte le "/mypage" ) public class MyServlet extends HttpServlet {... } 35

36 Servlet: parametri della richiesta Ciascuna richiesta HTTP può contenere dei parametri Nel caso di richiesta GET, i parametri sono accodati all URL es.: Nel caso di POST, i parametri si trovano nel corpo della richiesta Quando si conferma (submit) un form HTML, viene inviata una richiesta GET o POST che ha per parametri i dati immessi nel form La servlet accede ai parametri di ciascuna richiesta col metodo getparameter di HttpServletRequest String id = request.getparameter( "id" ); I valori dei parametri sono restituiti in forma di stringa: vanno convertiti in numeri o altri tipi dove necessario es.: int id = Integer.parseInt( request.getparameter( "id" ) ); 36

37 Servlet: output Le servlet possono eseguire il forwarding ad una risorsa, ovvero il trasferimento del controllo della richiesta request.getrequestdispatcher( percorso ).forward( request, response ); La risorsa va specificata in forma di percorso Può essere una servlet o una risorsa nella cartella webapp, sono accessibili in questo caso anche i file privati nella cartella WEB-INF Si possono passare dati alla servlet di destinazione, impostandoli come attributi della richiesta request.setattribute( "user", currentuser ) Come destinazione usiamo una pagina JSP, che avrà accesso agli attributi per costruire la pagina risultante 37

38 Servlet: redirezioni ed errori La servlet può inviare come risposta una redirezione, a cui il client reagisce inviando un altra richiesta ad un URL dato response.sendredirect( url ); Usiamo questo nei controller di scrittura (POST) per redirezionare il browser ad uno di lettura che visualizzi i risultati La servlet può inviare un errore nel caso sia impossibilitata a soddisfare la richiesta response.senderror( codice, messaggio ); Se non è l ultima istruzione del metodo, va seguita da return I possibili codici sono definiti come costanti in HttpServletResponse (ad es. SC_NOT_FOUND = 404) Il servlet container genera automaticamente una pagina d errore sia in questo caso che nel caso in cui la servlet generi un eccezione 38

39 Esempio: servlet per la ricerca di prodotti (SearchServlet) // indico il servlet path, che determina l URL a cui è accessibile la "/search" ) public class SearchServlet extends HttpServlet { // implemento il metodo doget per gestire richieste HTTP GET public void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { input // reperisco il valore del parametro q : la stringa da cercare String query = request.getparameter( "q" ); // ottengo il DAO per l accesso al database GeneralDAO dao = DataAccess.getGeneralDAO( request ); elaborazione // eseguo l interrogazione sul databse List<Product> results = dao.searchproducts( query ); // imposto i dati da visualizzare sulla pagina come attributi della richiesta output } } request.setattribute( "query", query ); request.setattribute( "results", results ); // eseguo il forwarding alla pagina JSP che mostra i risultati request.getrequestdispatcher( "/WEB-INF/view/SearchResults.jsp" ).forward( request, response ); Oggetti passati alla view (vedi dopo) URL base applicazione (server+contesto) servlet parametri esempio URL : 39

40 Pagine JSP view Le pagine JSP view costituiscono l interfaccia grafica dell applicazione vista dall utente sul browser La view riguarda solamente la visualizzazione all utente dei dati: non contiene codice per elaborarli o reperirli dal DB Nel progetto dato non possono essere oggetto di una richiesta esterna, in quanto sono tra le risorse private (WEB-INF) Sono invece richiamate per forward dalle servlet controller, che forniscono i dati che devono visualizzare Sono costituite principalmente da HTML, con integrati costrutti JSP per inserire e formattare correttamente i dati I file JSP della webapp contengono solo la parte centrale della pagina, senza intestazione: vedremo in seguito come è aggiunta in automatico 40

41 JSP: sintassi ed elementi di base Tutto il contenuto di un file JSP, eccetto tag ed elementi speciali, è statico ed restituito così com è ai client Si possono inserire commenti con: <%-- commento --%> I commenti JSP non appaiono nella pagina risultante e nemmeno nel relativo sorgente (al contrario di commenti HTML <!-- -->) Le direttive si scrivono con <%@ nome parametri %> e danno istruzioni specifiche al compilatore JSP es.: <%@ page contenttype="text/html" pageencoding="utf-8" %> informazioni sulla pagina contenuto: HTML codifica caratteri: UTF-8 (Unicode) Non useremo elementi per includere codice eseguibile <% %> scriptlet (parti di codice da eseguire) <%! %> dichiarazioni di variabili o metodi <%= %> espressioni il cui risultato è riportato in output 41

42 JSP: Expression Language Le espressioni EL sono usate all interno di una pagina JSP per estrarre informazioni da oggetti Java accessibili da essa attributi della richiesta o della sessione, oggetti impliciti JSP, Un espressione EL si scrive nella forma ${espressione} Si può accedere alle proprietà dei bean: ${bean.proprietà} Sono disponibili operatori tipici, espressi a simboli e/o parole chiave Non si può scrivere codice Java (ma gli operatori sono simili) Le espressioni EL si possono utilizzare in mezzo al contenuto statico, per riportare dati nella pagina risultante all interno di tag della JSP Standard Tag Library (JSTL), ad es. per esprimere condizioni (vediamo dopo) Tramite EL accediamo agli attributi della richiesta, impostati dalla servlet che ha ceduto il controllo alla pagina 42

43 Esempi di espressioni EL ${item.name} valore della proprietà name o ${item["name"]} dell oggetto bean item equivalente a item.getname() in Java es. per ottenere proprietà innestate: ${item.category.name} ${x[0]} 1 elemento dell array o lista x ${x+y} somma di x e y altri operatori aritmetici: -, *, / div, % mod ${x>y} o ${x gt y} true se x è maggiore di y altri operatori di confronto: == eq,!= ne, < lt, <= le, >= ge ${x&&y} o ${x and y} true se sia x che y lo sono altri operatori logici: or,! not ${empty x} true se x è null oppure se è una stringa, lista o array vuoto 43

44 JSP Standard Tag Library JSTL è una collezione di tag utilizzabili in JSP che forniscono funzionalità ricorrenti, altrimenti realizzate con codice Java si possono anche creare tag personalizzati per uso interno alla webapp In particolare, utilizziamo i tag per il controllo del flusso della pagina e per il formato di stampa dei dati I tag JSTL sono divisi funzionalmente in librerie core contiene i tag principali, tra cui quelli per il controllo del flusso Ogni libreria usata in un file JSP va dichiarata indicando l URI (uniform resource identifier) ed un prefisso per riferirsi ad essa <%@ taglib prefix="c" uri=" %> In seguito si possono usare i tag indicandone prefisso e nome <c:if parametri> contenuto </c:if> 44

45 JSTL: controllo del flusso Il tag if incapsula un contenuto che viene riportato in output solo se la condizione data (espressa in EL) è soddisfatta <c:if test="${condizione}"> contenuto </c:if> choose, when, otherwise selezionano uno di più blocchi <c:choose> <c:when test="${cond1}">...</c:when> (uno o più when) <c:otherwise>... </c:otherwise> (facoltativo) </c:choose> foreach ripete il contenuto per ogni elemento di una collezione (es. List), accessibile in EL all interno del tag <c:foreach items="${collezione}" var="elem"> <p>the list contains ${elem}.</p> </c:foreach> 45

46 JSTL: formattazione La libreria fmt contiene funzioni utili per formattare in modo leggibile valori di diversi tipi (numeri, date ecc.) taglib prefix="fmt" uri=" %> formatnumber formatta un numero ad es. per stampare un prezzo espresso in euro 14,99: <fmt:formatnumber value="${product.price}" type="currency" currencysymbol=" " /> formatdate formatta una data ad es. per stampare una data per esteso ( 4 marzo 2016 ): <fmt:formatdate value="${invoice.date.time}" type="date" datestyle="long" /> (.time converte da Calendar a Date) 46

47 JSTL: altre funzioni La libreria functions contiene un assortimento di funzioni utilizzabili in EL, in particolare per la manipolazione di stringhe taglib prefix="fn" uri=" %> La funzione length restituisce il numero di caratteri di una stringa o di elementi in una collezione <p>there are ${fn:length(reviews)} reviews.</p> La funzione escapexml converte i caratteri speciali di HTML/XML in corrispondenti sequenze di escape Importante per evitare che i testi (in particolare quelli scritti dagli utenti) siano interpretati come codice HTML o JavaScript <p>${fn:escapexml(review.text)}</p> es.: List<Product> List<Product> Altre funzioni: touppercase, tolowercase, trim,... 47

48 Esempio: pagina JSP con i risultati della ricerca (SearchResults.jsp) <%-- importo le librerie core e functions di JSTL --%> <@% taglib prefix="c" uri=" %> <@% taglib prefix="fn" uri=" %> <%-- riporto nell intestazione la stringa cercata --%> <h1>search results for ${fn:escapexml(query)}</h1> <c:choose> <%-- se sono stati trovati uno o più prodotti... --%> <c:when test="${not empty results}"> <%--... riporto i link uno per uno in un elenco puntato... --%> <ul> <c:foreach items="${results}" var="item"> <li><a href="item?id=${item.id}">${item.name}</a></li> </c:foreach> </ul> </c:when> <%--... altrimenti indico che non è stato trovato alcun prodotto --%> <c:otherwise><p>no results!</p></c:otherwise> </c:choose> HTML JSP JSTL EL Le variabili query e results sono passate come attributi della richiesta dalla SearchServlet vista in precedenza 48

49 Accesso al DB: Pooling delle Connessioni L accesso al database si gestisce tramite le API JDBC, ma diversamente dalle applicazioni desktop (utente singolo) Per non lasciare connessioni aperte, ad ogni richiesta di una pagina si dovrebbe aprire, usare e chiudere una connessione Aprire una connessione è però costoso in termini di tempo soluzione: riutilizzare connessioni esistenti in più richieste Il server può gestire un pool di connessioni allo stesso database da riutilizzare Ad ogni accesso al database, il server fornisce all applicazione una connessione già stabilita (o la apre sul momento se necessario) Chiudendo la connessione (metodo close), questa viene in realtà restituita al pool per poter essere riutilizzata 49

50 Sorgenti dati La classe DataSource (package javax.sql) rappresenta il concetto generale di sorgente dati in forma relazionale Comunemente (come nel nostro caso), la sorgente è un database con riferimenti definiti per la connessione indirizzo, autenticazione, nome del database uso: Connection conn = datasource.getconnection() Data una sorgente dati, Tomcat può essere configurato per gestire un pool di connessioni ad essa Il pool di connessioni è visto a sua volta come sorgente dati il codice dell applicazione rimane lo stesso Ogni sorgente dati ha un nome, che si usa nell applicazione per riferirsi ad essa ed ottenere una connessione dal pool 50

51 Tomcat: Configurazione Pool di Connessioni Un pool va dichiarato come risorsa nel file context.xml Tomcat lo renderà disponibile all interno dell applicazione <?xml version="1.0" encoding="utf-8"?> <Context path="/estore"> <Resource /> </Context> name="psqlpool" auth="container" type="javax.sql.datasource" driverclassname="org.postgresql.driver" url="jdbc:postgresql://localhost/dia" username="dia" password="123" maxactive="100" maxidle="30" maxwait="10000" num. massimo di connessioni attive num. massimo di connessioni inattive Nome del pool di connessioni, usato per riferirsi ad esso Tipo di risorsa (specifica che si tratta di una sorgente dati) Parametri per la connessione (driver JDBC, URL e autenticazione) max attesa in ms per restituire una connessione 51

52 Accesso alle Risorse dall Applicazione Un riferimento alla risorsa va dichiarato nel file web.xml <resource-ref> <res-ref-name>psqlpool</res-ref-name> <res-type>javax.sql.datasource</res-type> <res-auth>container</res-auth> </resource-ref> In seguito, è possibile ottenere la risorsa dal suo nome usando l API JNDI (Java Naming and Directory Interface) // 1) ottengo il contesto dell applicazione InitialContext initctx = new InitialContext(); Context ctx = (Context) initctx.lookup( "java:comp/env" ); // 2) dal contesto ottengo la sorgente dato il nome DataSource ds = (DataSource) ctx.lookup("psqlpool"); 52

53 Gestione delle connessioni Un applicazione web può gestire più richeste alla volta Ogni richiesta necessita di una connessione al database E importante accertarsi che ciascuna connessione sia utilizzata da una sola richiesta alla volta alla fine della richiesta, la connessione venga chiusa (restituita al pool) Per associare una singola connessione per richiesta, si può salvare la connessione in un attributo della richiesta Per garantire in automatico la corretta gestione delle connessioni in ogni richiesta, è possibile applicare un filtro apposito a tutte le servlet 53

54 Filtri Servlet Un filtro è un oggetto Filter che intercetta l invocazione di una servlet, modificando la richiesta e/o la risposta Per ciascun filtro dichiarato nell applicazione è possibile stabilire su quali URL deve essere attivato I filtri attivi per una richiesta formano una catena costruita e invocata dal servlet container che si chiude con la servlet I filtri possono essere usati per implementare operazioni che devono essere eseguite sistematicamente su diverse richieste Vedremo ad es. come usarli per gestire le connessioni ad ogni richiesta Container Filtro Filtro Servlet 54

55 Implementazione di un filtro servlet Un filtro servlet va implementato in una classe Filter Il metodo dofilter è eseguito ad ogni richiesta filtrata Il metodo è invocato dal container o dal filtro precedente della catena Per cedere il controllo all elemento successivo (servlet o altro filtro), va invocato il metodo dofilter sull oggetto FilterChain dato Prima e/o dopo si può intervenire sulla richiesta e/o sulla risposta, ad esempio impostando attributi utilizzabili negli elementi successivi Il metodo init è invocato dal container una sola volta per inizializzare il filtro, di solito all avvio dell applicazione Utilizzabile per inizializzare risorse usate poi dal filtro in ogni richiesta Analogamente, il metodo destroy è invocato una sola volta per disattivare il filtro, in genere all arresto dell applicazione Utilizzabile per rilasciare le risorse inizializzate in init 55

56 container servlet Applicazioni Web Codice: filtro servlet per gestire la connessione JDBC al database public class JDBCRequestFilter implements Filter { private DataSource connectionpool; All inizializzazione del filtro, ottengo il riferimento al pool di connessioni tramite JNDI public void init( FilterConfig config ) throws ServletException { try { Context context = (Context) new InitialContext().lookup( "java:comp/env" ); connectionpool = (DataSource) context.lookup( "psqlpool" ); } catch ( NamingException ex ) { throw new ServletException( ex ); } } } public void dofilter( ServletRequest request, ServletResponse response, FilterChain chain ) throws IOException, ServletException { try ( Connection conn = connectionpool.getconnection() ) { // auto-chiusura conn.setautocommit( false ); JDBCGeneralDAO dao = new JDBCGeneralDAO( conn ); request.setattribute( DataAccess.ATTR_DAO, dao ); chain.dofilter( request, response ); } } catch ( SQLException ex ) { throw new ServletException( "error opening JDBC connection", ex ); } Ad ogni richiesta utilizzo una connessione del pool, la incapsulo in un DAO e la rilascio dopo che la richiesta è stata servita 56

57 Configurazione del filtro servlet per gestione connessioni JDBC I filtri usati e le associazioni alle servlet si dichiarano in web.xml Si potrebbe usare l ma non si avrebbe controllo sull ordine dei filtri nella catena Ogni classe filtro va dichiarata in un tag filter con un nome <filter> <filter-name>jdbccontroller</filter-name> <filter-class>it..jdbc.jdbcrequestfilter</filter-class> </filter> Usando i nomi, i filtri vanno associati ai percorsi delle servlet su cui applicarli usando tag filter-mapping ( * = qualsiasi percorso) L ordine delle dichiarazioni determina l ordine di applicazione <filter-mapping> <filter-name>jdbccontroller</filter-name> <url-pattern>*</url-pattern> </filter-mapping> 57

58 Sessioni HTTP Come anticipato, il protocollo HTTP è stateless: ogni richiesta è gestita a se e la risposta ad essa è indipendente dalle altre La webapp deve però tenere traccia dell attività di un utente Dopo che l utente si è autenticato, il server deve ricordare la sua identità e decidere di conseguenza quali azioni gli sono consentite Per eseguire un ordine, un utente deve poter inserire articoli in un carrello virtuale e il server deve memorizzarne il contenuto Il server può tenere traccia delle sessioni HTTP: ciascuna è una sequenza di richieste e risposte con lo stesso client Il servlet container gestisce il mantenimento delle sessioni con i client Ciascun client può essere identificato ad es. usando i cookie HTTP Ad ogni sessione possono essere associati dei dati 58

59 Gestione delle sessioni HTTP Una sessione è rappresentata da un oggetto HttpSession Durante la gestione di una HttpServletRequest, si può ottenere la sessione corrente col metodo getsession La sessione viene creata e inizializzata automaticamente se necessario In ogni sessione possono essere salvati degli oggetti, che persistono attraverso molteplici richieste nella stessa sessione setattribute salva con nome un oggetto nella sessione getattribute reperisce un oggetto dalla sessione dato il suo nome Una sessione può scadere, comportando la perdita degli oggetti salvati in essa e il rilascio di risorse da parte del server manualmente, invocando il metodo invalidate in automatico, dopo un periodo di inattività (impostabile in web.xml) 59

60 Gestore delle sessioni Per facilitare la gestione dei dati di sessione, utilizziamo nella webapp un apposito oggetto SessionManager Questo oggetto fornisce metodi di alto livello per gestire i dati Astrae la Servlet API e i nomi assegnati agli oggetti È in pratica un DAO per gli oggetti di sessione Nello specifico sono forniti metodi per verificare l identità dell utente autenticato: getcurrentuser dichiarare o invalidare l identità: loguserin, loguserout reperire o impostare il contenuto del carrello: getcart, setcart L implementazione è data in SessionManagerImpl Per ottenerne un istanza usiamo la classe Session passando la richiesta corrente SessionManager sm = getsessionmanager(request); 60

61 Autenticazione e Autorizzazione Nell arco di una sessione, vogliamo tenere traccia di quale utente registrato nel database stia usando il sito Tramite la LoginServlet (path /login ), l utente si può autenticare fornendo nome e password L utente col nome dato viene cercato nel database: se esiste e la password corrisponde, viene impostato come utente corrente Per semplicità ignoriamo aspetti di sicurezza, es. uso di funzioni hash L header delle pagine cambia se un utente si è autenticato Le servlet che trattano dati di uno specifico utente (ordini e recensioni) rifiutano la richiesta se l utente non è autenticato La LogoutServlet (path /logout ) imposta l utente corrente a null, annullando l autenticazione 61

62 Header e footer delle pagine Abbiamo visto che i file JSP dell applicazione contengono solo il codice HTML relativo al contenuto principale di ogni pagina Non sono presenti la struttura dei documenti HTML (tag <html>, <head>,...) e l header della pagina col form di autenticazione o i contenuti per l utente connesso Le parti iniziali e finali da applicare a tutte le pagine restituite dal server sono definite in file JSPF (JSP Fragment) I file sono contenuti in webapp/web-inf/jspf (privati) header.jspf è inserito in testa ad ogni pagina JSP apre <html>, contiene <head>, apre <body> e contiene l header footer.jspf è inserito in coda ad ogni pagina JSP contiene il piè di pagina e chiude i tag <body> e <html> 62

63 Applicazione di header e footer alle pagine L applicazione di header e footer alle pagine JSP va dichiarata nel file web.xml definendo un gruppo di pagine JSP <web-app...>... <jsp-config> <jsp-property-group> <!-- assegno un nome al gruppo di pagine --> <display-name>view</display-name> <!-- indico le pagine incluse nel gruppo --> <url-pattern>/web-inf/view/*</url-pattern> <!-- impedisco l uso di scriptlet (Java) nelle pagine --> <scripting-invalid>true</scripting-invalid> <!-- indico il file da includere in testa ad ogni pagina --> <include-prelude>/web-inf/jspf/header.jspf</include-prelude> <!-- indico il file da includere in coda ad ogni pagina --> <include-coda>/web-inf/jspf/footer.jspf</include-coda> </jsp-property-group> </jsp-config> 63

64 Filtro servlet di supporto all header Per visualizzare nell header delle pagine il nome dell utente connesso, abbiamo bisogno che questo sia accessibile con EL L utente corrente va però reperito dal SessionManager Utilizziamo un filtro servlet HeaderInfoRequestFilter che renda disponibile questa informazione in header.jspf come attributo della richiesta Il filtro va applicato dopo JDBCRequestFilter, in modo che possa accedere alle informazioni dell utente dal database Il file web.xml è configurato per applicare i due filtri in ordine corretto l ordine dei tag filter-mapping è rilevante 64

65 HTTPS Di default usiamo l applicazione tramite il protocollo HTTP: le informazioni transitano in chiaro attraverso la rete Ciò non è idoneo per la trasmissione di dati sensibili, quali ad esempio le credenziali di autenticazione, carte di credito ecc. Il protocollo HTTPS consiste nell incapsulamento di HTTP in una connessione cifrata tramite i protocolli SSL/TLS SSL = Secure Sockets Layer, TLS = Transport Layer Security Garantisce privacy e integrità: solo il server può leggere i dati e solo il client specifico può averli generati (o viceversa) Il server dichiara la sua identità tramite un certificato che ne garantisce l identità e indica la chiave pubblica di cifratura Il certificato è di norma firmato da una Certification Authority che ne garantisce l autenticità 65

66 Utilizzo di HTTPS Tomcat (come altri container) normalmente utilizza un connettore (porta server) HTTP per comunicare con i client È possibile abilitare (anche) un connettore HTTPS, che può servire le stesse pagine ma usando connessioni sicure (cifrate) Questo richiede di fornire al server un certificato ed una relativa coppia di chiavi di cifratura: possono essere generati con appositi tool Una webapp ha controllo sul tipo di connessione utilizzata Le servlet possono verificare se la connessione usata è sicura tramite il metodo issecure di ServletRequest La webapp può essere configurata in modo da obbligare l uso di connessioni sicure per alcune o per tutte le richieste In laboratorio vedremo come abilitare il supporto ad HTTPS in Tomcat ed impostare che la webapp ne imponga l uso 66

67 Carrello della spesa Per poter eseguire ordini con più prodotti, è opportuno tenere traccia di una lista di prodotti durante la navigazione E prassi nei siti di e-commerce mantenere un carrello virtuale I prodotti possono essere aggiunti al carrello in determinate quantità Una pagina mostra il contenuto del carrello e permette di modificarlo Se il carrello non è vuoto, col checkout si può confermare l ordine dei prodotti attualmente nel carrello (che viene svuotato) Nella parte finale dell esercitazione di laboratorio, vediamo come implementare la gestione di un carrello della spesa modellazione del contenuto del carrello implementazione della logica per le richieste di modifica del contenuto (aggiunta e rimozione di prodotti) e per il checkout aggiunta/modifica di pagine per la visione e gestione del carrello 67