Corso di Laboratorio Applicazioni Internet

Transcript

1 i Corso di Laboratorio Applicazioni

2 ii Copyright Dip. Informatica - Università di Pisa

3 iii COLLABORATORI TITOLO : Corso di Laboratorio Applicazioni AZIONE NOME DATA FIRMA A CURA DI Tito Flagella e Lorenzo Nardi 10 marzo 2011 CRONOLOGIA DELLE REVISIONI POSIZIONE DATA DESCRIZIONE NOME

4 iv Indice 1 Architetture Applicative Introduzione I Web Services e le Architetture Orientate ai Servizi L infrastruttura software per l erogazione di Servizi Il Protocollo HTTP e la programmazione di Servlet HTTP Tools http Richiesta HTTP Risposta HTTP Codifica dei parametri Eseguire query HTTP con JAVA Web/Application Server Introduzione alla programmazione di Servlet Ciclo di vita di una Servlet Implementare HttpServlet Deploy della Servlet Sessioni Problematiche nella gestione delle sessioni - Caso Alitalia Sessioni in Java Introduzione all XML XML Sintassi XML Strutturare i dati Namespace XML in Java, DOM Java API for XML Processing DOM Parser SAX Parser StAX Parser XSD Costruzione di uno Schema XML Validazione con JAXP Applicazioni XML su HTTP

5 v 4 Web Service SOAP WSDL Types Messages Binding Services WSDL Validation Web Service in Java Approccio centrato su classi Java Uso di WSDL2Java Uso di Java2WSDL Approccio centrato su messaggi SOAP Message Level Service SAAJ Client Sicurezza nelle applicazioni WEB Minacce per la sicurezza nelle comunicazioni Web Services Security Requirements Public Key Infrastructure Setup con Keytool WS-Security Authentication Signature Encryption TimeStamp WS-Security con CXF Autentication con Username Token Signature Encryption Timestamp Timestamp Signature Encrypt Le specifiche WS-* Gestione delle Transazioni in un Database Gestione del Backend JDBC e Gestione Backend con Java SQL Injection Le Transazioni

6 vi 6.4 Transazioni concorrenti Lost Update Dirty Read Unrepeatable Read Phantom Row Lock Lost Update Unrepeatable Read Phantom Row SELECT... FOR UPDATE Livelli di isolamento READ COMMITTED e SERIALIZABLE Livello di isolamento Serializable vs Serializzazione Matematica Lost Update Unrepeatable Read Phantom Row Transazioni Distribuite Two Phase Commit (2PC)

7 vii Elenco delle tabelle 1 Header HTTP di richiesta Header HTTP piu frequenti Codifica di caratteri speciali Parser Message Exchange Pattern Esempio Lost Update Esempio Dirty Read Esempio Unrepeatable Read Esempio Phantom Row Implementazioni dei lock per i database più diffusi Esempio Lost Update con lock share Esempio Lost Update con lock exclusive Esempio Unrepeatable Read con lock share Esempio Phantom Row Livelli di isolamento e le anomale dovute ad accesso concorrente ai dati Livello di isolamento Serializable vs Serializzazione Esempio Lost Update con Read Committed Esempio Lost Update con Serializable

8 1 / 74 1 Architetture Applicative 1.1 Introduzione La rapida diffusione di ha provocato una vera e propria rivoluzione nelle architetture delle applicazioni distribuite, aumentando significativamente la complessità dei sistemi in gioco. E sicuramente interessante, prima di approfondire gli aspetti architetturali tipici di una applicazione, ripercorrere rapidamente l evoluzione delle architetture dei sistemi distribuiti negli ultimi anni. Inizialmente, quelle che oggi chiamiamo Applicazioni Enterprise (come ad esempio i sistemi di prenotazione, o il software di gestione degli ATM) non erano realizzati come oggi in maniera distribuita ma erano invece applicazioni monolitiche ospitate da un Mainframe. L interazione da pate degli utenti (o meglio degli operatori) avveniva da terminali, tipicamente i 3270 a fosfori verde sempre piu difficili da trovare in circolazione, connessi al Mainframe via cavi coassiali. I terminali non avevano alcuna capacità di elaborazione locale dei dati e si limitavano a trasmettere al mainframe i dati digitati dall utente e a visualizzare sul display i caratteri ricevuti dal mainframe. A quei tempi la scalabilità di un applicazione, cioè la sua capacità di incrementare nel tempo la propria capacità di risposta in funzione delle necessità e delle disponibilità di risorse, era quindi unicamente di tipo verticale, basata cioè sulla capacità di incrementare la potenza di calcolo del mainframe.

9 2 / 74 Un primo cambiamento radicale si ebbe con la diffusione, avvenuta nel corso degli anni 80, di due tecnologie ancora oggi estremamente diffuse: i database relazionali e i personal computer. I personal computer offrivano sia potenza di calcolo a basso costo che i primi tool per lo sviluppo di interfacce grafiche. I Data Base Management System (DBMS) d altro canto offrivano uno strumento affidabile ed a basso costo per la gestione delle transazioni applicative. Si diffonde così un nuovo paradigma applicativo, solitamente riferito come client-server, basato proprio sull uso coordinato di queste due tecnologie: il client, detto anche Fat Client a causa delle sue dimensioni spesso eccessive, include l interfaccia utente (presentation logic), la logica applicativa del programma (business logic) e la logica di elaborazione dei dati (data manipulation logic); il DBMS si limita inizialmente a gestire la manipolazione dei dati in maniera transazionale. Il nuovo paradigma si diffonde con una straordinaria rapidità, grazie alla sua caratteristica di sfruttare il parallelismo nel più semplice dei modi, distribuendo cioè l esecuzione della maggior parte del carico sui PC degli stessi utenti. La semplicità dell architettura client-server, che ne ha costituito il principale punto di forza, mostra però nel tempo alcuni limiti importanti. In particolare: l uso di un Fat Client richiede un upgrade del client ad ogni modifica dell applicazione (nuove feature e/o bug-fix); se è vero, come abbiamo detto, che il client scala ottimamente sui PC utilizzati al crescere del numero di utenti, la stessa cosa non succede però per il DBMS, che tende a diventare un collo di bottiglia dell intera architettura. Per risolvere questo problema ci si comincia a muovere verso il concetto di quello che oggi viene chiamato Application Server. Si tratta sostanzialmente di spostare parte della logica applicativa dal client al server. I vendor piu importanti si muovono quindi in due direzioni: I produttori di DBMS cominciano ad aggiungere funzionalità applicative nei loro prodotti, nella forma di trigger e stored procedure. I produttori dei TP Monitor, i framework applicativi (come li chiameremmo oggi) che dominavano il mercato Mainframe, colgono l opportunita per portare i loro software su sistema Unix, avviando il processo di downsizing da mainframe a un ambiente etorogeneo, che usa pesantemente minicomputer, reti LAN e personal computer.

