Transcript Lezione 001 6 Aprile 2009

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 [email protected], http://www.ba.infn.it/~maggi
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 nell’anno
accademico 2008/09 presso l’Università degli Studi di Ferrara.
Paolo Veronesi
[email protected], [email protected]
http://www.cnaf.infn.it/~pveronesi/unife/
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
0
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
1
Introduzione
 Esaminiamo
in breve:
 HTTP (HyperText Transfer Protocol)
 An application-level protocol for distributed, collaborative,
hypermedia information systems

La storia

Il funzionamento

Caching e autenticazione

I cookie
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
2
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 l’indipendenza 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
3
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 1998-99
1.1 (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
nell’RFC 2109 e poi 2965).
I lavori di WebDAV estendono di fatto HTTP, ma non generano una
nuova versione del protocollo.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
4
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
5
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: un’applicazione che stabilisce una
connessione HTTP, con lo scopo di mandare
richieste.
Server: un’applicazione che accetta connessioni
HTTP, e genera risposte.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
6
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 (è l’ultimo della catena)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
7
Ruoli delle applicazioni HTTP (3)



In

Proxy: Un’applicazione 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: un’applicazione che agisce da intermediario per qualche altro
server. A differenza del proxy, il gateway riceve le richieste come fosse l’origin
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.
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
8
La connessione HTTP (1)



La connessione HTTP è composta da una serie di
richieste ed una serie corrispondente di risposte.
La differenza principale tra HTTP 1.0 e 1.1 è stata la
possibilità di specificare coppie multiple di richiesta e
risposta nella stessa connessione.
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
9
La connessione HTTP (2)
HTTP 0.9
C
S
HTTP 1.0
C
S
open
open
close
open
close
open
close
open
close
open
HTTP 1.1
HTTP 1.1 con
pipelining
C
S C
S
open
open
close
close
close
(solo GET)
close
(GET, POST,
HEAD, PUT)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
(GET, POST,
HEAD, PUT)
(GET, POST,
HEAD, PUT)
10
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).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
11
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 nell’apposito 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).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
12
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,
l’accessibilità 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
13
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 un’applicazione
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
14
Il metodo PUT
Il
metodo PUT serve per trasmettere delle informazioni dal client al
server, creando o sostituendo la risorsa specificata.
In generale, l’argomento del metodo PUT è la risorsa che ci si aspetta
di ottenere facendo un GET in seguito con lo stesso nome. L’argomento
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).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
15
Gli header
Gli
header sono righe RFC822 che specificano
caratteristiche




generali della trasmissione
dell’entità trasmessa,
della richiesta effettuata
della risposta generata
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
16
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
17
Header dell’entità
Gli
header dell’entità danno informazioni sul body del messaggio, o, se
non vi è body, sulla risorsa specificata.





Content-Type: il tipo MIME dell’entità 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, l’URL 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 l’ora dell’ultima modifica.
Serve per decidere se la copia posseduta (es. in cache) è ancora valida o
no.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
18
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)
l’URL della pagina mostrata all’utente mentre richiede il nuovo URL.
Se l’URL è richiesto con altri metodi che non l’attraversamento 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?)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
19
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/1.0
...
Host: www.alpha.com:80



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 l’implementazione di virtual hosting senza manipolazioni del
routing e multi-addressing IP.
From:

l’indirizzo di e-mail del richiedente. Si richiede che l’utente dia la sua
approvazione prima di inserire questo header nella richiesta.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
20
Header della richiesta (3)

Range:


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:



il range della richiesta. Poco usato.
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 l’accesso alla risorsa richiesta. Ne
parliamo oltre.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
21
La risposta
Version status-code reason-phrase CrLf
[Header]*
CrLf
Body
GET /index.html HTTP/1.1
Host: www.unife.it:80
HTTP/1.1 200 OK
Date: Fri, 10 Apr 2009 11:46:53 GMT
Server: Apache/2.0.2 (Unix)
Last-Modified: Mon, 5 Apr 2009 12:55:37 GMT
Accept-Ranges: bytes
Content-Length: 3357
Content-Type: text/html
<HTML> …. </HTML>
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
22
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).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
23
Esempi di status code










