La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 0 Lezione 3b - 20 ottobre 2009 Il materiale didattico usato in questo corso è stato mutuato.

Presentazioni simili


Presentazione sul tema: "Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 0 Lezione 3b - 20 ottobre 2009 Il materiale didattico usato in questo corso è stato mutuato."— Transcript della presentazione:

1 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 0 Lezione 3b - 20 ottobre 2009 Il materiale didattico usato in questo corso è stato mutuato da quello utilizzato da Paolo Veronesi per il corso di Griglie Computazionali per la Laurea Specialistica in Informatica tenuto nellanno accademico 2008/09 presso lUniversità degli Studi di Ferrara. Paolo Veronesi Università degli Studi di Bari – Corso di Laurea Specialistica in Informatica Tecnologia dei Servizi Grid e cloud computing A.A. 2009/2010 Giorgio Pietro Maggi

2 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 1

3 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 2 Introduzione Esaminiamo in breve: HTTP (HyperText Transfer Protocol) An application-level protocol for distributed, collaborative, hypermedia information systems n La storia n Il funzionamento n Caching e autenticazione n I cookie

4 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 3 HTTP HTTP é un protocollo client-server generico e stateless utilizzato non solo per lo scambio di documenti ipertestuali, ma per una moltitudine di applicazioni, incluso name server e sistemi object-oriented distribuiti. Caratteristiche di HTTP sono la negoziazione del formato di dati, per lindipendenza del sistema dal formato di rappresentazione dei dati. Specifiche di politiche di caching sofisticate a seconda del tipo di connessione Specifiche di autenticazione dell'utente di varia sofisticazione.

5 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 4 Storia di HTTP HTTP è esistito in tre versioni: 0.9: un semplicissimo protocollo client-server di sola richiesta di risorse HTML, senza flessibilità né nella direzione, né nel formato delle risorse. Utilizzata nel primo prototipo WWW e nei primi server NCSA. 1.0 (RFC 1945): il protocollo diventa generico e definisce la statelessness, e definisce alcuni metodi anche per l'upload di dati. Utilizzato fino al (RFC 2068, 2069 e poi 2616, 2617): la versione attuale di HTTP, specifica meglio i meccanismi di caching, permette multi-homing e connessioni persistenti. HTTP-NG doveva essere la naturale evoluzione di HTTP, ma il WG IETF fallì miseramente nel raggiungere l'obiettivo, e l'evoluzione del protocollo si fermò. I cookie, originariamente proposti da Netscape, vennero descritti nellRFC 2109 e poi 2965). I lavori di WebDAV estendono di fatto HTTP, ma non generano una nuova versione del protocollo.

6 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 5 Alcune definizioni Client-server In HTTP esistono due ruoli specifici: il client attiva la connessione e richiede dei servizi. Il server accetta la connessione, nel caso identifica il richiedente, e risponde alla richiesta. Alla fine chiude la connessione. Protocollo generico HTTP è indipendente dal formato dati con cui vengono trasmesse le risorse. Può funzionare per documenti HTML come per binari, eseguibili, oggetti distribuiti o altre strutture dati più o meno complicate. Statelessness Il server non è tenuto a mantenere informazioni che persistano tra una connessione e la successiva sulla natura, identità e precedenti richieste di un client. Il client è tenuto a ricreare da zero il contesto necessario al server per rispondere.

7 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 6 Ruoli delle applicazioni HTTP HTTP è un protocollo di comunicazione piuttosto semplice, basato sulla comunicazione tra due applicazioni, il browser, che manda richieste di documenti, ed il server, che risponde. In realtà i ruoli sono un po più precisi: Client: unapplicazione che stabilisce una connessione HTTP, con lo scopo di mandare richieste. Server: unapplicazione che accetta connessioni HTTP, e genera risposte.

8 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 7 Ruoli delle applicazioni HTTP (2) User agent: Quel particolare client che inizia una richiesta HTTP (tipicamente un browser, ma può anche essere un bot). Un bot (abbreviazione di robot) è un'applicazione automatica che richiede e scarica pagine HTML e siti web per scopi vari: indicizzazione, catalogazione, verifica di correttezza sintattica, etc. E' uno user agent anche se non vi sono utenti che serve. Origin server: il server che possiede fisicamente la risorsa richiesta (è lultimo della catena)

9 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 8 Ruoli delle applicazioni HTTP (3) Proxy: Unapplicazione intermediaria che agisce sia da client che da server. Le richieste sono soddisfatte autonomamente, o passandole ad altri server, con possibile trasformazione, controllo, verifica. Gateway: unapplicazione che agisce da intermediario per qualche altro server. A differenza del proxy, il gateway riceve le richieste come fosse lorigin server: il client può non essere al corrente che si tratta del gateway. Tunnel: un programma intermediario che agisce da trasmettitore passivo di una richiesta HTTP. Il tunnel non fa parte della comunicazione HTTP, anche se può essere stato attivato da una connessione HTTP. In più è importante ricordare: Cache: memoria locale di un'applicazione e il sistema che controlla i meccanismi della sua gestione ed aggiornamento. Qualunque client o server può utilizzare una cache, ma non un tunnel.

10 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 9 La connessione HTTP (1) n La connessione HTTP è composta da una serie di richieste ed una serie corrispondente di risposte. n La differenza principale tra HTTP 1.0 e 1.1 è stata la possibilità di specificare coppie multiple di richiesta e risposta nella stessa connessione. n Le richieste possono essere messe in pipeline, ma le risposte debbono essere date nello stesso ordine delle richieste, poiché non è specificato un metodo esplicito di associazione.