10 3 / 74 Queste due strade si rilevano però pocò più che un palliativo. I DB server, che già costituivano un collo di bottiglia dell intera architettura, vedono aumentare il loro carico di lavoro. I TP Monitor, anche in ambiente Unix mantengono significative controindicazioni in termini di costi e complessità d uso. In questa fase intervengono altre due significative novità destinate ad influenzare l evoluzione delle architetture applicative: da una parte si sviluppa un attenzione crescente verso gli aspetti di portabilità, standardizzazione ed interoperabilità, poi scaturita nella definizione di Open Systems; si afferma decisamente il paradigma di programmazione ad oggetti e, di conseguenza, cominciano ad affermarsi tecnologie per la distribuzione degli oggetti in rete. Lo sforzo piu significativo per la costruzione di un sistema ad oggetti distribuito si sviluppa nell ambito dell OMG (Object Management Group), un organizzazione che raggruppa tutti i piu importanti player del mercato del software e che arriva a standardizzare l architettura software CORBA (Common Object Request Broker Architecture), un architettura ad oggetti distribuita, definita da OMG, come segue: a vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network. CORBA ha poi effettivamente ottenuto un ampio successo, diventando uno standard di fatto nel mondo Enterprise per la realizzazione di applicazioni multi-linguaggio e multi-piattaforma. E in questo contesto che esplode la novita della tecnologia, trainata dal travolgente successo del World Wide Web. La rete in effetti esisteva gia da tempo ma viene scossa dall invenzione del WWW, un nuovo paradigma progettato per la visualizzazione di testi ipermediali in rete, e basato sull uso del protocollo HTTP e dei Browser Web, utilizzati per la visualizzazione di pagine descritte tramite il linguaggio HTML. l architettura WWW prevede infati l uso del protocollo http per le comunicazioni tra il Browser ed il Web Server. Il Web Server serve direttamente al Browser le informazioni statiche, prelevandole dal proprio file system, ma puo anche utilizzare il protocollo CGI per richiedere ad applicazioni esterne di generare dinamicamente le informazioni (tipicamente pagine html ed immagini) da restituire al browser. A mano a mano che il Web si diffonde su, e che si comincia a costruire siti web dinamici, ci si rende conto che questo semplice modello architetturale avrebbe potuto essere utilizzato anche per la realizzazione di vere e proprie applicazioni distribuite.

11 4 / 74 I primi siti web dinamici utilizzavano infatti il brwoser non solo per visualizzare le pagine html, ma anche per raccogliere le preferenze dell utente, ad esempio per il login o per le selezioni della pagina, tramite l uso del costrutto FORM del linguaggio HTML. Il browser si dimostra cosi adatto a gestire il livello di presentazione, prima occupato dal Fat Client nell architettura client server. Dal punto di vista del backend, invece, questi siti cominciano ad accedere sempre piu intensamente a varie fonti informative (data base ed in generale sistemi legacy), tramite l uso di applicazioni CGI, per costruire le pagine html da restituire come risposta al Browser. Ne deriva un architettura applicativa nella quale: il browser si candida a diventare un Client Universale, con la sola funzione di gestire l interazione con l utenza; il web server si candida ad assumere la funzione di Application Server, mediando le interazioni tra il browser e gli ulteriori livelli di backend applicativo (DBMS e sistemi legacy); il protocollo http si candida a diventare lo standard di fatto per tutte le comunicazioni applicative veicolate tramite ; nel backend continuano a vivere sia i DBMS acceduti dalle estensioni Web tramite middleware basati sul linguaggio SQL (odbc, jdbc,...), sia le applicazioni legacy vere e proprie, piu (CORBA, RMI, DCOM) o meno (RPC, API proprietarie,...) recenti. Questa nuova architettura si afferma rapidamente, identificata inizialmente come Architettura a Tre Livelli (Three Tier Architecture). Successivamente, a mano a mano che si intesifica la disponibilita e l uso di Servizi, si evolve verso un architettura a piu livelli (Multi Tier Architecture), schematizzata nella figura successiva, che prevede sia interazioni verso il backend che verso servizi esterni disponibili anch essi tramite. 1.2 I Web Services e le Architetture Orientate ai Servizi La diffusione di si porta dietro tutto un fiorire di nuove tecnologie. Sostanzialmente si fa strada l idea che se la tecnologia si e dimostrata adatta a supportare lo straordinario successo del WEB, scalando su milioni di server e di utenti diversi, puo essere una tecnologia di successo anche per le applicazioni distribuite.

12 5 / 74 Nascono quindi tutta una serie di nuove proposte, che ruotano principalmente attorno all uso di XML per la rappresentazione dei dati di interscambio e l uso di http per il livello di trasporto fisico dei pacchetti xml. Nel loro insieme queste tecnologie vanno oggi sotto il nome di Web Services, e si differenziano in due proposte diverse. La prima, solitamente riferita semplicemente come Web Services e basata sull uso del protocollo SOAP, di cui parleremo estesamente piu avanti, per l imbustamento dei contenuti applicativi, e sulla definizione di numerosi e spesso eccessivamente complessi formati di header della busta SOAP, utilizzati per contenere le metainformazioni necessarie a vari servizi di infrastrura (sicurezza, indirizzamento, transazionalita, etc.). La seconda, solitamente riferita come Restful Web Services parte invece dalla convinzione che il protocollo http possa essere usato nativamente anche per realizzare applicazioni, senza bisogno dell ulteriore livello di imbustamento SOAP. In entrambe queste interpretazioni, i Web Services si stanno diffondendo moltissimo come tecnologia per la realizzazione delle Architetture Service Oriented (SOA), un paradigma di progettazione applicativa basato sul concetto di servizio, considerato da tempo il paradigma emergente nelle architetture applicative, e che ha finalmente trovato nei Web Services una adeguata tecnologia attuativa. 1.3 L infrastruttura software per l erogazione di Servizi Abbiamo visto nelle sezioni precedenti come le Applicazioni si presentino come un insieme di nodi applicativi (servizi), che interagiscono tra loro utilizzando la tecnologia dei Web Services. In questa sezione vogliamo cominciare ad analizzare il dettaglio di un singolo nodo applicativo che, da un punto di vista logico, puo essere schematizzato come nella figura successiva. Nella figura successiva mostriamo invece come i 3 livelli logici del singolo nodo applicativo vengano effettivamente realizzati in un reale progetto attuativo. Ogni livello e a sua volta composto da alcuni componenti software, che interagiscono tra loro come schematizzato nella figura che segue.

13 6 / 74 E facile immaginare come la progettazione, la realizzazione ed il tuning di un applicazione non possano non essere condizionati dalla complessita dell ambiente in cui queste stesse saranno poi ospitate e dalle interazioni che dovranno avere con componenti esterni. L obiettivo di questo corso e proprio quello di introdurre alle problematiche specifiche che un progettista, uno sviluppatore ed un sistemista applicativo dovranno imparare a fronteggiare, lavorando con questa tipologia sempre piu diffusa di applicazioni. 2 Il Protocollo HTTP e la programmazione di Servlet 2.1 HTTP HTTP è l acronimo di HyperText Transfer Protocol (protocollo di trasferimento di un ipertesto). Usato come principale sistema per la trasmissione di informazioni sul web. è il protocollo standard tramite il quale i server Web rispondono alle richieste dei client. Il protocollo HTTP è basato su un modello richiesta/risposta, quindi ad ogni messaggio di richiesta è associato un messaggio di risposta, anche vuoto. Per demistificare l idea che http sia un protocollo di comunicazione utilizzabile solo dai browser, è utile fare un po di pratica nell interazione con i server web, usando strumenti alternativi al browser Tools http Telnet è un protocollo client-server basato su TCP. è possibile utilizzare un programma Telnet per stabilire una connessione interattiva ad un qualunque servizio su un server internet. La sintassi per stabilire una connessione è telnet host port Con telnet possiamo collegarci ad un server http, costruire le nostre richieste HTTP, inviarle e leggere la risposta. Cominciamo effettuando il collegamento, specificando l host e la porta (la porta di default per i web server è la 80): telnet 80 Trying Connected to Escape character is ^]. Una volta stabilita una connessione al server http possiamo inviare una richiesta e ricevere la relativa risposta: telnet 80 Trying Connected to mu-in-f104.google.com ( ). Escape character is ^]. GET /index.html HTTP/1.1 Host: Connection: Close HTTP/ OK Cache-Control: private, max-age=0 Date: Mon, 26 Jan :33:56 GMT Expires: -1 Content-Type: text/html; charset=iso Set-Cookie: PREF=ID=68f0a6e6797de267:TM= :LM= :S=6L8dH9vX0HGcTvJw; expires=fri, 11-Feb :10:15 GMT; path=/; domain=.google.it

