Corso di Laboratorio Applicazioni Internet

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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... (http://curl.haxx.se/docs/manual.html) 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:http://isi.link.it/isi.html 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="http://projects.cli.di.unipi.it/isi/cgi-bin/env.pl" 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 = 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 (http://hc.apache.org/index.html) 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 = "http://localhost:8080/sample/index.html?par=" + 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 (http://java.sun.com/products/servlet/2.2/javadoc/index.html) è 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="http://www.shop.org/manufacturers/ns" xmlns:ns2="http://www.shop.org/product/ns"> <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="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.shop.com/ns" elementformdefault="qualified">...

34 27 / 74 </xs:schema> Il nodo radice deve essere uno schema definito nel namespace Con il frammento targetnamespace="http://www.shop.com/ns" 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="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.shop.com/ns" 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="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.shop.com/ns" 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="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.shop.com/ns" 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="http://www.w3.org/2001/xmlschema" targetnamespace="http://www.shop.com/ns" 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 = "http://java.sun.com/xml/jaxp/properties/ schemalanguage"; static final String W3C_XML_SCHEMA = "http://www.w3.org/2001/xmlschema"; 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="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation= YourSchemaDefinition.xsd > Oppure specificandolo nella factory

37 30 / 74 static final String schemasource = "YourSchemaDefinition.xsd"; static final String JAXP_SCHEMA_SOURCE = "http://java.sun.com/xml/jaxp/properties/ 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="http://www.w3.org/2001/12/soap-envelope">... </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="http://www.w3.org/2001/12/soap-envelope"> <soap:header> <myheader soap:actor="..." soap:mustunderstand="...">...

XML e XSD. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

XML e XSD. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com XML e XSD Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com Ordine di Acquisto Servizio: eshop Operazione: ordine di acquisto Dati dell'ordine: prodotti quantità corriere Playstation 2 Controller

Dettagli

Il Protocollo HTTP e la programmazione di estensioni Web

Il Protocollo HTTP e la programmazione di estensioni Web Il Protocollo HTTP e la programmazione di estensioni Web 1 Il protocollo HTTP È il protocollo standard inizialmente ramite il quale i server Web rispondono alle richieste dei client (prevalentemente browser);

Dettagli

Introduzione alla programmazione Http lato server in Java

Introduzione alla programmazione Http lato server in Java Introduzione alla programmazione Http lato server in Java Tito Flagella Laboratorio Applicazioni Internet - Università di Pisa Slide API Java Titleper il Protocollo Http Programmazione Client java.net.url

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Architetture Web Protocolli di Comunicazione

Architetture Web Protocolli di Comunicazione Architetture Web Protocolli di Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 10 Maggio 2011 Architetture Web Architetture Web Protocolli di Comunicazione Il Client Side Il Server Side

Dettagli

Architetture Applicative Il Web

Architetture Applicative Il Web Architetture Applicative Il Web Alessandro Martinelli alessandro.martinelli@unipv.it 18 Marzo 2014 Architetture Architetture Web L Architettura Client-Server HTTP Protocolli di Comunicazione Fondamenti

Dettagli

Sessioni Applicative in Http. Tito Flagella tito@link.it

Sessioni Applicative in Http. Tito Flagella tito@link.it Sessioni Applicative in Http Tito Flagella tito@link.it Perché le sessioni Solitamente le transazioni http sono anonime e indipendenti Le applicazioni hanno bisogno di correlarle tra di loro User1: http://bank.com/prelievo?amount=10000$

Dettagli

Lezione di Basi di Dati 1 18/11/2008 - TECNOLOGIE PER IL WEB: CGI - AJAX SERVLETS & JSP

Lezione di Basi di Dati 1 18/11/2008 - TECNOLOGIE PER IL WEB: CGI - AJAX SERVLETS & JSP EVOLUZIONE DEL WEB: PAGINE STATICHE vs PAGINE DINAMICHE Il Web è nato a supporto dei fisici, perché potessero scambiare tra loro le informazioni inerenti le loro sperimentazioni. L HTTP è nato inizialmente

Dettagli

INFORMATICA DISTRIBUITA. lez 5 World Wide Web (cont)

INFORMATICA DISTRIBUITA. lez 5 World Wide Web (cont) INFORMATICA DISTRIBUITA prof. lez 5 World Wide Web (cont) Università degli Studi di Milano Scienze e Tecnologie della Comunicazione Musicale a.a. 2009-2010 Protocolli usabili nelle URL http: ftp: : http://www.dico.unimi.it/

Dettagli

Le tecnologie software Internet

Le tecnologie software Internet Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B B2_1 V1.7 Le tecnologie software Internet Standard aperti / Sun Java Il contenuto del documento è liberamente utilizzabile dagli studenti,

Dettagli

Le tecnologie software Internet

Le tecnologie software Internet Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B2_1 V1.7 Le tecnologie software Internet Standard aperti / Sun Java Il contenuto del documento è liberamente utilizzabile

Dettagli

Protocolli per il Web. Impianti Informatici. Protocolli applicativi

Protocolli per il Web. Impianti Informatici. Protocolli applicativi Protocolli per il Web Protocolli applicativi I protocolli applicativi 2 Applicazioni Socket interface HTTP (WEB) SMTP (E-MAIL) FTP... NFS RPC DNS... Trasporto TCP UDP Rete ICMP RIP OSPF IP ARP RARP Non

Dettagli

Architetture Web parte 2

Architetture Web parte 2 Architetture Web parte 2 Programmazione in Ambienti Distribuiti A.A. 2004-05 Sessione Un insieme di richieste, provenienti dallo stesso browser e dirette allo stesso server, confinate in un dato lasso

Dettagli

Database & WWW. Basi di dati Architetture e linee di evoluzione P. Atzeni, S. Ceri, P. Fraternali, S. Paraboschi, R. Torlone

Database & WWW. Basi di dati Architetture e linee di evoluzione P. Atzeni, S. Ceri, P. Fraternali, S. Paraboschi, R. Torlone Database & WWW Capitolo 4 Basi di dati Architetture e linee di evoluzione P. Atzeni, S. Ceri, P. Fraternali, S. Paraboschi, R. Torlone 1 Sommario Protocollo HTTP CGI Java Servlet Server-side scripting

Dettagli

Programmazione server-side: Java Servlet

Programmazione server-side: Java Servlet Programmazione server-side: Java Servlet Corso di Applicazioni Telematiche A.A. 2006-07 Lezione n.11 parte II Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Cos

Dettagli

L evoluzione delle Applicazioni Distribuite

L evoluzione delle Applicazioni Distribuite L evoluzione delle Applicazioni Distribuite Dai terminali a fosfori verdi al Client-Server a Internet Architettura basata su Mainframe thin client su 3270 a fosfori verde server TP-Monitor su Mainframe

Dettagli

Web e HTTP. path name. host name Realizzato da Roberto Savino. www.someschool.edu/somedept/pic.gif

Web e HTTP. path name. host name Realizzato da Roberto Savino. www.someschool.edu/somedept/pic.gif Web e HTTP Terminologia Una pagina web consiste di oggetti Un oggetto può essere un file HTML, una immagine JPG, ecc. Una pagina web consiste di un file HTML base che fa riferimento a diversi oggetti al

Dettagli

Siti web centrati sui dati (Data-centric web applications)

Siti web centrati sui dati (Data-centric web applications) Siti web centrati sui dati (Data-centric web applications) 1 A L B E R T O B E L U S S I A N N O A C C A D E M I C O 2 0 1 2 / 2 0 1 3 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente

Dettagli

Sicurezza delle applicazioni web: protocollo HTTP

Sicurezza delle applicazioni web: protocollo HTTP Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Anno Accademico 2009/2010 Sicurezza delle applicazioni web: protocollo HTTP Roberto Paleari roberto@security.dico.unimi.it

Dettagli

Capitolo 7. Sviluppi futuri. 7.1 Generazione automatica di pagine WML

Capitolo 7. Sviluppi futuri. 7.1 Generazione automatica di pagine WML Capitolo 7 Sviluppi futuri 7.1 Generazione automatica di pagine WML Con l avvento della tecnologia WAP/WML abbiamo constatato la necessità di avere a disposizione uno strumento che consenta, così come

Dettagli

Session tracking Session tracking HTTP: è stateless, cioè non permette di associare una sequenza di richieste ad un dato utente. Ciò vuol dire che, in generale, se un browser richiede una specifica pagina

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

Dettagli

Applicazioni web centrati sui dati (Data-centric web applications)

Applicazioni web centrati sui dati (Data-centric web applications) Applicazioni web centrati sui dati (Data-centric web applications) 1 ALBERTO BELUSSI ANNO ACCADEMICO 2009/2010 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente lo strumento di riferimento

Dettagli

Reti di Calcolatori. Master "Bio Info" Reti e Basi di Dati Lezione 2

Reti di Calcolatori. Master Bio Info Reti e Basi di Dati Lezione 2 Reti di Calcolatori Sommario Software di rete TCP/IP Livello Applicazione Http Livello Trasporto (TCP) Livello Rete (IP, Routing, ICMP) Livello di Collegamento (Data-Link) I Protocolli di comunicazione

Dettagli

Servlet API. Programmazione in Ambienti Distribuiti A.A. 2003-04

Servlet API. Programmazione in Ambienti Distribuiti A.A. 2003-04 Servlet API Programmazione in Ambienti Distribuiti A.A. 2003-04 Servlet Interfaccia Java che modella il paradigma richiesta/elaborazione/risposta tipico delle applicazioni lato server Presuppone l esistenza

Dettagli

Architetture Web I Server Web e gli Standard della Comunicazione

Architetture Web I Server Web e gli Standard della Comunicazione Architetture Web I Server Web e gli Standard della Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 27 Marzo 2012 Architetture Architetture Web Protocolli di Comunicazione Il Client Side

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Internet Architettura del www

Internet Architettura del www Internet Architettura del www Internet è una rete di computer. Il World Wide Web è l insieme di servizi che si basa sull architettura di internet. In una rete, ogni nodo (detto host) è connesso a tutti

Dettagli

Attacchi Web - Introduzione alla sicurezza nelle applicazioni Web

Attacchi Web - Introduzione alla sicurezza nelle applicazioni Web Attacchi Web Introduzione alla sicurezza nelle applicazioni Web Davide Marrone davide@security.dico.unimi.it Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento

Dettagli

Servlet e JDBC. Servlet e Web Server. Servlet e Web Server. Servlet e Web Server. Richieste. Servlet. Servlet:

Servlet e JDBC. Servlet e Web Server. Servlet e Web Server. Servlet e Web Server. Richieste. Servlet. Servlet: e JDBC Programmazione in Rete e Laboratorio Matteo Baldoni Dipartimento di Informatica Universita` degli Studi di Torino C.so Svizzera, 185 I-10149 Torino e : estensioni del Java API permettono di scrivere

Dettagli

Architetture Web I Server Web e gli Standard della Comunicazione

Architetture Web I Server Web e gli Standard della Comunicazione Architetture Web I Server Web e gli Standard della Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 1 Aprile 2014 Architetture Web I Server Web e gli Standard della Comunicazione Il Server

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

Tener traccia del client

Tener traccia del client Tener traccia del client Raramente un applicazione web è costituita da una singola pagina (risorsa). E utile quindi tener traccia dei client che si collegano per rendere più semplice lo sviluppo dell applicazione.

Dettagli

Laboratorio di reti II: Servlet

Laboratorio di reti II: Servlet Laboratorio di reti II: Servlet Stefano Brocchi brocchi@dsi.unifi.it 16 marzo, 2009 Stefano Brocchi Laboratorio di reti II: Servlet 16 marzo, 2009 1 / 34 Le servlet Una servlet è una classe Java eseguita

Dettagli

Esercitazione 8. Basi di dati e web

Esercitazione 8. Basi di dati e web Esercitazione 8 Basi di dati e web Rev. 1 Basi di dati - prof. Silvio Salza - a.a. 2014-2015 E8-1 Basi di dati e web Una modalità tipica di accesso alle basi di dati è tramite interfacce web Esiste una

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

Laboratorio di reti II: Java Server Pages

Laboratorio di reti II: Java Server Pages Laboratorio di reti II: Java Server Pages Stefano Brocchi brocchi@dsi.unifi.it 6 aprile, 2009 Stefano Brocchi Laboratorio di reti II: Java Server Pages 6 aprile, 2009 1 / 34 JSP - Java Server Pages Le

Dettagli

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Applicazioni e Architetture Internet 1 Introduzione Introduzione alle architetture a tre livelli Formati di dati per il Web HTML, XML, DTD 2 Componenti dei sistemi dataintensive Tre tipi separati di funzionalità:

Dettagli

Note pratiche sullo sviluppo di servlet (I)

Note pratiche sullo sviluppo di servlet (I) Note pratiche sullo sviluppo di servlet (I) Nel caso in cui sulla macchina locale (PC in laboratorio/pc a casa/portatile) ci sia a disposizione un ambiente Java (con compilatore) e un editor/ambiente di

Dettagli

Tecnologie di Sviluppo per il Web

Tecnologie di Sviluppo per il Web Tecnologie di Sviluppo per il Web Applicazioni Web J2EE: Java Servlet Parte a versione 3.1 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima pagina) G. Mecca

Dettagli

Sicurezza delle applicazioni web: protocollo HTTP

Sicurezza delle applicazioni web: protocollo HTTP Università degli Studi di Milano Facoltà di Scienze Matematiche, Fisiche e Naturali Sicurezza delle applicazioni web: protocollo HTTP Alessandro Reina Aristide Fattori

Dettagli

url uniform resource locator

url uniform resource locator url uniform resource locator m. patrignani nota di copyright questo insieme di slides è protetto dalle leggi sul copyright il titolo ed il copyright relativi alle slides (inclusi, ma non limitatamente,

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Accesso ai Dati Ing. Giuseppe D'Aquì Testi Consigliati Eclipse In Action Core J2EE Patterns - DAO [http://java.sun.com/blueprints/corej2eepatterns/patterns/dataaccessobject.html]

Dettagli

Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML

Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML Gianluca Moro gianluca.moro@unibo.it Dipartimento di Elettronica, Informatica e Sistemistica G. Moro - Università di Bologna World

Dettagli

Livello cinque (Livello application)

Livello cinque (Livello application) Cap. VII Livello Application pag. 1 Livello cinque (Livello application) 7. Generalità: In questo livello viene effettivamente svolto il lavoro utile per l'utente, contiene al suo interno diverse tipologie

Dettagli

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET)

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Ipotesi di partenza: concetti di base del networking Le ipotesi di partenza indispensabili per poter parlare di tecniche di accesso

Dettagli

Tecnologie di Sviluppo per il Web

Tecnologie di Sviluppo per il Web Tecnologie di Sviluppo per il Web Applicazioni Web J2EE: Struttura dell Applicazione versione 2.4 Questo lavoro è concesso in uso secondo i termini di una licenza Creative Commons (vedi ultima pagina)

Dettagli

Applicazioni web. Sommario. Parte 6 Servlet Java. Applicazioni web - Servlet. Alberto Ferrari 1. Servlet Introduzione alle API ed esempi

Applicazioni web. Sommario. Parte 6 Servlet Java. Applicazioni web - Servlet. Alberto Ferrari 1. Servlet Introduzione alle API ed esempi Applicazioni web Parte 6 Java Alberto Ferrari 1 Sommario Introduzione alle API ed esempi Tomcat Server per applicazioni web Alberto Ferrari 2 Alberto Ferrari 1 Java: da applet a servlet In origine Java

Dettagli

19. LA PROGRAMMAZIONE LATO SERVER

19. LA PROGRAMMAZIONE LATO SERVER 19. LA PROGRAMMAZIONE LATO SERVER Introduciamo uno pseudocodice lato server che chiameremo Pserv che utilizzeremo come al solito per introdurre le problematiche da affrontare, indipendentemente dagli specifici

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Assignment (1) - Varie

Assignment (1) - Varie Elementi di Sicurezza e Privatezza Laboratorio 6 - Vulnerabilità di applicazioni Web (1) Chiara Braghin chiara.braghin@unimi.it! Assignment (1) - Varie Al link http://www.dti.unimi.it/braghin/ elementi/lab/lista_consegnati.pdf

Dettagli

Elementi di Sicurezza e Privatezza Laboratorio 6 - Vulnerabilità di applicazioni Web (1) Chiara Braghin chiara.braghin@unimi.it!

Elementi di Sicurezza e Privatezza Laboratorio 6 - Vulnerabilità di applicazioni Web (1) Chiara Braghin chiara.braghin@unimi.it! Elementi di Sicurezza e Privatezza Laboratorio 6 - Vulnerabilità di applicazioni Web (1) Chiara Braghin chiara.braghin@unimi.it! Assignment (1) - Varie Al link http://www.dti.unimi.it/braghin/ elementi/lab/lista_consegnati.pdf

Dettagli

Introduzione al linguaggio Java: Servlet e JSP

Introduzione al linguaggio Java: Servlet e JSP Introduzione al linguaggio Java: Servlet e JSP Corso di Gestione della Conoscenza d Impresa A. A. 2006/2007 Dipartimento di Informatica Università degli Studi di Bari 1 Servlet e JSP: il contesto Un applicazione

Dettagli

Telematica II 7. Introduzione ai protocolli applicativi

Telematica II 7. Introduzione ai protocolli applicativi Indice Standard ISO/OSI e TCP/IP Telematica II 7. Introduzione ai protocolli applicativi Modello Client / Server I Socket Il World Wide Web Protocollo HTTP Corso di Laurea in Ingegneria Informatica A.A.

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.6 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

Dettagli

Framework di Middleware. per Architetture Enterprise

Framework di Middleware. per Architetture Enterprise Framework di Middleware per Architetture Enterprise Corso di Ingegneria del Software A.A.2011-2012 Un po di storia 1998: Sun Microsystem comprende l importanza del World Wide Web come possibile interfaccia

Dettagli

World Wide Web. Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML. Il Successo del Web. Protocolli di accesso

World Wide Web. Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML. Il Successo del Web. Protocolli di accesso Web e Server-side Computing: Richiami sulla tecnologia Web e FORM HTML Gianluca Moro gmoro@deis.unibo.it Dipartimento di Elettronica, Informatica e Sistemistica Università di Bologna World Wide Web nato

Dettagli

Tecniche Multimediali

Tecniche Multimediali Chiedersi se un computer possa pensare non è più interessante del chiedersi se un sottomarino possa nuotare Edsger Dijkstra (The threats to computing science) Tecniche Multimediali Corso di Laurea in «Informatica»

Dettagli

Server-side Programming: Java servlets Parte II

Server-side Programming: Java servlets Parte II Corso di Laurea Specialistica in Ingegneria Informatica Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni Corso di Reti di Applicazioni Telematiche a.a. 2009-2010 Server-side Programming:

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Indice generale. Parte I Anatomia del Web...21. Introduzione...xiii

Indice generale. Parte I Anatomia del Web...21. Introduzione...xiii Indice generale Introduzione...xiii Capitolo 1 La sicurezza nel mondo delle applicazioni web...1 La sicurezza delle informazioni in sintesi... 1 Primi approcci con le soluzioni formali... 2 Introduzione

Dettagli

Applicazioni Web, HTTP e REST. Matteo Vaccari http://matteo.vaccari.name/ Milano XP User Group, 3 ottobre 2007

Applicazioni Web, HTTP e REST. Matteo Vaccari http://matteo.vaccari.name/ Milano XP User Group, 3 ottobre 2007 Applicazioni Web, HTTP e REST Matteo Vaccari http://matteo.vaccari.name/ Milano XP User Group, 3 ottobre 2007 1 Applicazioni Web? Applicazione Web: un'applicazione clientserver in cui il client è un semplice

Dettagli

Architetture di sistema

Architetture di sistema Università di Bergamo Facoltà di Ingegneria Applicazioni Internet B Paolo Salvaneschi B1_1 V1.7 Architetture di sistema Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio

Dettagli

Contenuti. Applicazioni di rete e protocolli applicativi

Contenuti. Applicazioni di rete e protocolli applicativi Contenuti Architettura di Internet Principi di interconnessione e trasmissione World Wide Web Posta elettronica Motori di ricerca Tecnologie delle reti di calcolatori Servizi Internet (come funzionano

Dettagli

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

Corso di Informatica Modulo T3 B1 Programmazione web

Corso di Informatica Modulo T3 B1 Programmazione web Corso di Informatica Modulo T3 B1 Programmazione web 1 Prerequisiti Architettura client/server Elementi del linguaggio HTML web server SQL server Concetti generali sulle basi di dati 2 1 Introduzione Lo

Dettagli

Introduzione. Capitolo 9

Introduzione. Capitolo 9 Introduzione Capitolo 9 Applicazioni Internet Internet: Concetti di base Formati di dati per il Web HTML, XML, DTD Introduzione alle architetture a tre livelli Il livello di presentazione Moduli HTML:

Dettagli

Internet e Tecnologia Web

Internet e Tecnologia Web INTERNET E TECNOLOGIA WEB Corso WebGis per Master in Sistemi Informativi Territoriali AA 2005/2006 ISTI- CNR c.renso@isti.cnr.it Internet e Tecnologia Web...1 TCP/IP...2 Architettura Client-Server...6

Dettagli

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4)

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4) Architettura del WWW World Wide Web Sintesi dei livelli di rete Livelli di trasporto e inferiori (Livelli 1-4) - Connessione fisica - Trasmissione dei pacchetti ( IP ) - Affidabilità della comunicazione

Dettagli

SERVLET & JSP DISPENSE

SERVLET & JSP DISPENSE SERVLET & JSP DISPENSE PROGRAMMAZIONE LATO SERVER Un server deve rispondere alle richieste del client e permettere di visualizzare le pagine Web. Questo compito è svolto da un software ben definito, il

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

Tecnologie per il Web. Il web: Architettura HTTP HTTP. SSL: Secure Socket Layer

Tecnologie per il Web. Il web: Architettura HTTP HTTP. SSL: Secure Socket Layer Tecnologie per il Web Il web: architettura e tecnologie principali Una analisi delle principali tecnologie per il web Tecnologie di base http, ssl, browser, server, firewall e proxy Tecnologie lato client

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

Tecnologie e Programmazione Web

Tecnologie e Programmazione Web Presentazione 1 Tecnologie e Programmazione Web Html, JavaScript e PHP RgLUG Ragusa Linux Users Group SOftware LIbero RAgusa http://www.solira.org - Nunzio Brugaletta (ennebi) - Reti 2 Scopi di una rete

Dettagli

APPENDICE A Servlet e Java Server Page

APPENDICE A Servlet e Java Server Page APPENDICE A Servlet e Java Server Page A.1 Cosa è una Servlet e come funziona Una servlet è un particolare tipo di applicazione Java, in grado di essere eseguita all'interno di un web server e di estenderne

Dettagli

Sommario. Settimana - Gli elementi fondamentali... 1. Introduzione...xv. Giorno 1 - I linguaggi di markup...3

Sommario. Settimana - Gli elementi fondamentali... 1. Introduzione...xv. Giorno 1 - I linguaggi di markup...3 000B-XML-Somm.fm Page iii Wednesday, June 12, 2002 9:25 AM Sommario Introduzione...xv A chi si rivolge questo libro...xvi Convenzioni usate in questo libro...xvi Settimana - Gli elementi fondamentali...

Dettagli

Protocolli applicativi basati su TCP/IP

Protocolli applicativi basati su TCP/IP Protocolli applicativi basati su TCP/IP A.A. 2005/2006 Walter Cerroni Protocolli applicativi Sono i protocolli utilizzati dalle applicazioni per scambiarsi informazioni attraverso la rete Esempi: HTTP

Dettagli

Sviluppo di Applicazioni Web con Java 2 Enterprise Edition

Sviluppo di Applicazioni Web con Java 2 Enterprise Edition Sviluppo di Applicazioni Web con Java 2 Enterprise Edition Ivan Scagnetto Dipartimento di Matematica e Informatica http://www.dimi.uniud.it/scagnett scagnett@dimi.uniud.it Laboratorio di Tecnologie Lato

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Il World Wide Web. Il Servizio World Wide Web (WWW) WWW WWW WWW WWW. Storia WWW: obbiettivi WWW: tecnologie Le Applicazioni Scenari Futuri.

Il World Wide Web. Il Servizio World Wide Web (WWW) WWW WWW WWW WWW. Storia WWW: obbiettivi WWW: tecnologie Le Applicazioni Scenari Futuri. Il Servizio World Wide Web () Corso di Informatica Generale (Roberto BASILI) Teramo, 20 Gennaio, 2000 Il World Wide Web Storia : obbiettivi : tecnologie Le Applicazioni Scenari Futuri La Storia (1990)

Dettagli

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1 Gli XML Web Service Prof. Mauro Giacomini Medica 2008/2009 1 Definizioni i i i Componente.NET che risponde a richieste HTTP formattate tramite la sintassi SOAP. Gestori HTTP che intercettano richieste

Dettagli

Impianti di Elaborazione. Applicazioni e Servizi

Impianti di Elaborazione. Applicazioni e Servizi Impianti di Elaborazione Applicazioni e Servizi M.G. Fugini COMO IMPIANTI 08-09 Indice dei contenuti Servizi e risorse Internet (Telnet, FTP, Posta elettronica, News, Chat, Videoconferenza, ) World Wide

Dettagli

Capitolo 2 - parte 2. Corso Reti ed Applicazioni Mauro Campanella

Capitolo 2 - parte 2. Corso Reti ed Applicazioni Mauro Campanella Capitolo 2 - parte 2 Corso Reti ed Applicazioni Mauro Campanella La nascita del World Wide Web L idea fu nel 1989 di Tim Berners Lee, fisico del CERN di Ginevra. Vi era la necessità di far collaborare

Dettagli

Stack protocolli TCP/IP

Stack protocolli TCP/IP Stack protocolli TCP/IP Application Layer Transport Layer Internet Layer Host-to-Nework Layer DNS SMTP Telnet HTTP TCP UDP IP Insieme di eterogenei sistemi di rete... 1 Concetti base Differenza tra i concetti

Dettagli

Web Service SOAP e WSDL. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com

Web Service SOAP e WSDL. Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com Web Service SOAP e WSDL Tito Flagella tito@link.it Lorenzo Nardi nardi80@gmail.com SOAP Originariamente: Simple Object Access Protocol E poi evoluto in un Framework per lo scambio di messaggi in XML 2

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

Siti interattivi e dinamici. in poche pagine

Siti interattivi e dinamici. in poche pagine Siti interattivi e dinamici in poche pagine 1 Siti Web interattivi Pagine Web codificate esclusivamente per mezzo dell HTML non permettono alcun tipo di interazione con l utente, se non quella rappresentata

Dettagli

Tomcat & Servlet. Contenuti. Programmazione in Ambienti Distribuiti. Tomcat Applicazioni Web. Servlet JSP Uso delle sessioni

Tomcat & Servlet. Contenuti. Programmazione in Ambienti Distribuiti. Tomcat Applicazioni Web. Servlet JSP Uso delle sessioni Tomcat & Servlet Programmazione in Ambienti Distribuiti V 1.2 Marco Torchiano 2005 Contenuti Tomcat Applicazioni Web Struttura Sviluppo Deployment Servlet JSP Uso delle sessioni 1 Tomcat Tomcat è un contenitore

Dettagli

Introduzione alle Applicazioni Web

Introduzione alle Applicazioni Web Introduzione alle Applicazioni Web di Mary Ercolini Con il termine Applicazione Web si intende un applicazione risiedente in un Server Web alla quale si accede tramite un browser Internet o un altro programma

Dettagli

2.5. L'indirizzo IP identifica il computer di origine, il numero di porta invece identifica il processo di origine.

2.5. L'indirizzo IP identifica il computer di origine, il numero di porta invece identifica il processo di origine. ESERCIZIARIO Risposte ai quesiti: 2.1 Non sono necessarie modifiche. Il nuovo protocollo utilizzerà i servizi forniti da uno dei protocolli di livello trasporto. 2.2 Il server deve essere sempre in esecuzione

Dettagli

Posta Elettronica e Web

Posta Elettronica e Web a.a. 2002/03 Posta Elettronica e Web Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Posta Elettronica

Dettagli

Flavio De Paoli depaoli@disco.unimib.it

Flavio De Paoli depaoli@disco.unimib.it Flavio De Paoli depaoli@disco.unimib.it 1 Il web come architettura di riferimento Architettura di una applicazione web Tecnologie lato server: Script (PHP, Pyton, Perl), Servlet/JSP, ASP Tecnologie lato

Dettagli

OSOR. Applicazioni di Rete

OSOR. Applicazioni di Rete OSOR Applicazioni di Rete 1 Client-Server in Sistemi Distribuiti Host A Host B Client TCP/UDP IP Network Interface Internet Risultati Server TCP/UDP IP Network Interface Richiesta Applicazioni di Rete

Dettagli

JDBC versione base. Le classi/interfacce principali di JDBC

JDBC versione base. Le classi/interfacce principali di JDBC JDBC versione base Java Database Connectivity è il package Java per l accesso a database relazionali il package contiene interfacce e classi astratte uno dei pregi è la completa indipendenza del codice

Dettagli

Il Web, HTML e Java Corso di Laurea in Ingegneria Informatica Progetto S.C.E.L.T.E.

Il Web, HTML e Java Corso di Laurea in Ingegneria Informatica Progetto S.C.E.L.T.E. Il Web, HTML e Java Corso di Laurea in Ingegneria Informatica Progetto S.C.E.L.T.E. Università di Bologna Facoltà di Ingegneria Bologna, 08/02/2010 Outline Da applicazioni concentrate a distribuite Modello

Dettagli

Servizi web in LabVIEW

Servizi web in LabVIEW Servizi web in LabVIEW Soluzioni possibili, come si utilizzano. 1 Soluzioni possibili WEB SERVER Dalla versione 5.1 di LabVIEW è possibile implementare un Web server che consente di operare da remoto sul

Dettagli

Seminari Eucip, Esercizio e Supporto di Sistemi Informativi

Seminari Eucip, Esercizio e Supporto di Sistemi Informativi Seminari Eucip, Esercizio e Supporto di Sistemi Informativi Servizi di Dipartimento di Informtica e Sistemistica Università di Roma La Sapienza Sicurezza su Sicurezza della La Globale La rete è inerentemente

Dettagli