11 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 10 La connessione HTTP (2) CS HTTP 0.9 open close open close open close CS HTTP 1.1 open close CS HTTP 1.1 con pipelining open close CS HTTP 1.0 open close open close open close (GET, POST, HEAD, PUT) (GET, POST, HEAD, PUT) (solo GET) (GET, POST, HEAD, PUT)

12 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 11 Connessioni persistenti e pipelining Le connessioni persistenti hanno diversi vantaggi: Richiedono meno connessioni TCP, con vantaggio per le CPU e per la rete Permettono di ridurre l'attesa della visualizzazione Permettono di gestire in maniera migliore gli errori Il pipelining è la trasmissione di più richieste senza attendere l'arrivo della risposta alle richieste precedenti Riduce ulteriormente i tempi di latenza, ottimizzando il traffico di rete, soprattutto per richieste che riguardano risorse molto diverse per dimensioni o tempi di elaborazione. E' fondamentale che le risposte vengano date nello stessso ordine in cui sono state fatte le richieste (HTTP non fornisce un meccanismo di riordinamento esplicito).

13 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 12 Il metodo GET Il più importante (ed unico in v. 0.9) metodo di HTTP è GET, che richiede una risorsa ad un server. Questo è il metodo più frequente, ed è quello che viene attivato facendo click su un link ipertestuale di un documento HTML, o specificando un URL nellapposito campo di un browser. GET è sicuro ed idempotente, e può essere: assoluto (normalmente, cioè quando la risorsa viene richiesta senza altre specificazioni), condizionale (se la risorsa fa match con un criterio indicato negli header If-match, If-modified-since, If-range, etc.) parziale (se la risorsa richiesta è una sottoparte di una risorsa memorizzata).

14 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 13 Il metodo HEAD Il metodo HEAD è simile al metodo GET, ma il server deve rispondere soltanto con gli header relativi, senza il corpo. HEAD è sicuro ed idempotente, e viene usato per verificare: la validità di un URI: la risorsa esiste e non è di lunghezza zero, laccessibilità di un URI: la risorsa è accessibile presso il server, e non sono richieste procedure di autenticazione del documento. la coerenza di cache di un URI: la risorsa non è stata modificata nel frattempo, non ha cambiato lunghezza, valore hash o data di modifica.

15 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 14 Il metodo POST Il metodo POST serve per trasmettere delle informazioni dal client al server, ma senza la creazione di una nuova risorsa. POST non è sicuro né idempotente, e viene usato per esempio per sottomettere i dati di una form HTML ad unapplicazione CGI sul server. Il server può rispondere positivamente in tre modi: 200 Ok: dati ricevuti e sottomessi alla risorsa specificata. E stata data risposta 201 Created: dati ricevuti, la risorsa non esisteva ed è stata creata 204 No content: dati ricevuti e sottomossi alla risorsa specificata. Non è stata data risposta.

16 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 15 Il metodo PUT Il metodo PUT serve per trasmettere delle informazioni dal client al server, creando o sostituendo la risorsa specificata. In generale, largomento del metodo PUT è la risorsa che ci si aspetta di ottenere facendo un GET in seguito con lo stesso nome. Largomento del metodo POST, invece, è una risorsa esistente a cui si aggiunge (es. come input) informazione. PUT è idempotente ma non sicuro, e comunque non offre nessuna garanzia di controllo degli accessi o locking. Per questo è nato il gruppo di lavoro WebDAV, che ha fornito una semantica sicura e collaborativa per il metodo PUT (tra le altre cose).

17 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 16 Gli header Gli header sono righe RFC822 che specificano caratteristiche generali della trasmissione dellentità trasmessa, della richiesta effettuata della risposta generata