14 7 / 74 Server: gws Transfer-Encoding: chunked Connection: Close 1ad4 <html>[...omissis...]</html> 0 curl è un tool per il trasferimento di file su una moltitudine di protocolli di trasporto (http, ftp,...). La stessa richiesta eseguita in precedenza può esser replicata con curl in questo modo: curl con la possibilità di specificare una serie di opzioni per definizione di header, redirezione dell output, codifica dei parametri etc... ( Richiesta HTTP Analizziamo come è strutturata una richiesta HTTP GET /index.html HTTP/1.1 Host: User-agent: Mozilla Accept: text/html, image/jpeg, image/png La prima è la linea di richiesta: è composta dal metodo, URI della risorsa e versione del protocollo. Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti: GET: è usato per ottenere il contenuto della risorsa indicata nell URI (come può essere il contenuto di una pagina HTML) POST: è usato di norma per inviare informazioni al server (ad esempio i dati di un form) HEAD: funziona come il metodo GET, ma nella risposta vengono specificati solo gli header e non il corpo del messaggio. PUT: questo metodo richiede che il contenuto del messaggio venga memorizzato nella posizione specificata dalla URI DELETE: richiede la cancellazione della risorssa specificata nella URI. TRACE: fa eseguire l echo del messaggio OPTIONS: richiede al server di fornire informazioni sulle opzioni di comunicazione disponibili per la risorsa specificata. CONNECT: indica al proxy di assumere il comportamento di tunnel l URI sta per Uniform Resource Identifier ed indica l oggetto della richiesta (ad esempio la pagina web che si intende ottenere). I metodi HTTP più comuni sono GET, HEAD e POST. Molte degli altri metodi, anche se definiti nella specifica HTTP 1.1, non sono implementati dalla maggior parte dei web server. Le linee successive a quella di richiesta sono gli header http. Gli header sono nella forma: [nome]: [valore] Di seguito sono riportati alcuni header di uso comune per il messaggio di richiesta. Per una lista completa rimandiamo alle specifiche del W3C.

15 8 / 74 Header Descrizione Esempio Accept Mime Type accettati nella riosposta Accept: text/plain Authorization Credenziali per l autenticazione Authorization: Basic QWxhZGRpbcGVuIHNlc2FtZQ== Connection Tipo di connessione che il client preferisce Connection: Close Host Domain name dell host per il virtual hosting Host: Tabella 1: Header HTTP di richiesta Risposta HTTP La richiesta che abbiamo inviato in precedenza ritorna una risposta simile alla seguente: HTTP/ OK Cache-Control: private, max-age=0 Date: Mon, 26 Jan :33:56 GMT Expires: -1 Content-Type: text/html; charset=iso Set-Cookie: PREF=ID=68f0a6e6797de267:TM= :LM= :S=6L8dH9vX0HGcTvJw; expires=fri, 11-Feb :10:15 GMT; path=/; domain=.google.it Server: gws Transfer-Encoding: chunked Connection: Close 1ad4 <html>[...omissis...]</html> 0 La prima linea indica la versione del protocollo HTTP, il codice di stato e la Reason Phrase. Il codice di stato è un numero a tre cifre classificabile come segue: 200~299 Successo 300~399 Ridirezione 400~499 Errore del Client 500~599 Errore del Server Nel nostro caso la richiesta della pagina di root è stata completata con successo, con un 200 ok. Vediamo alcuni esempi di codice di stato che un server può inviarvi. Per la lista completa come sempre rimandiamo al sito del W3C. 200: OK; operazione completata con successo 302: ridirezione a una nuova URL; la URL originale è stata spostata. cercheranno la nuova pagina. Non si tratta di un errore, i browser compatibili 304: usa una copia locale; i browser compatibili mandano una informazione su lastmodified della copia della pagina in cache. Il server può rispondere con il codice 304 invece di mandare di nuovo la pagina in modo che il client utilizzi quella che risiede in cache. 401: non autorizzato. L utente ha richiesto un documento ma non ha fornito uno username o una password validi. 403: Vietato, l accesso alla URL è vietato. 404: Non trovato; il documento non è disponibile sul server. 500: Server error; si è verificato un errore interno del server.

16 9 / 74 A seguire la linea di risposta ci sono gli header (opzionali, come per la richiesta) che forniscono utili informazioni sui dati contenuti nel body (tipo, lunghezza), sul server che l ha costruita, sul file richiesto (data di ultima modifica). Come per gli header di richiesta, segue una lista non esaustiva degli header più comunemente utilizzati: Dopo gli headers c è una linea vuota a separare Header Descrizione Esempio Allow Metodi di richiesta accettati dal server Allow: GET, HEAD Content-Lentgth Dimensione dei dati in bytes Content-Length: 258 Content-Type Mime type del contenuto della risposta Content-Type: text/html; Date Data e ora dell invio della risposta Date: Tue, 15 Nov :12:31 GMT Exprires Data di scadenza del documento Expires: Tue, 15 Nov :12:31 GMT Last-Modified Data dell ultima modifica effettuata Last-Modified: Tue, 15 Nov 1994 sulla risorsa 08:12:31 GMT Location Per il redirect Location: Server Contiene informazioni sul server Server:Apache/ (Unix) PHP/4.3.4 WWW-authenticate Contiene informazioni per l accesso in WWW-Authenticate: Basic caso di errore 401 realm=link-it Tabella 2: Header HTTP piu frequenti i dati (opzionali, come per la Richiesta). Questi possono essere in qualsiasi formato, anche binario, come specificato nell header ContentType. Nel nostro caso, avendo richiesto una pagina HTML, il ContentType è text/html e nel corpo del messaggio vediamo il codice della pagina Codifica dei parametri Per effettuare le nostre richieste faremo uso principalmente dei metodi GET o POST. La differenza sostanziale sta nel modo in cui i dati sono codificati nel messaggio. Per la GET sono incapsulati nella URI di richiesta, mentre per la POST sono inclusi nel corpo del messaggio. Si possono compattare più parametri nella query string usando una codifica standard: separare i parametri con & sostituire i blank con + sottoporre ad escape (%xx) i caratteri speciali Per convenzione, il metodo GET dovrebbe essere usato solo per reperire risorse, mentre la POST usata per richieste che modificano lo stato del server. Proviamo ad esempio ad eseguire una ricerca su Google con Telnet. La pagina di ricerca è mentre il parametro da inviare si chiama q. telnet 80 Trying Connected to Escape character is ^]. GET /search?q=ciao HTTP/1.1 Host: Connection: Close