100
Continue (se il client non ha ancora mandato il body)
200
Ok (GET con successo)
201
Created (PUT con successo)
301
Moved permanently (URL non valida, il server conosce la
nuova posizione
400
Bad request (errore sintattico nella richiesta)
401
Unauthorized (manca l’autorizzazione)
403
Forbidden (richiesta non autorizzabile)
404
Not found (URL errato)
500
Internal server error (tipicamente un CGI mal fatto)
501
Not implemented (metodo non conosciuto dal server)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
24
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
25
Header della risposta
Gli
header della risposta sono posti dal server per
specificare informazioni sulla risposta e su se stesso al
client

Server:


WWW-Authenticate:


una stringa che descrive il server: tipo, sistema operativo e
versione.
l’header 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 nell’header
Authorization della prossima richiesta.
Accept-ranges:

specifica che tipo di range può accettare (valori previsti: byte e
none).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
26
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)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
27
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
28
Autenticazione (3)
Digest



access authentication
Introdotto da HTTP 1.1, descritto in RFC 2069 e RFC
2617.
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.).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
29
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
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
30
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
31
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
32
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
33
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
34
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, è un’estensione di Netscape, proposta
nell’RFC 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)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
35
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ì).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
36
Architettura dei cookies (2)
client
server
HTTP
applicazione
CGI
genera il cookie
analizza il cookie
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
37
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,
dell’indirizzo IP del server, e dell’età del cookie.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
38
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: l’URI 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
39
Conclusioni HTTP
Abbiamo


parlato di
Protocollo HTTP
Meccanismo di gestione dello stato in HTTP (cookie)
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
40
Riferimenti

Wilde’s WWW, capitolo 3

Altri testi:

T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer
Protocol -- HTTP/1.0, RFC 1945, May 1996
D. Kristol, L. Montulli, HTTP State Management Mechanism,
RFC 2965, October 2000
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
D. Kristol, HTTP Cookies: Standards, privacy, and Politics, ACM
Transactions on Internet Technologies, 1(2), November 2001



Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
41
Introduction to XML

eXtensible Markup Language
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
42
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
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
43
XML
XML
(Extensible Markup Language [sic!]) è un metalinguaggio 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 metainformazioni, ecc.
XML si propone di integrare, arricchire e, nel lungo
periodo, sostituire HTML come linguaggio di markup
standard per il World Wide Web.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
44
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
45
Perché non SGML?
SGML
ha molti pregi, ma ha dalla sua una complessità d’uso e di
comprensione notevole. Inoltre, a SGML mancano caratteristiche di
notevole importanza per l’uso pratico, come link ipertestuali e
specifiche grafiche.
L’avvento di HTML ha fatto capire come i linguaggi di markup siano
ormai maturi per essere compresi dal largo pubblico, ma che la
semplicità d’uso 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
46
I vantaggi di XML (1)
Documenti


La scelta dei nomi degli elementi può essere fatta per
facilitare la comprensione del ruolo strutturale
dell’elemento.
Inoltre, l’uso di un DTD può esplicitare le regole di
composizione ed i rapporti possibili tra le varie parti
dei documenti.
Struttura

auto-descrittivi
navigabile dei documenti
La rigida struttura ad albero e l’assenza di regole di
minimizzazione rendono semplice la visualizzazione e
l’analisi della struttura del documento, e la possibilità
di visualizzare il documento è indipendente dal foglio
di stile che vi si applica.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
47
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
48
I vantaggi di XML (3)
Strutturazione

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

gerarchica dei documenti
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).
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
49
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
dall’applicazione 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, l’autoradio.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
50
Cosa si fa con XML? (1)




Applicazioni che richiedono che il client Web si ponga a
mediare tra due o più database eterogenei
Applicazioni che distribuiscono una parte significativa del carico
computazionale dal server al client
Applicazioni che richiedono che il client Web presenti view
diverse degli stessi dati agli utenti
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,
http://metalab.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
51
Cosa si fa con XML? (2)
Accesso




a database eterogenei
Ogni volta che è necessario trasferire dei dati da un database all’altro, la
soluzione più economica a tutt’oggi è 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
52
Cosa si fa con XML? (3)
Computazioni

Esistono molte esigenze di testing e computazione su oggetti descrivibili
parametricamente:






client-side
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
53
Cosa si fa con XML? (4)
Viste



selettive
L’esempio tipico è l’indice 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
dell’indice.
Ogni espansione richiede un passaggio al server, con ovvi problemi di
latenza. Sarebbe possibile fare tutto client-side con Javascript, ma o si fa
l’indice 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
54
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 vendorindependent, 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
55
Quando scegliere XML? (1)
Quali
sono le condizioni per adottare XML in un progetto?
Ovviamente:





Ma




E’ nuovo
E’ di moda
E’ compatibile con Web e con .NET
Può essere imposto dal committente
Può essere imposto dai partner
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
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
56
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
57
Quando scegliere XML? (3)
Gestione



indipendente di produzione ed uso di dati
Spesso l’interscambio di dati avviene all’interno 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, un’adeguata
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 l’elaborazione non è nota in anticipo.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
58
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
59
Quando scegliere XML? (5)
Elaborazione



di dati in contenitori semi-strutturati
A volte l’informazione 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 all’interno di strutture documentarie
(pensate per la visualizzazione) tag di natura descrittiva
utilizzabili per elaborazioni sofisticate.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
60
Cosa c’è con XML?
XML
è in realtà una famiglia di linguaggi, alcuni già definiti, altri in corso di
completamento. Alcuni hanno l’ambizione 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
61
Uno sguardo d'insieme
NS
SGML
XML
Schema
SOAP
XML
HTML
DOM
XPath
XHTML
URI
CSS
XSLT
Java, C,
C++, PHP,
ASP, Perl,
Javascript,
VBscript
XPointer
XLink
XSLFO
browser
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
Web
Services
print
62
XML 1.0




Una raccomandazione W3C del 10 febbraio 1998.
È definita come un sottoinsieme di SGML
URL ufficiale: http://www.w3.org/TR/REC-xml
Traduzione ufficiale in italiano:
http://www.iat.cnr.it/xml/REC-xml-19980210-it.html

Molto più formalizzata della grammatica di SGML, usa
una notazione formale, Extended Backus-Naur Form.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
63
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 c’entrano con la rete.
Specificamente: deve essere possibile creare applicazioni come
tool di authoring, filtri, formattatori, e traduttori.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
64
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
65
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
66
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!
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
67
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
68
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 all’adozione 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 l’internazionalizzazione

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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
69
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 dell’internazionalizzazione:


È 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
70
Sintassi dei DTD
Una precisazione
 <!DOCTYPE … >
 <!ELEMENT … >
 <!ATTLIST … >
 <!ENTITY … >: Entità generali
 <!ENTITY % … >: Entità parametriche


Altre caratteristiche di XML
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
71
La dichiarazione di tipo




Il <!DOCTYPE … > è la dichiarazione del tipo di documento. Essa permette
alle applicazioni SGML di determinare le regole sintattiche da applicare alla
verifica e validazione del documento.
La dichiarazione non è, ma contiene o fa riferimento alla Document Type
Definition, o DTD, ove vengono elencati gli elementi validi e i loro vincoli.
Il DTD può essere posto in un file esterno, internamente al documento, o in
parte esternamente ed in parte internamente.
N.B.: In XML il nome del DOCTYPE deve essere il nome del tag radice.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
72
Dichiarazione del DTD: <!DOCTYPE … >

1
2

]>
3

<!DOCTYPE mydoc SYSTEM “document.dtd“>
<!DOCTYPE mydoc [
<!ELEMENT …
<!DOCTYPE mydoc SYSTEM “document.dtd” [
<!ELEMENT …
]>



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.
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.
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
73
Dichiarazione XML (1)

<?XML version=“1.0” encoding=“UTF-16” standalone=“yes”
?>

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.
La sintassi usata per la dichiarazione XML è quella delle
Processing Instructions,
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:



<?XML version=“1.0” ?>
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
74
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, l’unico 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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
75
Attribute
Attribute
Name
(Character)
Entity
Reference
Attribute
Value
Element Type
Element Type
Anatomia di un elemento
<p type="rule">Use a hyphen: &#173;.</p>
Start-tag
Content
End-tag
Element
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
76
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
77
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: <vuoto/>
Tutti gli attributi sono sempre racchiusi tra virgolette
Tutte le entità sono definite.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
78
Parser validanti e non validanti




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).
Un parser validante, in presenza di un DTD, è in grado di verificare
la validità del documento, o di segnalare gli errori di markup presenti.
Un parser non validante invece, anche in presenza di un DTD è solo
in grado di verificare la buona forma del documento.
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.
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
79
XML in HEP
Configuration files
 Detector geometry description



Schema for introspection and persistency


“Standard” is evolving
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
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
80
Links

WWW consortium



http://www.w3.org/
with lots of further links !
XML – development

http://www.xml.org/
Tecnologia dei Servizi “Grid e cloud computing” - Lezione 003b
81