18 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 17 Header generali Gli header generali si applicano solo al messaggio trasmesso e si applicano sia ad una richiesta che ad una risposta, ma non necessariamente alla risorsa trasmessa. Date: data ed ora della trasmissione MIME-Version: la versione MIME usata per la trasmissione (sempre 1.0) Transfer-Encoding: il tipo di formato di codifica usato per la trasmissione Cache-Control: il tipo di meccanismo di caching richiesto o suggerito per la risorsa Connection: il tipo di connessione da usare (tenere attiva, chiudere dopo la risposta, ecc. Via: usato da proxy e gateway.

19 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 18 Header dellentità Gli header dellentità danno informazioni sul body del messaggio, o, se non vi è body, sulla risorsa specificata. Content-Type: il tipo MIME dellentità acclusa. Questo header è obbligatorio in ogni messaggio che abbia un body. Content-Length: la lunghezza in byte del body. Obbligatorio, soprattutto se la connessione è persistente. Content-Encoding, Content-Language, Content-Location, Content-MD5, Content-Range: la codifica, il linguaggio, lURL della risorsa specifica, il valore di digest MD5 e il range richiesto della risorsa. Expires: una data dopo la quale la risorsa è considerata non più valida (e quindi va richiesta o cancellata dalla cache). Last-Modified: Obbligatorio se possibile. La data e lora dellultima modifica. Serve per decidere se la copia posseduta (es. in cache) è ancora valida o no.

20 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 19 Header della richiesta (1) Gli header della richiesta sono posti dal client per specificare informazioni sulla richiesta e su se stesso al server. User-Agent: una stringa che descrive il client che origina la richiesta; tipo, versione e sistema operativo del client, tipicamente. Referer: L'errore di spelling è dovuto a ragioni storiche (si direbbe Referrer) lURL della pagina mostrata allutente mentre richiede il nuovo URL. Se lURL è richiesto con altri metodi che non lattraversamento di un link es. digitando l'URL o selezionandolo dai bookmark, Referer deve essere assente. Referer viene usato per controllo sui percorsi degli utenti, utili nel caso di user profiling (che gusti ha il mio utente? Lo capisco dalla pagina da cui proviene) o pubblicità (il mio utente ha cliccato su un banner. A chi devo pagare i diritti?)

21 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 20 Header della richiesta (2) Host: Header obbligatorio in HTTP 1.1. Contiene il nome di dominio e la porta a cui viene fatta la connessione. L'URI posto nella riga di richiesta è soltanto la parte locale al server. Manda l'indicazione del nome del server o della porta acceduta. GET /beta.html HTTP/ Host: Se un server contiene più siti Web per scopi diversi, Host permette al server di distinguere il sito a cui la richiesta fa riferimento. Permette limplementazione di virtual hosting senza manipolazioni del routing e multi-addressing IP. From: lindirizzo di del richiedente. Si richiede che lutente dia la sua approvazione prima di inserire questo header nella richiesta.

22 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 21 Header della richiesta (3) Range: il range della richiesta. Poco usato. Accept, Accept-Charset, Accept-Encoding, Accept-Language: Implementazione della negoziazione del formato, per quel che riguarda tipo MIME, codice caratteri, codifica MIME, linguaggio umano. Il client specifica cosa è in grado di accettare, e il server propone il match migliore. If-Modified-Since, If-Unmodified-Since: richieste condizionali (per esempio, per aggiornare una cache) che vanno portate a termine solo se la condizione è vera. Se la pre-condizione è valida, viene ritornato un 304 (not modified), altrimenti si procede come per un GET normale. Authorization, Proxy-Authorization: una stringa di autorizzazione per laccesso alla risorsa richiesta. Ne parliamo oltre.

23 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 22 La risposta Version status-code reason-phrase CrLf [Header]* CrLf Body GET /index.html HTTP/1.1 Host: HTTP/ OK Date: Fri, 10 Apr :46:53 GMT Server: Apache/2.0.2 (Unix) Last-Modified: Mon, 5 Apr :55:37 GMT Accept-Ranges: bytes Content-Length: 3357 Content-Type: text/html ….

24 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 23 Status code Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta, e le altre due la risposta specifica. Esistono le seguenti classi: 1xx: Informational. Una risposta temporanea alla richiesta, durante il suo svolgimento. 2xx: Successful. Il server ha ricevuto, capito e accettato la richiesta. 3xx: Redirection. Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte del client per portare a termine la richiesta. 4xx: Client error. La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non autorizzata). 5xx: Server error. La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un problema interno (suo o di applicazioni CGI).

25 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 24 Esempi di status code 100Continue (se il client non ha ancora mandato il body) 200Ok (GET con successo) 201Created (PUT con successo) 301Moved permanently (URL non valida, il server conosce la nuova posizione 400Bad request (errore sintattico nella richiesta) 401Unauthorized (manca lautorizzazione) 403Forbidden (richiesta non autorizzabile) 404Not found (URL errato) 500Internal server error (tipicamente un CGI mal fatto) 501Not implemented (metodo non conosciuto dal server)

26 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 25 Header nella risposta La risposta contiene un body MIME che è introdotto da alcuni header e prosegue (se opportuno) con un body. Gli header sono o generali, o dell'entità (se viene fornito un body) e specifici della risposta. N.B.: Se viene fornita un'entità in risposta, devono esserci almeno le entità Content-type e Content-length. E' solo grazie al content type che lo user agent sa come visualizzare l'oggetto ricevuto. E' solo grazie al content length che lo user agent sa che ha ricevuto tutto l'oggetto richiesto.

27 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 26 Header della risposta Gli header della risposta sono posti dal server per specificare informazioni sulla risposta e su se stesso al client Server: una stringa che descrive il server: tipo, sistema operativo e versione. WWW-Authenticate: lheader di WWW-Authenticate include una challenge (codice di partenza) con cui il meccanismo di autenticazione deve fare match in caso di una risposta 401, (unauthorized). Il client genererà con questo valore un valore di autorizzazione posto nellheader Authorization della prossima richiesta. Accept-ranges: specifica che tipo di range può accettare (valori previsti: byte e none).

28 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 27 Autenticazione (1) Quando si vuole accedere ad una risorsa su cui esistono restrizioni di accesso, il server richiede l'autenticazione dell'utente. Al GET viene fornita la risposta 401 (unauthorized), più un header WWW-Authenticate che specifica i criteri con cui autenticarsi (metodo e parametri da usare). HTTP ha due metodi di autenticazione: Basic authentication (introdotto in HTTP 1.0) Digest access authentication (introdotto in HTTP 1.1)

29 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 28 Autenticazione (2) Basic authentication Introdotto da HTTP 1.0. L'header della prima risposta WWW-Authenticate contiene il contesto di sicurezza (realm) dell'autenticazione. Il client richiede le informazioni di autorizzazione all'utente e Il client crea una nuova richiesta GET e fornisce le informazioni di autorizzazione codificate in Base64. Il browser continua a mandare lo stesso header per tutte le pagine dello stesso realm. Problema: La password passa dunque in chiaro sulla rete.

30 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 29 Autenticazione (3) Digest access authentication Introdotto da HTTP 1.1, descritto in RFC 2069 e RFC Non manda la password in chiaro, ma una fingerprint della password, ovvero la password crittografata con il metodo MD5 (RFC 1321). Per evitare l'abuso della password, anche se crittografata, insieme alla fingerprint vengono codificate anche informazioni come lo username, il realm, l'URI richiesto, una time stamp, ecc.).