17 10 / 74 Nel caso di una richiesta con metodo POST, dopo gli header c è una linea vuota seguita dai dati della richiesta. Nel caso di GET o HEAD il campo body della richiesta è vuoto non avendo dati da inviare. Un altro modo per inserire i parametri è quello delle form html, usato normalmente per la navigazione web. Le Form sono introdotte dal tag <form>. Oltre a codice html, possono contenere i seguenti tag: <input> definisce text entry fields, checkboxes, radio buttons o pushbuttons <select> definisce dropdown menus e selection box <textarea> definisce campi text-entry su più linee la Form può avere i seguenti attributi: action, la URL di destinazione a cui saranno inviati i dati method, il metodo HTTP usato per la sottomissione dei dati (get o post) Vediamo ad esempio il codice di una semplice form che invia un parametro via get: <form action=" method="get"> Parametro: <input type="text" name="par"> <br/> <input type="submit" value="invia"> </form> Tramite browser, sarà visualizzato un campo di input testuale ed un bottone. Il testo inserito nel campo di input verrà adeguatamente codificato e inviato via GET alla pagina uno script che ritorna tutte le informazioni utili riguardo la richiesta ricevuta e il server che lo ospita: SCRIPT_NAME = /isi/cgi-bin/env.pl SERVER_NAME = projects.cli.di.unipi.it HTTP_REFERER = SERVER_ADMIN = wwwadm@cli.di.unipi.it HTTP_ACCEPT_ENCODING = gzip,deflate HTTP_CONNECTION = keep-alive REQUEST_METHOD = GET HTTP_ACCEPT = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q =0.8,image/png,*/*;q=0.5 SCRIPT_FILENAME = /home/projects/isi/cgi-bin/env.pl SERVER_SOFTWARE = Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c HTTP_ACCEPT_CHARSET = ISO ,utf-8;q=0.7,*;q=0.7 QUERY_STRING = par=bed+%26+breakfast REMOTE_PORT = HTTP_USER_AGENT = Mozilla/5.0 (X11; U; Linux i686; it; rv: ) Gecko/ Fedora / fc8 Firefox/ pango-text SERVER_PORT = 80 SERVER_SIGNATURE = Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c Server at projects.cli.di.unipi.it Port 80 HTTP_CACHE_CONTROL = max-age= HTTP_ACCEPT_LANGUAGE = it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_COOKIE = SESSa20d042eca1ead7ca16668c646e4e3af=07a100cd31837a1b1588bb2bd08e38a0 REMOTE_ADDR = HTTP_KEEP_ALIVE = 300 SERVER_PROTOCOL = HTTP/1.0