31 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 30 Caching (1) Può essere client-side, server-side o intermedia (su un proxy). La cache server-side riduce i tempi di computazione di una risposta, ma non ha effetti sul carico di rete. Le altre riducono il carico di rete. HTTP 1.0 si basava su tre header: Expires: il server specifica la data di scadenza di una risorsa If-Modified-Since: il client richiede la risorsa solo se modificata dopo il giorno X. Richiede una gestione del tempo comune tra client e server Pragma: no-cache: Fornita dal server, istruisce il client di non fare cache della risorsa in ogni caso. HTTP 1.1 introduce due tipi di cache control: Server-specified expiration Heuristic expiration

32 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 31 Caching (2) Server-specified expiration Il server stabilisce una data di scadenza della risorsa, con l'header Expires o con la direttiva max-age nell'header Cache-Control Se la data di scadenza è già passata, la richiesta deve essere rivalidata. Se la richiesta accetta anche risposte scadute, o se l'origin server non può essere raggiunto, la cache può rispondere con la risorsa scaduta ma con il codice 110 (Response is stale) Se Cache-Control specifica la direttiva must-revalidate, la risposta scaduta non può mai essere rispedita. In questo caso la cache deve riprendere la risorsa dall'origin server. Se questo non risponde, la cache manderà un codice 504 (Gateway time-out) Se Cache-Control specifica la direttiva no-cache, la richiesta deve essere fatta sempre all'origin server.

33 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 32 Caching (3) Heuristic expiration Poiché molte pagine non conterranno valori espliciti di scadenza, la cache stabilisce valori euristici di durata delle risorse, dopo le quali assume che sia scaduta. Queste assunzioni possono a volte essere ottimistiche, e risultare in risposte scorrette. Se non valida con sicurezza una risposta assunza fresca, allora deve fornire un codice 113 (heuristic expiration) alla risposta.

34 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 33 Modelli di sicurezza (1) Ci sono due modi per fornire un trasporto sicuro (cioè non intercettabile da orecchie maliziose durante la trasmissione): Usare un'infrastruttura di trasporto sicura Il protocollo non cambia, ma ogni pacchetto trasmesso nello scambio di informazioni viene gestito in maniera sicura dal protocollo di trasporto Usare un protocollo sicuro a livello applicazione Si usa un protocollo anche diverso, che si occupa di gestire la trasmissione delle informazioni.

35 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 34 Modelli di sicurezza (2) HTTPS (RFC 2818) Introdotto da Netscape, trasmette i dati in HTTP semplice su un protocollo di trasporto (SSL) che crittografa tutti i pacchetti. Il server ascolta su una porta diversa (per default la porta 443), e si usa uno schema di URI diverso (introdotto da https:// ) S-HTTP (RFC 2660) Poco diffuso, incapsula richieste e risposte HTTP in un messaggio crittografato secondo o un formato MIME apposito (MIME Object Security Services, MOSS), o un formato terzo (Cryptographic Message Syntax, CMS). E' più efficiente ma più complesso.

36 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 35 I cookies HTTP è stateless: non esiste nessuna struttura ulteriore alla connessione, e il server non è tenuto a mantenere informazioni su connessioni precedenti. Un cookie (non in HTTP, è unestensione di Netscape, proposta nellRFC 2109 e poi ancora RFC 2965) è una breve informazione scambiata tra il server ed il client. Il client mantiene lo stato di precedenti connessioni, e lo manda al server di pertinenza ogni volta che richiede un documento. Il termine cookie (anche magic cookie) in informatica indica un blocco di dati opaco (i.e.: non interpretabile) lasciato in consegna ad un richiedente per poter ristabilire in seguito il suo diritto alla risorsa richiesta (come il tagliando di una lavanderia)

37 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 36 Architettura dei cookie (1) Alla prima richiesta di uno user-agent, il server fornice la risposta ed un header aggiuntivo, il cookie, con dati arbitrari, e con la specifica di usarlo per ogni successiva richiesta. Il server associa a questi dati ad informazioni sulla transazione. Ogni volta che lo user-agent accederà a questo sito, rifornirà i dati opachi del cookie che permettono al server di riidentificare il richiedente, e creare così un profilo ottimale. Di particolare importanza sono la valutazione dei cookie da siti complessi (che comprendono molti domini) e l'uso di cookie di terze parti (ad esempio associati a banner o cose così).

38 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 37 Architettura dei cookies (2) client server HTTP applicazione CGI request Output + cookie Risposta + Set-Cookie request + Cookie Output Risposta genera il cookie analizza il cookie

39 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 38 Architettura dei cookies (3) I cookies dunque usano due header, uno per la risposta, ed uno per le richieste successive: Set-Cookie: header della risposta, il client può memorizzarlo e rispedirlo alla prossima richiesta. Cookie: header della richiesta. Il client decide se spedirlo sulla base del nome del documento, dellindirizzo IP del server, e delletà del cookie.

40 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 39 Architettura dei cookies (4) I cookies contengono le seguenti informazioni: Comment: stringa leggibile di descrizione del cookie. Domain: il dominio per cui il cookie è valido Max-Age: La durata in secondi del cookie. Path: lURI per il quale il cookie è valido Secure: la richiesta che il client contatti ilo server usando soltanto un meccanismo sicuro (es. SHTTP) per spedirlo Version: La versione della specifica a cui il cookie aderisce.

41 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 40 Conclusioni HTTP Abbiamo parlato di Protocollo HTTP Meccanismo di gestione dello stato in HTTP (cookie)

42 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 41 Riferimenti Wildes WWW, capitolo 3 Altri testi: n T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945, May 1996 n D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC 2965, October 2000 n R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999 n D. Kristol, HTTP Cookies: Standards, privacy, and Politics, ACM Transactions on Internet Technologies, 1(2), November 2001

43 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 42 Introduction to XML eXtensible Markup Language

44 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 43 Introduzione Qui esaminiamo alcuni aspetti di XML, in particolare sintattici e di filosofia d'uso: Vantaggi di XML Applicazioni XML Sintassi dei DTD Elementi Attributi Entità Altre caratteristiche sintattiche di XML XML e Whitespace

45 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 44 XML XML (Extensible Markup Language [sic!]) è un meta- linguaggio di markup, progettato per lo scambio e la interusabilità di documenti strutturati su Internet. XML prevede una sintassi semplificata rispetto a SGML, e definisce contemporaneamente una serie piuttosto lunga di linguaggi associati: uno per i link, uno per i nomi di tag, uno per i fogli di stile, uno per la descrizione di meta- informazioni, ecc. XML si propone di integrare, arricchire e, nel lungo periodo, sostituire HTML come linguaggio di markup standard per il World Wide Web.

46 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 45 Perché XML? HTML nacque come un DTD di SGML (non proprio!!!), che permetteva di mettere in rete documenti di un tipo molto specifico, semplici documenti di testo con qualche immagine e dei link ipertestuali. Con il successo del WWW, HTML venne iniziato ad usare per molti scopi, molti più di quelli per cui era stato progettato. Si iniziò ad abusare dei tag di HTML per gli effetti grafici che forniva, più che per gli aspetti strutturali o semantici. Si iniziarono a desiderare elaborazioni sofisticate sui dati HTML, elaborazioni che non era possibile fornire. Si iniziò a trovare limitata la capacità grafica di HTML, anche abusando dei tag.

47 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 46 Perché non SGML? SGML ha molti pregi, ma ha dalla sua una complessità duso e di comprensione notevole. Inoltre, a SGML mancano caratteristiche di notevole importanza per luso pratico, come link ipertestuali e specifiche grafiche. Lavvento di HTML ha fatto capire come i linguaggi di markup siano ormai maturi per essere compresi dal largo pubblico, ma che la semplicità duso di HTML doveva costituire un elemento di partenza. XML contiene tutte le caratteristiche di SGML che servono per creare applicazioni generali senza scendere nel livello di dettaglio e pedanteria richiesti da SGML.

48 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 47 I vantaggi di XML (1) Documenti auto-descrittivi La scelta dei nomi degli elementi può essere fatta per facilitare la comprensione del ruolo strutturale dellelemento. Inoltre, luso di un DTD può esplicitare le regole di composizione ed i rapporti possibili tra le varie parti dei documenti. Struttura navigabile dei documenti La rigida struttura ad albero e lassenza di regole di minimizzazione rendono semplice la visualizzazione e lanalisi della struttura del documento, e la possibilità di visualizzare il documento è indipendente dal foglio di stile che vi si applica.

49 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 48 I vantaggi di XML (2) Platform-independence XML è uno standard aperto, e chiunque può realizzare strumenti che lo usino come formato di dati. Facile convertibilità a formati Web La totale interdipendenza tra XML, SGML, HTML etc. fa sì che la conversione tra formati interni e formati per il Web sia facile.

50 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 49 I vantaggi di XML (3) Strutturazione gerarchica dei documenti Esistono molti formati di dati generici per l'intescambio di dati, ma sono tutti organizzati linearmente. XML permette strutture ad albero. Ripetibilità degli elementi XML permette di definire formalmente elementi ripetibili. Questo permette strutture più flessibili e complesse di altri formati di dati Content model misti XML trova un punto di equilibrio tra i formati dati per l'interscambio di dati e i formati per la strutturazione di documenti di testo. I content model misti (elementi che possono contenere sia altri elementi che testo) infatti permettono di inserire caratterizzazioni semantiche non soloper interi elementi, ma anche all'interno di elementi di testo contenitori (ad esempio, i paragrafi).

51 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 50 Quali applicazioni XML? Data Interchange Ogni volta che più programmi si debbono scambiare dati, ci sono problemi di compatibilità. Ogni programma ha le proprie assunzioni in termini di caratteri, separatori, ripetibilità di elementi, differenza tra elementi vuoti e assenti, ecc. XML si propone come la sintassi intermedia più semplice per esprimere dati anche complessi in forma indipendente dallapplicazione che li ha creati. Document publishing XML è ideale come linguaggio per esprimere documenti strutturati o semi strutturati, e per esprimerli in maniera indipendente dalla loro destinazione finale. Lo stesso documento XML può essere preso e trasformato per la stampa, il Web, il telefonino, lautoradio.

52 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 51 Cosa si fa con XML? (1) n Applicazioni che richiedono che il client Web si ponga a mediare tra due o più database eterogenei n Applicazioni che distribuiscono una parte significativa del carico computazionale dal server al client n Applicazioni che richiedono che il client Web presenti view diverse degli stessi dati agli utenti n Applicazioni in cui agenti Web intelligenti adattano la scoperta di informazioni alle esigenze degli specifici utenti. Da J. Bosak, XML, Java, and the future of the Web,

53 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 52 Cosa si fa con XML? (2) Accesso a database eterogenei Ogni volta che è necessario trasferire dei dati da un database allaltro, la soluzione più economica a tuttoggi è stampare i dati dal primo DB su carta e ribatterli a mano sul secondo. Idealmente io vorrei accedere via Web ai dati del primo DB, selezionare quelli che voglio in una cartella, e sbattere la cartella sul secondo DB, che si preoccupa di adattarli alle sue esigenze. Il secondo DB, dunque, deve essere in grado di comprendere la sintassi dei dati, di interpretare la struttura (eventualmente, in parte, aiutato da un essere umano) e di isolare le informazioni di suo interesse. Per questo potrebbe essere aiutato da un formato di interscambio tipo XML, che permetterebbe di etichettare i dati esplicitamente ed in maniera generale e comprensibile agli esseri umani.

54 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 53 Cosa si fa con XML? (3) Computazioni client-side Esistono molte esigenze di testing e computazione su oggetti descrivibili parametricamente: Caratteristiche e funzionalità di chip, semilavorati, e prodotti industriali Scheduling in aerei, treni, ecc. Shopping on-demand, e user-tailoring Applicazioni per il customer suppot In tutti questi casi, attualmente si creano applicazioni server-side che interrogano i database per i parametri e usano cicli del server per le computazioni, mentre i client sono in attesa. Poter esprimere in Java o altri linguaggi client-side la logica della computazione, che scarica i parametri dal sito giusto ed esegue le computazioni indipendentemente, sarebbe molto comodo, e permetterebbe confronti incrociati e ogni altro tipo di valutazione ottimale per le esigenze di chi compra.

55 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 54 Cosa si fa con XML? (4) Viste selettive Lesempio tipico è lindice sommario dinamico di un documento: interrogo una base documentaria e ottengo il primo livello di indice di un documento. Seleziono una voce e ri-interrogo la base dati per avere il secondo livello dellindice. Ogni espansione richiede un passaggio al server, con ovvi problemi di latenza. Sarebbe possibile fare tutto client-side con Javascript, ma o si fa lindice a mano del documento HTML, oppure bisogna ricorrere a documenti ben strutturati, come XML. Altri esempi: Un grafico che si trasforma in una tabella Un documento annotato in cui vedo il contenuto, o le annotazioni, o tutti e due Un manuale di due versioni dello stesso sistema, con testi e immagini che cambiano a seconda di quale specifica versione si sta esaminando.

56 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 55 Cosa si fa con XML? (5) Agenti Web (ora: Web applications) Mattew Fuchs (Disney Imagineering): Data needs to know about itself, and data needs to know about me Agenti di filtro, selezione, rilevamento hanno bisogno di sapere le caratteristiche dei dati che stanno filtrando in maniera vendor- independent, ben strutturata e flessibile (nuove esigenze, categorie, comunità virtuali, sub-società si formano continuamente) Ad esempio, bot personalizzati, la guida dei canali TV, i sistemi di classificazione del contenuto delle pagine Web, ecc.

57 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 56 Quando scegliere XML? (1) Quali sono le condizioni per adottare XML in un progetto? Ovviamente: E nuovo E di moda E compatibile con Web e con.NET Può essere imposto dal committente Può essere imposto dai partner Ma ci sono almeno quattro buone ragioni per XML: Produzione di documenti automatici Gestione indipendente di produzione e uso di dati Elaborazione di dati con aspetti strutturali complessi Elaborazione di dati strutturati in contenitori semi-strutturati

58 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 57 Quando scegliere XML? (2) Produzione di documenti automatici XML è la soluzione in assoluto più elegante (anche se ad oggi ancora faticosa) per integrare collezioni di dati strutturati sul Web. Documenti dinamici, che mescolano blocchi testuali con output tabellari di informazioni strutturate, sono facilmente esprimibili in XML, e gli strumenti attuali si concentrano su questo, per il momento. Integra e sostituisce le tecnologie server-side di accesso ai dati: ASP, PHP, server-side Javascript, ecc.

59 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 58 Quando scegliere XML? (3) Gestione indipendente di produzione ed uso di dati Spesso linterscambio di dati avviene allinterno di un workflow controllato e noto. In questo caso, data producers e data consumers sono creati ad hoc per lo specifico flusso informativo. XML è una complicazione inutile. Tuttavia esistono delle situazioni in cui non cè progettazione integrata di producer e consumer. In questo caso, unadeguata progettazione del producer facilita molto il lavoro di tutti i possibili consumer XML è strutturato, auto-esplicativo, enfatizza la descrizione del dato più che del suo scopo nella elaborazione. E quindi ideale per le situazioni in cui lelaborazione non è nota in anticipo.

60 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 59 Quando scegliere XML? (4) Elaborazione di dati con aspetti strutturali complessi I database utilizzano le relazioni per ogni tipo di esigenza: dalla descrizione di connessioni logiche tra entità concettualmente diverse, alla gestione di dati strutturati in maniera complessa. Ad esempio, è complicato gestire, in una tabella, record con un numero variabile di campi, o situazioni alternative complesse. XML prevede strutture con blocchi ripetuti, alternativi, facoltativi. La descrizione di queste strutture in XML è molto più naturale che con DB relazionali.

61 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 60 Quando scegliere XML? (5) Elaborazione di dati in contenitori semi-strutturati A volte linformazione ha uno stato naturale semi-strutturato (e.g., documenti testuali), al cui interno esistono informazioni atomiche su cui è necessario attivare computazioni. La soluzione classica è di estrarre le informazioni atomiche, metterle in un DB tradizionale, e buttare via il contenitore naturale. Questo ha il grosso difetto di eliminare il contesto e omogeneizzare in maniera forzata informazioni organizzate diversamente. XML permette di inserire allinterno di strutture documentarie (pensate per la visualizzazione) tag di natura descrittiva utilizzabili per elaborazioni sofisticate.

62 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 61 Cosa cè con XML? XML è in realtà una famiglia di linguaggi, alcuni già definiti, altri in corso di completamento. Alcuni hanno lambizione di standard, altri sono solo proposte di privati o industrie interessate. Alcuni hanno scopi generali, altri sono applicazioni specifiche per ambiti ristretti. XML 1.0: un meta-linguaggio di markup DTD: specifica di vincoli di correttezza su documenti XML XSLT: trasformazione di documenti XML XML-Schema:specifica di vincoli sofisticati di correttezza su documenti XML RDF: specifica di meta-informazioni machine-processable DOM, SAX: modelli e strutture dati per la programmazione SOAP, WSDL, UDDI: linearizzazione di strutture dati e loro dichiarazione per dati di interscambio tra applicazioni Migliaia di proposte di vocabolari con lo scopo di standardizzare linguaggi, processi e servizi in ambiti specializzati: TEI, RSS, News-ML, Math-ML, CML, ebXML, cXML, etc.

63 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 62 Uno sguardo d'insieme XML NS XPath XLink XSLT XSLFO XML Schema DOM Java, C, C++, PHP, ASP, Perl, Javascript, VBscript SGML HTML XHTML CSS URI XPointer browser print SOAP Web Services

64 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 63 XML 1.0 n Una raccomandazione W3C del 10 febbraio n È definita come un sottoinsieme di SGML n URL ufficiale: Traduzione ufficiale in italiano: n Molto più formalizzata della grammatica di SGML, usa una notazione formale, Extended Backus-Naur Form.

65 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 64 Criteri di progettazione di XML (1) Nel documento ufficiale di XML si elencano i seguenti obiettivi progettuali di XML: 1. XML deve essere utilizzabile in modo diretto su Internet. Non significa che deve essere possibile usarlo sul browser del giorno. Significa che si dovevano tenere in conto le esigenze di applicazioni distribuite su reti a larga scala. 2. XML deve supportare un gran numero di applicazioni. Cioè XML non si limita al supporto di documenti in rete, ma a una larga classe di applicazioni che non centrano con la rete. Specificamente: deve essere possibile creare applicazioni come tool di authoring, filtri, formattatori, e traduttori.

66 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 65 Criteri di progettazione di XML (2) 3. XML deve essere compatibile con SGML Tool SGML esistenti debbono essere in grado di leggere e scrivere documenti XML Istanze XML debbono essere istanze SGML così come sono, senza traduzioni, per quanto semplici. Dato un documento XML, deve essere possibile generare un DTD SGML tale per cui un tool SGML esegue lo stesso parsing di un tool XML. XML deve avere essenzialmente lo stesso potere espressivo di SGML. Questi goal sono stati sostanzialmente raggiunti.

67 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 66 Criteri di progettazione di XML (3) 4. Deve essere facile lo sviluppo di programmi che elaborino documenti XML Deve essere possibile creare applicazioni XML utili che non dipendano dal leggere ed interpretare il DTD Obiettivo dichiarato: un diplomato in informatica deve essere in grado di scrivere un processore minimale XML in meno di una settimana. 5. Il numero di caratteristiche opzionali deve essere mantenuto al minimo possibile, idealmente a zero. SGML, per generalità, aveva adottato un numero molto alto di caratteristiche opzionali, di dubbia utilità, o molto specifiche Risultato: ogni processore SGML implementava solo una parte delle caratteristiche opzionali, e quindi documenti SGML conformi che potevano essere letti da un processore SGML non venivano letti da un altro, e viceversa.

68 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 67 Criteri di progettazione di XML (4) 6. I documenti XML dovrebbero essere leggibili da umani e ragionevolmente chiari. Formati testuali sono più aperti, più utili, più gradevoli da lavorarci che formati binari. Inoltre, per quanti capricci possa fare il tuo editor specializzato XML, puoi sempre aprire il documento con un editor di testi e rimettere a posto le cose. 7. La specifica del linguaggio XML deve avvenire rapidamente. La paura era che le esigenze di estensibilità del Web potessero essere soddisfatte da una qualche combinazione di complicati formati binari e di accrocchi proprietari. Es: DHTML!

69 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 68 Criteri di progettazione di XML (5) 8. La progettazione XML deve essere formale e concisa. La specifica di SGML è composta di un documento di oltre 300 pagine in stile ottuso e burocratico. Il manuale SGML ne richiede più di 600, e comunque non è leggibile facilmente. Inoltre non è neanche immediatamente utilizzabile da un programmatore per realizzare tool (poche definizioni formali, difficile dedurre la grammatica del linguaggio). La scelta di formalismi nitidi e pochi commenti ha permesso la creazione di una specifica XML notevolmente più corta (~40 pagg.) e immediatamente utilizzabile dai realizzatori di tool (sintassi BNF). 9. I documenti XML devono essere facili da creare. In particolare, deve essere facile creare tool di authoring di documenti XML.

70 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 69 Criteri di progettazione di XML (6) 10. Non ha importanza l'economicità del markup XML. Le esigenze di economicità di markup (terseness) di SGML avevano portato alladozione di molte pratiche di minimizzazione dei caratteri, che però rendevano i documenti poco leggibili e molto più complicati da parsare. XML non ha meccanismi di minimizzazione, e dove si poteva scegliere tra economicità e chiarezza, si è scelta la chiarezza. Esistono poi due obiettivi progettuali non riportati: A. Supporto per linternazionalizzazione XML deve funzionare con tutti i set di caratteri. B. Desperate Perl hacker Il programmatore a cui viene imposto di eseguire un compito di modifica globale su una grande quantità di documenti e che riesce a farla applicando un qualche script semplice sulla struttura pulita dei documenti XML.

71 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 70 XML e Unicode XML (come Java) abbandona completamente ASCII e le codifiche ad un byte, e si basa direttamente su Unicode. Questo porta a due vantaggi nei riguardi dellinternazionalizzazione: È possibile scrivere documenti misti, senza ricorrere a trucchi strani per identificare la parte che usa un alfabeto dalla parte che ne adopera un altro. Un documento scritto in un linguaggio non latino non deve basarsi su parametri esterni per essere riconosciuto come tale, ma la codifica stessa dei caratteri lo identifica.

72 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 71 Sintassi dei DTD n Una precisazione : Entità generali : Entità parametriche n Altre caratteristiche di XML

73 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 72 La dichiarazione di tipo Il è la dichiarazione del tipo di documento. Essa permette alle applicazioni SGML di determinare le regole sintattiche da applicare alla verifica e validazione del documento. n La dichiarazione non è, ma contiene o fa riferimento alla Document Type Definition, o DTD, ove vengono elencati gli elementi validi e i loro vincoli. n Il DTD può essere posto in un file esterno, internamente al documento, o in parte esternamente ed in parte internamente. n N.B.: In XML il nome del DOCTYPE deve essere il nome del tag radice.

74 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 73 Dichiarazione del DTD: n La prima forma di dichiarazione indica che il DTD è contenuto in un file esterno (per esempio, condivisa con altri documenti). Il DTD viene chiamato external subset perché è posto in un file esterno. n La seconda forma precisa il DTD internamente (cioè nello stesso file), che quindi non può essere condiviso da altri file. Il DTD si chiama in questo caso internal subset. n La terza forma precisa una parte del DTD come contenuta in un file esterno (e quindi condivisibile con altri documenti), e una parte come propria del documento, e non condivisibile.

75 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 74 Dichiarazione XML (1) n Un documento XML può includere una dichiarazione XML. Questa specifica le caratteristiche opzionali del documento in questione. Poiché esse sono ridotte al minimo, la dichiarazione XML è brevissima. n La sintassi usata per la dichiarazione XML è quella delle Processing Instructions, n La non obbligatorietà della dichiarazione XML è dovuta a motivi di convenienza, per poter usare la grande quantità di documenti HTML e SGML che sono ben formati senza richiedere modifiche anche stupide. In assenza di dichiarazione XML, si assume la forma:

76 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 75 Dichiarazione XML (2) Esistono esattamente tre valori che possono essere messi in una dichiarazione XML: Il parametro version identifica quale versione di XML si sta usando. Per il momento, lunico valore possibile è 1.0. Necessario. Il parametro encoding permette di specificare, se il dubbio può sorgere, quale codifica di caratteri viene usata per il documento. Facoltativo. Il parametro standalone permette di specificare se tutto il contenuto del documento è interno alla risorsa o se ne esiste parte anche all'esterno (ad esempio in un'entità posta nel DTD esterno). Facoltativo. Se è assente è false.