18 11 / 74 PATH = /usr/local/bin:/usr/bin:/bin REQUEST_URI = /isi/cgi-bin/env.pl?par=bed+%26+breakfast GATEWAY_INTERFACE = CGI/1.1 SERVER_ADDR = DOCUMENT_ROOT = /home/projects/ HTTP_HOST = projects.cli.di.unipi.it Eseguire query HTTP con JAVA Abbiamo usato fin qui telnet per effettuare le richieste ai web service, ma vediamo come eseguire le stesse interrogazioni programmando un semplice client HTTP in java. Ci sono più classi che consentono di effettuare comunicazioni su protocollo HTTP, aiutando a vario titolo il programmatore la gestione della specifica nelle operazioni più complesse. Il package che più si avvicina alle nostre esigenze è Commons-HttpClient ( del progetto Jakarta Commons. Implementiamo un client che replica la richiesta fatta in precedenza tramite la form inviando come valore Bed & Breakfast, stampando richiesta e risposta HTTP. I passi da completare sono i seguenti: Costruire la query string. Costruire e stampare la richiesta GET. Eseguire la richiesta e ricevere la risposta. Stampare il messaggio di risposta. Il primo passo richiede di inserire un parametro nella query string, come abbiamo fatto negli esempi precedenti. La difficoltà sta nel fatto che nel parametro da passare ci sono caratteri che non possiamo inserire nella query string (il carattere & e gli spazi per l esattezza) quindi dobbiamo prima codificari. Vediamo come fare: String parameter = URLEncoder.encode("Bed & Breakfast"); String querystring = " + parameter; Adesso possiamo costruire e stampare la richiesta: HttpClient httpclient = new DefaultHttpClient(); // Prepariamo la richiesta HttpGet httpget = new HttpGet(queryString); // Stampiamone il contenuto System.out.println(httpget.getRequestLine()); Header[] headers = httpget.getallheaders(); for(int i=0; i<headers.length; i++){ System.out.println(headers[i].getName() + ": " + headers[i].getvalue());

19 12 / 74 Eseguiamo la richiesta e stampiamo la risposta. // Eseguiamo la richiesta e prendiamo la risposta HttpResponse response = httpclient.execute(httpget); // Stampiamo Status Line e Headers System.out.println(response.getStatusLine()); headers = response.getallheaders(); for(int i=0; i<headers.length; i++){ System.out.println(headers[i].getName() + ": " + headers[i].getvalue()); // Prendiamo il contenuto della risposta HttpEntity entity = response.getentity(); InputStream instream = entity.getcontent(); String s = null; BufferedReader reader = new BufferedReader(new InputStreamReader(instream)); while((s = reader.readline())!= null) System.out.println(s); instream.close(); Non rimane che gestire eventuali errori sincerandoci di chiudere la connessione se attiva. 2.2 Web/Application Server Un Web Server implementa il protocollo HTTP lato server. Il suo compito è quello di ricevere le richieste dai vari client. La porta solitamente utilizzata per questo scopo è la 80. Il browser non richiede che venga specificata e usa quella porta come default per individuare il server. Qualora la porta del Web Server fosse diversa, allora è necessario specificarla nell url (es. Ricevura la richiesta, il server si occupa di reperire le risorse specificate nella URL di richiesta secondo il metodo specificato (GET, POST..). A questo punto costruisce un prologo di risposta HTTP contenente informazioni sullo stato, gli header e i dati relativi alla risorsa richiesta. Completata la risposta la invia al richiedente Introduzione alla programmazione di Servlet. I servlet sono oggetti che operano all interno di un server per applicazioni (Application Server, per esempio Apache Tomcat) e potenziano le sue funzionalità. La parola servlet fa coppia con applet, che si riferisce a piccoli programmi scritti in Java che si eseguono all interno di un browser. L uso più frequente dei servlet è generare pagine web in forma dinamica a seconda dei parametri della richiesta spedita dal browser. Un servlet può avere molteplici funzionalità e può essere associato ad una o più risorse web. Un esempio potrebbe essere un meccanismo per il riconoscimento dell utente. Quando digito un URL del tipo miosito/login, viene invocato un servlet che verificherà che i dati inseriti siano corretti e in base a questa decisione mi potrà indirizzare in una pagina di conferma o di errore. Sotto quest ottica un servlet è un programma che deve rispettare determinate regole e che processa in un determinato modo una richiesta HTTP. Nulla vieta che all interno dello stesso server web possano girare più servlet associati a URL diversi; ognuno di questi servlet farà cose diverse e estenderà le funzionalità del server web. La Servlet API ( è un estensione standard di Java sin dalla versione 1.2 e si tratta di moduli caricati dinamicamente dal server su richiesta. Una servlet è in grado di gestire più richieste contemporaneamente in modalità thread safe, consentendo a più processi di uilizzare le stesse risorse gestendone la concorrenza. La diffusione di questa tecnologia garantisce una buona portabilità del codice su un elevato numero di ambienti, aspetto cruciale quando si parla di applicazioni internet. Spesso le servlet sono indirizzati tramite il prefisso servet nella URL Il prefisso è configurabile nell application server ed è possibile avere più prefissi sul solito application server.

20 13 / Ciclo di vita di una Servlet Una servlet, nella sua forma più generale, è un istanza di una classe che implementa l interfaccia javax.servlet.servlet. Molte servlet, comunque, estendono una delle implementazioni standard di questa interfaccia. Dovendo gestire richieste HTTP, useremo ed esamineremo l implementazione javax.servlet.http.httpservlet. Quando viene istanziata/deployata una HttpServlet, l application server (es. Tomcat) chiama il metodo init della Servlet. La Servlet dovrebbe così effettuare una procedura di startup unica nel suo ciclo vitale. Adesso la Servlet è pronta per ricevere le richieste, per ognuna delle quali viene invocato il metodo corrispondente al tipo di richiesta (doget, dopost, dohead...). Nota La servlet viene chiamata concorrentemente per gestire più richieste, quindi dovrebbe essere implementato in modo threadsafe. Qualora non fosse possibile gestire la concorrenza dei thread e si rivelasse necessario rendere la Servlet singlethreaded è sufficiente che implementi l interfaccia SingleThreadModel. Quando è necessario effettuare l unload della servlet (ad esempio perchè è stata rilasciata una nuova versione, o il server deve essere spento) viene chiamato il metodo destroy. public class MyServlet extends public void init() throws ServletException{ // Viene eseguito una sola volta // alla prima chiamata della public void destroy(){ // Viene eseguito una sola volta // all unload della servlet Implementare HttpServlet Adesso che abbiamo chiaro il ciclo di vita di una Servlet, possiamo implementarne una Servlet Http. javax.servlet.httpservlet è l implementazione dell interfaccia Servlet che dobbiamo estendere facendo l override dei metodi ereditati. I metodi della classe HttpServlet ricevono in ingresso gli oggetti HttpServletRequest e HttpServletResponse che forniscono metodi per reperire o impostare i dati della richiesta e risposta HTTP. public class MyServlet extends public void doget(httpservletrequest req, HttpServletResponse res){...

21 14 / public void dopost(httpservletrequest req, HttpServletResponse public void doput(httpservletrequest req, HttpServletResponse public void dodelete(httpservletrequest req, HttpServletResponse res){ Se non viene fatto l override di un metodo, viene usata l implementazione ereditata che di default risponde al client con un errore di tipo 501: Not Implemented. Qualora il metodo fosse implementato, ma non ammesso per la risorsa richiesta, il server deve rispondere con un errore 405: Method not allowed. Ottenuta una HttpServletRequest è possibile in ogni metodo: getparameternames accede alla lista dei nomi dei parametri getparameter accede ai parametri per nome getquerystring consente il parsing manuale della QUERY_STRING Vediamo come implementare una servlet http che raccolga i dati inviati dal client. import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloServlet extends HttpServlet public void doget(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { String nome = req.getparameter("nome"); System.out.println("Hello, " + parameter); Deploy della Servlet Una volta compilata la servlet dobbiamo confezionarla per essere passata all Application Server. Questa è la stuttura standard per le applicazioni web compatibili J2EE 1.2:

22 15 / 74 Per quanto riguarda il nostro esempio, dobbiamo mettere la classe appena compilata che implementa la servlet sotto WEB-IN- F/classes e creare il file WEB-INF/web.xml. Vediamone un esempio: <web-app> <servlet> <servlet-name>hello</servlet-name> <servlet-class>helloservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>hello</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> </web-app> L elemento servlet definisce il nome della servlet da usare per riferirla nel resto del documento e la classe che la implementa. L elemento servlet-mapping indica al server a quale URL il servizio deve rispondere. Completati i file necessari e organizzati secondo le specifiche, copiamo tutto nella cartella webapps di Tomcat per fargli eseguire il deploy dell applicazione. 2.3 Sessioni Da html.it Una delle funzionalità più richieste per un applicazione web è mantenere le informazioni di un utente durante tutta la sessione. Una sessione è una sequenza di transazioni http, legate tra di loro secondo una logica applicativa. Sappiamo che il protocollo http non ha stato e per il server non è possibile capire se due richieste http sono eseguite dal solito client. Per aggirare questo problema, il server associa e comunica ad un client un identificativo di riconoscimento che questo userà per le richieste successive, permettendo al server di riconoscerlo. È possibile quindi creare applicazioni su protocollo http che riconoscono l utente, che tengono traccia delle sue scelte e dei suoi dati. Vediamo come nasce una sessione e come il server riesce ad associare la solita sessione ad un client usando i cookies: Prima Richiesta 1. L utente contatta il server per la prima volta. 2. Il server controlla se il client ha fornito un SessionID. Se non lo ha fatto crea una nuova sessione e genera un SessionID per identificare questa sessione. 3. Il server invia un header Set-Cookie al client 4. Il client salva il cookie per il dominio in questione Seconda Richiesta 1. L utente visita il server, stavolta inserendo l header Cookie contenente il SessionID salvato in precedenza. 2. Il server controlla se il client ha fornito un SessionID. 3. Il server verifica se il SessionID ricevuto corrisponde ad una sessione. 4. Il server localizza i dati di sessione e li rende disponibili all applicazione

23 16 / 74 Nota I cookie HTTP sono frammenti di testo inviati da un server ad un Web client e poi rimandati indietro dal client al server - senza subire modifiche - ogni volta che il client accede allo stesso server. Il server invia l header Set-Cookie con le variabili ed i loro valori, seguiti da elementi opzionali, come la data di scadenza, il dominio etc. Set-Cookie: <name>=<value>[; <name>=<value>]...[; expires=<date>][; domain=<domain_name>][; path=<some_path>][; secure][; httponly] Il client risponde con l header Cookie Cookie: <name>=<value>[; <name>=<value>]... i parametri DOMAIN e PATH individuano le URL per cui un cookie è valido il parametro expires specifica la validità temporale del cooky (Es: Wdy, DD-Mon-YYYY HH:MM:SS GMT) il parametro secure indica che il Cookie va spedito solo se il canale è sicuro (https) Se il client non supporta i cookies, possiamo comunque trasmettere l identificativo di sessione in altri due modi: Hidden Field: come parametro nel payload del messaggio HTTP Url Rewriting: nella URL di richiesta con la sintassi =value&.. Le informazioni di sessione sono quindi memorizzate sul server, mentre lato client viene visto solo un identificativo di sessione. Nota Per scoprire se un client supporta o meno l uso dei cookies, non c e altro modo che eseguire un tentativo di scrittura di cookie e verificarne successivamente l invio da parte del client. Poichè questo controllo introduce dei passaggi extra non desiderati nel processo di accesso e fruizione di una applicazione web con sessioni, spesso si preferisce inviare l id sessione contemporaneamente via cookie che via hidden field. Le richieste successive paleseranno quale dei due metodi il client ha accettato Problematiche nella gestione delle sessioni - Caso Alitalia Quando sviluppiamo una applicazione web dobbiamo sempre ricordare che l utente non necessariamente segue il percorso che abbiamo immaginato, ma che possa saltare passaggi, inserire dati errati, concorrere con altri utenti nell uso di risorse condivise. Alitalia ci fornisce un esempio di cattiva programmazione nell uso delle sessioni. Vediamo come replicarlo. Andiamo sulla pagina delle prenotazioni e facciamo una ricerca, ad esempio per un volo A/R Roma - Milano:

24 17 / 74 In un altra finestra facciamo un altra ricerca, ad esempio per un volo A/R Roma - Napoli:

25 18 / 74 Torniamo adesso alla lista dei voli Roma - Milano e acquistiamo il primo.

26 19 / 74 Ci aspettavamo il riepilogo del volo Roma - Milano, ma ci arriva quello di Roma - Napoli. Cosa è successo? Se guardiamo il sorgente della pagina che mostra i voli disponibili vediamo che ad ogni bottone è associato il numero di indice in tabella. Se ne desume che in sessione è salvata una corrispondenza che associa al numero di indice l identificativo del volo. Quando abbiamo fatto la seconda ricerca quei valori sono stati sovrascritti annullando di fatto la prima ricerca. Il progettista del sito non ha tenuto conto della possibilità che un utente potesse fare ricerche multiple concorrentemente. Una soluzione banale al problema è di non riferire un volo con l indice di tabella, ma con un identificativo univoco Sessioni in Java In Java una sessione HTTP viene rappresentata tramite un oggetto HttpSession. Tramite le sessioni si realizza la persistenza degli oggetti tra una richiesta HTTP e l altra. Java tenta di gestire le sessioni tramite cookie. Se questo non è possibile si può alternativamente passare l ID di sessione tra i parametri della pagina. Per questo scopo, il metodo encodeurl(string URL) di HttpServletResponse aggiunge il parametro con l id di sessione all URL passata nel caso in cui questo sia necessario. Tramite il metodo getsession() in HttpServletRequest viene restituita la sessione corrente o ne viene creata una nuova se questa non esiste.

27 20 / 74 Modifichiamo il servlet creato in precedenza e implementiamo uno storico dei parametri passati. //Recupero la sessione o la creo se non esiste HttpSession session = request.getsession(); //Recupero la lista di parametri in sessione o la instanzio se ancora non esiste String parameters = (String) (session.getattribute("parameters")); //Aggiungo il parametro arrivato nella lista di parametri e li stampo a video parameters += myparameter + "\n"; System.out.println(parameters); //Inserisco la lista dei parametri aggiornata in sessione. ses.setattribute("parameters", parameters); Lato client dovremo recuperare l id di sessione e inserirlo nelle richieste successive o tramite header o tramite query string. //Recupero l id sessione dagli header della risposta HttpResponse response = httpclient.execute(httpget); String cookie = response.getheader("set-cookie"); //Inserisco l idsessione nelle richieste successive HttpRequest request =... request.setheader("cookie", cookie); In questo modo tutte le volte che effettueremo una richiesta inviando l id di sessione e un valore ad un parametro, riceveremo nella risposta tutti i valori inviati fino a quel momento. 3 Introduzione all XML 3.1 XML Supponiamo che nel nostro scenario di riferimento il cliente voglia comunicare i dati di un ordine al rivenditore. Supponiamo per semplicità che il rivenditore abbia bisogno solo dei modelli dei prodotti scelti, delle quantità e del corriere preferito per gestire un ordine. I dati da inviare potrebbero essere questi: DHL Playstation 1 Controller 2 I dati presentati in questo modo sono però liberi di essere interpretati poichè privi di valore semantico. Abbiamo bisogno di un linguaggio che ci permetta specificare che la prima riga indica il corriere scelto per la spedizione, mentre le linee successive indicano il codice di un prodotto e la quantità richiesta. Per gestire questa problematica su, il W3C ha progettato ad-hoc il linguaggio XML (extensible Markup Language), un meta-linguaggio di markup per la strutturazione dei dati. La scelta di usare XML per la strutturazione dei dati è dettata da alcune sue importanti qualità Auto descrittivo: non richiede file esterni che ne definiscano la semantica perchè quest informazione è già contenuta al suo interno Semplice: ha una sintassi caratterizzata da poche e semplici regole. Estensibile: gli elementi già sintatticamente definiti possono essere estesi e adattati ad altri utilizzi. Interoperabile: supportato da una grande varietà di framework e linguaggi di programmazione, garantisce un livello di interoperabilità indispensabile per l implementazione di servizi web

28 21 / Sintassi XML La sintassi dell XML è piuttosto semplice e definita da poche, ma rigide, regole. Vediamole brevemente: È buona norma cominciare il documento XML specificando la versione e la codifica usata: <?xml version="1.0" encoding="iso "?> Tutti gli elementi devono avere il tag di chiusura. <ordine>... </ordine> <ordine /> I tag sono case sensitive. <ordine> sbagliato </Ordine> I tag devono essere annidati in maniera corretta. <ordine><articolo> sbagliato </ordine></articolo> <ordine><articolo> corretto </articolo></ordine> Un documento XML deve avere un elemento radice <ordine> <articolo>.. </articolo> </ordine> I valori degli attributi devono essere tra apici <ordine corriere = DHL> sbagliato </ordine> <ordine corriere = "DHL"> corretto </ordine> Il carattere minore (<) e l ampersand (&) sono vietati all interno degli elementi e devono essere codificati. E consigliabile farlo anche con altri caratteri speciali anche se non strettamente necessario: < < > > & & &apos; " Tabella 3: Codifica di caratteri speciali Si possono inserire commenti all interno di un documento XML <!-- commento --> Quando parsiamo un documento XML, anche il contenuto degli elementi viene parsato alla ricerca di nodi interni. Se non vogliamo che una porzione di XML sia processata la definiamo CDATA (Character DATA) in questo modo: <![CDATA[... ]]>

29 22 / Strutturare i dati Ora che conosciamo le regole sintattiche dell XML, vediamo come possiamo strutturare i dati del nostro ordine: <nome>playstation</nome> <quantita>1</quantita> <nome>controller</nome> <quantita>2</quantita> adesso abbiamo dato un significato a quei dati, ma sono ancora ambigui. Possiamo annidare gli elementi e strutturare ancora meglio le informazioni. Possiamo specificare che un codice ed una quantità sono per un articolo e che tanti articoli fanno un ordine: <ordine> <articolo> <nome>playstation</nome> <quantita>1</quantita> </articolo> <articolo> <nome>controller</nome> <quantita>2</quantita> </articolo> </ordine> Possiamo anche inserire degli attributi ad un elemento <ordine corriere="dhl"> <articolo> <nome>playstation</nome> <quantita>1</quantita> </articolo> <articolo> <nome>controller</nome> <quantita>2</quantita> </articolo> </ordine> Namespace In XML i nomi degli elementi sono definiti dallo sviluppatore. Questo può causare dei conflitti, ad esempio quando si lavora su documenti XML di provenienze diverse. Vediamo un esempio pratico: supponiamo che nell ordine inseriamo anche il nome del produttore e del prodotto. Potrebbe verificarsi una situazione di questo tipo: <ordine> <nome>nintendo</nome>... <nome>wii</nome>... </ordine> Come fare a distinguerli? Per questo si definiscono due namespace e, grazie al prefisso, si risale al loro significato semantico <ordine xmlns:ns1=" xmlns:ns2=" <ns1:nome>nintendo</ns1:nome>... <ns2:nome>wii</ns2:nome>... </ordine> Se non viene specificato un prefisso di un namespace, questo viene preso come default e assegnato a tutti i nodi discendenti privi di namespace. La definizione di un namespace è visibile nel nodo in cui viene inserita e in tutti i suoi discendenti.

30 23 / XML in Java, DOM Abbiamo scritto lo schema di un ordine. Vediamo come modificare il client HTTP affichè lo invii alla servlet. //Creo il documento XML dell ordine String xml = "<ordine corriere="dhl">"+ "<articolo>" + "<nome>playstation</nome>" + "<quantita>1</quantita>" + "</articolo>" + "<articolo>" + "<nome>controller</nome>" + "<quantita>2</quantita>" + "</articolo>" + "</ordine>" + "</ordine>"; //Creo il client per effettuare la POST dell XML HttpClient httpclient = new DefaultHttpClient(); HttpPost httppost = new HttpPost(servletUrl); //Creo l entita da inviare settandone il giusto ContentType StringEntity xmlentity = new StringEntity(xml); xmlentity.setcontenttype("text/xml"); httppost.setentity(xmlentity); System.out.println("executing request " + httppost.getrequestline()); HttpResponse response = httpclient.execute(httppost); System.out.println(" "); System.out.println(response.getStatusLine()); Java API for XML Processing La Java API for XML Processing (JAXP) è una libreria standard processare codice XML. L attuale versione è la 1.4 inclusa in Java SE 6.0 ed una sua implementazione è scaricabile all indirizzo jaxp.dev.java.net. Sono forniti più modi per effettuare il parsing di un documento XML. Un parser è un programma che effettua la lettura di un documento XML e lo divide in blocchi discreti. I due classici approcci per processare i documenti XML sono:

31 24 / 74 Simple API for XML Processing (SAX) Document Object Model (DOM) SAX è un API di basso livello il cui principale punto di forza è l efficienza. Quando un documento viene parsato usando SAX, una serie di eventi vengono generati e passati all applicazione tramite l utilizzo di callback handlers che implementano l handler delle API SAX. Gli eventi generati sono di livello molto basso e devono essere gestiti dallo sviluppatore che, inoltre, deve mantenere le informazioni necessarie durante il processo di parsing. Oltre ad un utilizzo piuttosto complicato, SAX soffre di due limitazioni di rilievo: non può modificare il documento che sta elaborando e può procedere alla lettura solo in avanti: non può tornare indietro. Quindi, quello che è stato letto è perso e non è possibile recuperarlo. DOM, invece, ha come punto di forza la semplicità d utilizzo. Una volta ricevuto il documento, il parser si occupa di costruire un albero di oggetti che rappresentano il contenuto e l organizzazione dei dati contenuti. In questo caso l albero esiste in memoria e l applicazione può attraversarlo e modificarlo in ogni suo punto. Ovviamente il prezzo da pagare è il costo di computazione iniziale per la costruzione dell albero ed il costo di memoria. A questi rappresentanti delle due principali tecniche di rappresentazione dei dati XML si aggiungono altri due parser di recente concezione: Streaming API for XML (StAX) Transformation API for XML (TrAX) StAX è un pull parser. A differenza di SAX, che è un push parser, non riceve passivamente i segnali inviati all handler per elaborarli, ma è l utente a controllare il flusso degli eventi. Questo significa che il client richiede (pull) i dati XML quando ne ha bisogno e nel momento in cui può gestirli, a differenza del modello push, dove è il parser a inviare i dati non appena li ha disponibili a prescindere che l utente ne abbia bisogno o sia in grado di elaborarli. Le librerie pull parsing sono molto può semplici delle push parsing e questo permette di semplificare il lavoro dei programmatori, anche per documenti molto complessi. Inoltre è bidirezionale, nel senso che oltre a leggere dati XML è anche in grado di produrli. Rimane il limite di poter procedere solo in avanti nell elaborazione del documento XML. TrAX, con l utilizzo di un XSLT stylesheet, permette di trasformare l XML. Inoltre, poiché i dati vengono solitamente manipolati con SAX o DOM, questo parser può ricevere in ingresso sia eventi SAX che documenti DOM. Può anche essere usato per convertire i dati da un formato all altro, infatti, è possibile prendere un documento DOM, trasformarlo e scriverlo su file, oppure prendere l XML da file, trasformarlo e restituirlo in forma di documento DOM. La tabella seguente riassume brevemente le caratteristiche principali dei parser presentati: Supponiamo di avere un documento Feature StAX SAX DOM TrAX Tipo di API Pull, streaming Push, streaming In memory tree XSLT Rule Facilità d uso Alta Media Alta Media Efficenza CPU e Buona Buona Dipende Dipende Memoria Solo in avanti Si Si No No Legge XML Si Si Si Si Scrive XML Si No Si Si CRUD (Create Read Update Delete) No No Si Si Tabella 4: Parser XML contenente le informazioni di una biblioteca. Non sappiamo con esattezza la struttura del documento, ma sappiamo che il titolo dei libri è contenuto in un elemento di come titolo. Vediamo come parsare il documento con gli strumenti offerti da JAXP e stampare i titoli dei libri.

32 25 / DOM Parser Vediamo come ottenere un documento DOM partendo dall XML import javax.xml.parsers.documentbuilder; import javax.xml.parsers.documentbuilderfactory; import org.w3c.dom.document; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder builder = factory.newdocumentbuilder(); Document document = builder.parse( new File("/tmp/mysource.xml") ); NodeList nodes = document.getelementsbytagname("title"); while(int i = 0; i < nodes.length(); i ++) { Element titleelem = (Element)nodes.item(i); Node childnode = titleelem.getfirstchild(); if (childnode instanceof Text) { System.out.println("Book title is: " + childnode.getnodevalue()); SAX Parser Vediamo come effettuare il parsing con SAX SAXParser saxparser = new SAXParser(); MyContentHandler myhandler = new MyContentHandler(); saxparser.setcontenthandler(myhandler); saxparser.parse(new File("/tmp/mysource.xml")); Questa è l implementazione del nostro handler:

33 26 / 74 public class MyContentHandler extends DefaultHandler { public void startelement(string uri, String localname, String qname, Attributes atts) { if (localname.equals("title")) istitle = true; public void endelement(string uri, String localname, String qname) { if(localname.equals("title")) istitle = false; public void characters(char[ ] chars, int start, int length) { if(istitle) System.out.println(new String(chars, start, length)); StAX Parser Vediamo come fare il parsing di un documento xml con StAX XMLInputFactory fac = XMLInputFactory.newInstance(); XMLEventReader eventreader = fac.createxmleventreader(new FileInputStream("/tmp/mysource. xml")); while(eventreader.hasnext()) { XMLEvent event = eventreader.next(); if (event instanceof StartElement && ((StartElement)event).getLocalName().equals(" title")) { System.out.println( ((Characters)eventReader.next()).getData()); 3.2 XSD Abbiamo appena visto come strutturare i dati e dar loro un significato grazie all uso dell XML, adesso abbiamo bisogno di uno strumento che ci permetta di descrivere tale struttura. Questo ci consentirebbe di validarne un messaggio XML, ovvero controllare che la sua struttura rispetti un determinato schema. Per definire uno schema si utilizza l XSD (XML Schema Definition), un linguaggio bassato su XML Costruzione di uno Schema XML Vediamo come si costruisce lo schema di un documento XML. <?xml version="1.0"?> <xs:schema xmlns:xs=" targetnamespace=" elementformdefault="qualified">...

34 27 / 74 </xs:schema> Il nodo radice deve essere uno schema definito nel namespace Con il frammento targetnamespace=" si indica che gli elementi che si andranno a definire avranno quel namespace, mentre con elementformdefault="qualified" indichiamo che tutti gli elementi definiti saranno qualificati (ovvero avranno un namespace), non solo quelli globali. A questo punto inseriamo gli elementi. Gli elementi si suddividono in semplici e complessi. Un elemento semplice è un elemento XML che può contenere solo testo. Non può contenere nessun altro elemento o attributo. Il testo contenuto può comunque avere tipi differenti, quindi essere uno dei tipi inclusi nella definizione di XML Schema (boolean, string, date, etc.) oppure un tipo definito da noi. Inoltre possiamo imporre restrizioni al tipo di dato inserito per limitarne il contenuto. Vediamo ad esempio che codice e quantita sono elementi semplici, dal momento che contengono solamente testo. La sintassi per definire un elemento semplice è la seguente: <xs:element name="xxx" type="yyy"/> dove xxx è il nome dell elemento e yyy il suo tipo. l XML Schema ha molti tipi di dato predefiniti. I più comuni sono: xs:string xs:decimal xs:integer xs:boolean xs:date xs:time Possiamo quindi specificare i due elementi in questo modo: <?xml version="1.0"?> <xs:schema xmlns:xs=" targetnamespace=" elementformdefault="qualified"> <xs:element name="quantita" type="xs:integer"/> <xs:element name="nome" type="xs:string"/> </xs:schema> Supponiamo di voler limitare il nome dell articolo ad una stringa di 7 caratteri alfanumerici maiuscoli, privi di spazi. Per far questo definiamo un nuovo tipo imponendo una restrizione sul tipo base string: <?xml version="1.0"?> <xs:schema xmlns:xs=" targetnamespace=" elementformdefault="qualified"> <xs:element name="quantita" type="xs:positiveinteger"/> <xs:element name="nome" type="nometype"/> <xs:simpletype name="nometype"> <xs:restriction base="xs:string">

35 28 / 74 <xs:pattern value="[a-z0-9]{7"/> </xs:restriction> </xs:simpletype> </xs:schema> Definiamo a questo punto l elemento articolo, costituito dai due elementi semplici descritti in precedenza. Non essendo solo testo, non è un elemento semplice, ma complesso. I tipi complessi sono elementi con attributi o costituiti da altri elementi. <?xml version="1.0"?> <xs:schema xmlns:xs=" targetnamespace=" elementformdefault="qualified"> <xs:element name="articolo" type="articolotype"/> <xs:complextype name="articolotype"> <xs:sequence> <xs:element name="nome" type="nometype"/> <xs:element name="quantita" type="xs:integer"/> </xs:sequence> </xs:complextype> <xs:simpletype name="nometype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z0-9]{7"/> </xs:restriction> </xs:simpletype> </xs:schema> Quando definiamo un nuovo tipo complesso, alcuni degli elementi utilizzabili sono: sequence: richiede che gli elementi compaiono nell ordine specificato group: un raggruppamento di altri tipi da utilizzare per un complextype all: ammette che elementi compaiano (o non compaiano) in qualsiasi ordine choice: ammette uno e uno solo degli elementi contenuti Concludiamo il nostro schema definendo l elemento ordine come sequenza di molti elementi articolo. Utilizzeremo nuovamente l elemento xs:sequence specificando questa volta il numero di occorrenze (di default impostate a 1) Per specificare un attributo nell elemento ordine basta inserire il seguente elemento nella sua definizione <xsd:attribute name="corriere" type="xsd:string" /> <?xml version="1.0"?> <xs:schema xmlns:xs=" targetnamespace=" elementformdefault="qualified"> <xs:element name="ordine" type="ordinetype"/> <xs:complextype name="ordinetype"> <xs:sequence maxoccurs="unbounded"> <xs:element name="articolo" type="articolotype"/> </xs:sequence> <xsd:attribute name="corriere" type="xsd:string" />

36 29 / 74 </xs:complextype> <xs:complextype name="articolotype"> <xs:sequence> <xs:element name="nome" type="nometype"/> <xs:element name="quantita" type="xs:positiveinteger"/> </xs:sequence> </xs:complextype> <xs:simpletype name="nometype"> <xs:restriction base="xs:string"> <xs:pattern value="[a-z0-9]{7"/> </xs:restriction> </xs:simpletype> </xs:schema> A questo punto abbiamo definito l XSD e possiamo validare il contenuto del documento XML. Uno strumento di validazione online è reperibile all indirizzo grazie ad esso possiamo controllare se un documento XML rispetta lo schema definito in un documento XSD Validazione con JAXP JAXP, oltre ad effettuare il parsing e la costruzione dell albero DOM, fornisce gli strumenti per validare i documenti XML rispetto ad uno o più XML Schema. Per essere notificati di eventuali errori di validazione devono essere rispettati questi vincoli: La Factory deve essere configurata e settato l handler dell errore Al documento deve essere associato almento uno schema Vediamo come gestire la validazione con JAXP. Per prima cosa configuriamo il parser static final String JAXP_SCHEMA_LANGUAGE = " schemalanguage"; static final String W3C_XML_SCHEMA = " DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance() factory.setnamespaceaware(true); factory.setvalidating(true); try { factory.setattribute(jaxp_schema_language, W3C_XML_SCHEMA); catch (IllegalArgumentException x) {... Poi settiamo l XML Schema. Questo può esser fatto o dichiarandolo nel documento XML stesso <documentroot xmlns:xsi=" xsi:nonamespaceschemalocation= YourSchemaDefinition.xsd > Oppure specificandolo nella factory

37 30 / 74 static final String schemasource = "YourSchemaDefinition.xsd"; static final String JAXP_SCHEMA_SOURCE = " schemasource";... DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance()... factory.setattribute(jaxp_schema_source, new File(schemaSource)); 3.3 Applicazioni XML su HTTP Abbiamo adesso un client che invia ad una servlet il codice XML di un ordine. Implementiamo la servlet in modo che lo validi e ne legga il contenuto. try{ // Imposto la factory per la validazione DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setignoringelementcontentwhitespace(true); factory.setnamespaceaware(true); factory.setvalidating(true); factory.setattribute(jaxp_schema_language, W3C_XML_SCHEMA); factory.setattribute(jaxp_schema_source, new File(xsdSchema)); // Prendo il parser, valido l xml e ne ottengo il DOM DocumentBuilder builder = factory.newdocumentbuilder(); builder.seterrorhandler(new MyErrorHandler()); Document request = builder.parse( req.getinputstream() ); NodeList articoli = request.getelementsbytagname("articolo"); for(int i = 0; i < articoli.getlength(); i++){ Node articolo = articoli.item(i); NodeList articolo_children = articolo.getchildnodes(); // Cerco e stampo nome e quantita degli articoli for(int h = 0; h < articolo_children.getlength(); h++){ Node articolo_child = articolo_children.item(h); if(articolo_child.getlocalname().comparetoignorecase("nome") == 0) System.out.print(articolo_child.getTextContent()); if(articolo_child.getlocalname().comparetoignorecase("quantita") == 0) System.out.println(articolo_child.getTextContent()); Infine rispondiamo al Client con un messaggio che confermi la ricezione dell ordine. try{ // Imposto il Content-Type res.setcontenttype("text/xml"); // Scrivo il corpo del messaggio String xml = "<esito>ok<esito>"; res.getwriter().write(xml); catch(ioexception e){ e.printstacktrace();

38 31 / 74 res.setstatus(500); 4 Web Service Abbiamo visto finora come http (trasporto) e xml (data representation) possano essere intuitivamente usati per realizzare applicazioni web. Queste semplici modalità applicative possono essere utilizzate per sviluppare applicazioni ad hoc, ma non sono sufficienti ad indirizzare gli aspetti di interoperabilità tra applicazioni sviluppate indipendentemente. È questo l obiettivo dei Web Services, un insieme di architetture e specifiche condivise finalizzato a risolvere i problemi di interoperabilità nella cooperazione applicativa. 4.1 SOAP Il protocollo piu usato per la strutturazione dei messaggi applicativi scambiati tra servizi Web è il protocollo SOAP. SOAP (Simple Object Access Protocol) è un protocollo basato su XML per lo scambio d informazioni in un ambiente distribuito e definisce un formato comune per trasmettere dati tra client e service. SOAP prevede l imbustamento dei contenuti applicativi da scambiare all interno di un formato di busta XML ed e indipendente dal protocollo di trasporto utilizato per la consegna dei messaggi, che teoricamente potrebbe anche avvenire off-line. Il namespace degli elementi SOAP è L elemento base di un messaggio SOAP è il SOAP Envelope. <?xml version="1.0"?> <soap:envelope xmlns:soap=" </soap:envelope> L Envelope ha due figli: l Header, opzionale, e il Body, obbligatorio. L elemento opzionale SOAP Header estende il messaggio e contiene metadati, informazioni utili al processamento del messaggio, come ad esempio l identità dell utente, informazioni riguardo la cifratura del documento, o informazioni per il routing del messaggio. <?xml version="1.0"?> <soap:envelope xmlns:soap=" <soap:header> <myheader soap:actor="..." soap:mustunderstand="...">...