77 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 76 Anatomia di un elemento Use a hyphen: ­. Start-tag ContentEnd-tag Element Element Type Attribute Name Attribute Value Attribute (Character) Entity Reference Element Type

78 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 77 Documenti ben formati o validi XML distingue due tipi di documenti rilevanti per le applicazioni XML: i documenti ben formati ed i documenti validi. In SGML, un DTD è necessario per la validazione del documento. Anche in XML, un documento è valido se presenta un DTD ed è possibile validarlo usando il DTD. Tuttavia XML permette anche documenti ben formati, ovvero documenti che, pur essendo privi di DTD, presentano una struttura sufficientemente regolare e comprensibile da poter essere controllata.

79 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 78 Documenti XML ben formati Un documento XML si dice ben formato se: Tutti i tag di apertura e chiusura corrispondono e sono ben annidati Esiste un elemento radice che contiene tutti gli altri I tag vuoti (senza contenuto) utilizzano un simbolo speciale di fine tag: Tutti gli attributi sono sempre racchiusi tra virgolette Tutte le entità sono definite.

80 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 79 Parser validanti e non validanti n Il cuore di un applicazione XML è il parser, ovvero quel modulo che legge il documento XML e ne crea una rappresentazione interna utile per successive elaborazioni (come la visualizzazione). n Un parser validante, in presenza di un DTD, è in grado di verificare la validità del documento, o di segnalare gli errori di markup presenti. n Un parser non validante invece, anche in presenza di un DTD è solo in grado di verificare la buona forma del documento. n Un parser non validante è molto più semplice e veloce da scrivere, ma è in grado di fare meno controlli. In alcune applicazioni, però, non è necessario validare i documenti, solo verificare la loro buona forma.

81 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 80 XML in HEP Configuration files Detector geometry description Standard is evolving Schema for introspection and persistency LCG Dictionary through gcc-xml Data interchange AIDA XML standards for Data Analysis related items Histograms (binned and unbinned), Vectors of data, Ntuples, Functions and Fits

82 Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 81 Links WWW consortium with lots of further links ! XML – development


Scaricare ppt "Tecnologia dei Servizi Grid e cloud computing - Lezione 003b 0 Lezione 3b - 20 ottobre 2009 Il materiale didattico usato in questo corso è stato mutuato."

Presentazioni simili


Annunci Google