Capitolo 10
Progettazione dell’architettura
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INDICE
Indice
•
•
•
•
•
Introduzione
Valutazione delle architetture
Configurazioni architetturali
Ottimizzazione delle prestazioni
Web caching
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Valutazione
delle architetture
• Ogni scelta architetturale va valutata in base a
dimensioni critiche:
•Prestazioni
•Scalabilità
•Disponibilità
•Mantenimento dello stato
•Sicurezza
• Obiettivo di un’architettura: massimizzare
queste dimensioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Obiettivi (1)
• Prestazioni: garanzia di sopportazione del
carico di lavoro previsto, in termini di:
– N° utenti concorrenti
– N° pagine servite/secondo
– Tempo di risposta all’utente
• Scalabilità: possibilità di aggiungere potenza
computazionale al crescere del carico di
lavoro, per mantenere elevate prestazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Obiettivi (2)
• Disponibilità: garanzia di continuità del
servizio anche a fronte di errori e/o
malfunzionamenti
• Mantenimento dello stato: capacità di
memorizzazione delle interazioni e dello stato
dell’utente, anche in ambiente distribuito
• Sicurezza: protezione delle informazioni,
identificazione dell’utente, accesso controllato
ai dati
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Vincoli:
limitazioni nella scelta
• Le scelte architetturale sono vincolate da
limiti fisici, economici ed organizzativi:
•Costi: il prezzo delle risorse tecnologiche
richieste (macchine, reti, software)
•Complessità: difficoltà e costi di
installazione, gestione e manutenzione
•Standard aziendali: risorse pre-esistenti,
esperienza pregressa, integrazione con i
sistemi aziendali
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Scenari di installazione
• Tendenza generale: OUTSOURCING.
• Possibili scenari:
•Interno: architettura interna all’azienda,
gestita dalla divisione IT
•Hosting: applicazione installata su
architettura di provider esterno, che la
gestisce completamente
•Housing: applicazione installata
internamente su macchine aziendali,
gestita poi da un fornitore di servizi esterno
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
I componenti essenziali
dell’architettura:
•Web Server
•Script Engine
•Application Server
•Database Server
Scelte architetturali per decidere:
•Quali componenti vanno su macchine separate
•Quante macchine servono per ogni componente
•Come collegare tra loro componenti
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Configurazione 1:
SERVER SINGOLO
•Una sola macchina (Host 1) ospita:
•Web Server
•Script execution engine
•Database
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Il router/ firewall
• Router:
– Punto di connessione Internet/
Intranet
– Consente a browser esterni di
connettersi al Web Server
• Firewall:
Internet
Intranet
– Separa il mondo esterno (Internet)
dalla rete aziendale (Intranet)
– Blocca i tentativi di intrusione e le
richieste non autorizzate (attraverso
Access Control Rules)
• Può essere un unico dispositivo
che svolge le due funzioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
SERVER SINGOLO:
valutazione
•Prestazioni: legata alle caratteristiche della macchina
(velocità CPU, HDD, connessione di rete, DBMS).
•Criticità: Database e Web Server sulla stessa macchina.
Sono due processi che occupano molte risorse (RAM, tempo-CPU)
•Scalabilità: unica possibilità è upgrade della macchina (aggiunta
RAM, cambio CPU o dischi, …)
•Disponibilità: se cade un componente, tutto il sistema è fermo
•Mantenimento dello stato: semplice perché su macchina singola
(memorizzato nello script engine e/o nel database)
•Sicurezza: dati non difesi se il firewall viene superato
•Costo: basso, se non serve hw ad alte prestazioni
•Complessità: soluzione più semplice da installare e mantenere
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Config. 2:
SEPARAZIONE DEL DB SERVER
Host 2
Host 1
HTTP
HTTP
Client
(browser)
Router /
firewall
Internet
Firewall
Web server +
Execution engine
Database
Demilitarized zone (DMZ)
Intranet
•Web Server e Script execution engine sono ospitati su una
macchina (Host 1)
•Il Database Server è ospitato su un altro calcolatore (Host 2)
•L’aggiunta di un firewall intermedio aumenta la sicurezza
dei dati
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
SEPARAZIONE DEL
DB: valutazione
•Prestazioni: dimensionamento migliore delle due macchine
•Es.: potenziamento accesso/mirroring dei dischi del DB server
•Scalabilità: possibilità di intervenire separatamente
su middle tier e data tier
•In genere è il middle tier che raggiunge per primo la saturazione;
richiede potenziamento per appieno le potenzialità del data tier
•Disponibilità: un componente fermo blocca ancora il sistema
•Sicurezza: dati su macchina separata sono più sicuri; un firewall
tra middle e data tier può bloccare le richieste HTTP (attacchi) e
consentire solo le richieste al DB
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
REPLICAZIONE E PARALLELISMO
•prestazioni
•disponibilità
•scalabilità
sono limitate dalla presenza di
UNA SINGOLA ISTANZA
DI OGNI COMPONENTE
Soluzione: REPLICAZIONE
•Replico i processi critici (Web Server, script engine,…)
•Tengo in esecuzione più copie in parallelo di ogni processo
Engine
Engine
Engine
Engine
Replicazione : applicabile a qualsiasi livello dell’architettura
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Replicazione orizzontale e verticale
Due modi di fare replicazione di applicazioni:
•VERTICALE:
una singola macchina server
ospita più istanze di processo
Vertical cloning
•ORIZZONTALE:
L’intera macchina server viene
replicata. Ogni macchina
ospita una o più istanze di
processo Horizontal cloning
Host 1:
Host 2:
Process
Process
Host 1:
Process 1
Process 2
Process 3
Process 4
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Host 3:
Host 4:
Process
Process
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Vantaggi della replicazione
Indipendenti dal tipo di replicazione (orizz. o vert.)
•Prestazioni
consente LOAD-BALANCING: distribuzione del carico di
lavoro sui server/ processi in modo bilanciato
•Scalabilità
Se necessario, è possibile aggiungere nuove istanze di
processi (o macchine server, in cluster)
•Disponibilità
consente FAIL-OVER: se cade uno dei processi, il suo carico
di lavoro viene distribuito sui processi funzionanti e il sistema
continua a fornire il servizio
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Config. 3:
REPLICAZIONE DEL WEB SERVER
•Più copie del Web Server funzionanti in parallelo
•Router/firewall fa da NETWORK DISPATCHER
(bilancia il carico di lavoro tra i diversi Web Server)
•Alcuni server possono usare SHTTP per garantire la sicurezza:
il dispatcher invia tutte le richieste SHTTP al server sicuro
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Il problema delle
sessioni utente
•Bisogna garantire che lo stato dell’utente sia mantenuto
SUL LOAD-BALANCING:
•STICKY SESSION: Tutte le richieste dello stesso client devono essere
inviate dal dispatcher allo stesso server (lo stato utente è memorizzato sul
server!)
•Il dispatcher deve avere una certa “intelligenza” per riconoscere le
richieste di uno stesso utente. Non basta l’IP del client: potrebbe essere
usato da più utenti di una intranet
SUL FAIL-OVER:
•Le sessioni memorizzate dal Web server guasto devono essere
recuperate ed usate dagli altri Web server (che riceveranno le richieste
seguenti degli utenti connessi al server guasto)
•I dati di sessione devono essere memorizzati in modo duraturo (es. nel
DB) [Soluzione costosa per le prestazioni]
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache:
metodo pull
PULL:
• La copia in cache avviene nel momento in
cui una richiesta del client scatena un
avviso di assenza da cache
• Usato più spesso
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Protocolli di gestione della cache
• Protocolli che raccolgono regole per
l’aggiornamento della cache:
– Expiration rules: definiscono la durata della validità di
un oggetto in cache
– Invalidation rules: criteri per stabilire se l’oggetto in
cache non è conforme con l’originale corrente
• Sono molto complessi per risorse dinamiche
• E’ possibile inserire delle direttive di caching
nelle risorse dinamiche (per esempio mediante
custom tag nelle pagine JSP)
• Proposta di standard: Edge Side Include (ESI)
www.esi.org
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
REPLICAZIONE DEL WEB
SERVER: valutazione
•Prestazioni: più elevate grazie al load-balancing
•Scalabilità: possibilità di aggiungere nuovi Web
server
•Disponibilità: se cade un Web server, il suo traffico
è ridiretto su una sua replica
•Mantenimento dello stato: necessari meccanismi
sticky session e memorizzazione stato per il fail-over
•Sicurezza: possibilità di avere uno o più server sicuri
•Complessità: accresciuta dalla replicazione
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Configurazione 4:
CON APPLICATION SERVER
•Centralizzazione della business logic nell’App. Server mediante oggetti
riusabili (per esempio, Enterprise Java Beans, componenti MS DCOM)
•Gli oggetti possono essere invocati da qualunque applicazione
aziendale (anche non Web)
•La gestione di parallelismo, replicazione, sicurezza, disponibilità è
garantita dall’application server ed è trasparente al programmatore
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Configurazione 4:
CON APPLICATION SERVER
HTTP
Engine 1
WebServer2
Engine 2
Application
server
Host 2
HTTP
HTTP
Client
(browser)
WebServer1
INTERNET
Router /
firewall
Internet
SHTTP
Firewall
Application
server
Firewall
Database
DMZ
WebServer3
Engine 3
DMZ2
Application
server
Intranet
•Bilanciamento e failover a livello degli oggetti applicativi
•Parallelismo DINAMICO: il numero di processi allocati e di istanze di
oggetti è scelto a run-time in base al traffico reale
•Possibilità di effettuare catene di operazioni sugli oggetti in modo
transazionale
•Application server isolabile con un ulteriore firewall
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
INTERNET
Application Server: valutazione
•Prestazioni: elevate grazie al load-balancing
dinamico
•Scalabilità: virtualmente illimitata replicando
l’application server
•Disponibilità: capacità di fail-over a livello degli
oggetti eseguiti all’interno dell’application server,
gestione delle transazioni
•Complessità: ambienti generalmente complessi da
manutenere
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Architetture software: il pattern MCV
• Come distribuire le funzionalità software tra web
server e application server?
• Architettura Model View Contoller (MVC):
client
aggiorna
richiede
controller
presenta
view
model
notifica
• Scopo: separare le funzioni in moduli software ben
disaccoppiati e rendere le logiche di business
(model) riusabili in contesti diversi, sia Web che non
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
MVC su Web (MVC 2)
richiesta
HTTP
browser
Pagina
HTML
Client
•
•
•
•
App. server
Controller
(servlet)
View
(Template JSP
+ custom tag
Model
(oggetti di
business
EJB)
Model
(action
classes)
Oggetti di stato
(JavaBeans)
Web server + engine
DB
Database
Il controller è configurato per dirigere ogni richiesta alla opportuna
action
La action class invoca gli oggetti di business necessari
Il controller chiama un template per visualizzare i risultati
Il template traduce (in HTML) i risultati prodotti dalla action, senza
neppure sapere come sono stati costruiti
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Prestazioni delle architetture Web
• Le prestazioni sono uno dei criteri più importanti
per la scelta dell’architettura
• Buon esempio delle considerazioni progettuali
necessarie durante il progetto di un’applicazione
Web
• I requisiti di prestazione sono basati sul numero
di utenti:
– Semplice da stimare per siti Intranet/Extranet (B2B)
– Difficilmente valutabile per siti Web pubblici (B2C)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Metriche di performance
• N° di richieste di pagine: valore medio e di picco
di richieste inviate dai client [pagine/secondo]
• N° di utenti concorrenti: valore medio e di picco di
utenti connessi al sito contemporaneamente
• Tempo di risposta: massimo intervallo di tempo di
attesa di risposta del server da parte del client
[time to first byte (TTFB) e time to last byte
(TTLB)]
• Mix di richieste: per applicazioni con pagine
complesse, si definisce il mix plausibile di accessi
alle differenti pagine da parte dell’utente medio
(assegnando una probabilità ad ogni pagina)
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Algoritmo di ottimizzazione
• Idea:
rimuovere i colli
di bottiglia finché
i requisiti non
risultano
soddisfatti
• Collo di bottiglia:
problema che si
verifica nel
componente più
lento del sistema
Start
Requisiti di
performance
Rimuovi colli di
bottiglia (se possib.)
Definisci una
configurazione
Identifica
colli di bottiglia
Verifica performance
no
Requisiti
soddisfatti?
sì
Stop
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Ottimizzazione di prestazioni
di applicazioni Web
Tre possibilità di intervento:
• Ottimizzazione del codice applicativo
– Difficile
• Potenziamento dell’architettura
– Costoso
• Web caching: memorizzazione temporanea
di risorse in modo da garantire accesso
veloce
– Basso costo
– Basso impatto sull’applicazione
– Basse conoscenze tecniche richieste
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Benefici del Web Caching
• Riduzione della latenza di rete: una cache
vicina al client consente risposte più veloci
perché non è necessario trasmettere
informazioni su lunghi tratti di rete
– Riduzione di uso della banda e tempo di risposta
• Riduzione dello sforzo computazionale:
risorse dinamiche vengono recuperate
immediatamente invece che ricalcolate
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Cosa mettere in cache
• Tutto ciò che contribuisce a costruire la
risposta del Web Server:
– Pagine statiche
– Files multimediali
– Fammenti di pagine dinamiche computate
– Dati intermedi consumati dallo scripting
per computare pagine
– Risultati di queries a database o di altre
computazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Cosa mettere in cache
• Tutto ciò che contribuisce a costruire la
risposta del Web Server:
– Pagine statiche
– Files multimediali
– Fammenti di pagine dinamiche computate
– Dati intermedi consumati dallo scripting
per computare pagine
– Risultati di queries a database o di altre
computazioni
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 1:
browser caching
•
•
•
•
E’ una directory dell’HD dell’utente
Memorizza pagine e risorse statiche
Annulla la latenza di rete
Non è affidabile in generale, il cliente o il
fornitore di contenuti la può disabilitare
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 2:
proxy caching
• Cache basata su proxy HTTP
• Posizionata tra Intranet e Internet
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 3:
Content Delivery Network
CDN
Cache 1
Client
(browser)
Cache 3
° Web server
° Engine
Cache 2
Client
(browser)
Internet
° App. server
Database
DMZ
Intranet
• Infrastruttura di cache complessa
• Composta da molti nodi anche distribuiti
geograficamente
• Gestita da fornitori specializzati
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Dove mettere la cache 4:
server accelerators
• Buffer posizionato di fronte alla macchina che
produce risposte dinamiche
• Permette di allocare minor potenza
computazionale all’architettura del server
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache:
metodo push
PUSH:
• La copia in cache avviene con periodicità
fissa, indipendentemente dalle richieste
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Popolazione della cache:
metodo pull
PULL:
• La copia in cache avviene nel momento in
cui una richiesta del client scatena un
avviso di assenza da cache
• Usato più spesso
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano
Protocolli di gestione della cache
• Protocolli che raccolgono regole per
l’aggiornamento della cache:
– Expiration rules: definiscono la durata della validità di
un oggetto in cache
– Invalidation rules: criteri per stabilire se l’oggetto in
cache non è conforme con l’originale corrente
• Sono molto complessi per risorse dinamiche
• E’ possibile inserire delle direttive di caching
nelle risorse dinamiche (per esempio mediante
custom tag nelle pagine JSP)
• Proposta di standard: Edge Side Include (ESI)
www.esi.org
Progettazione di dati e applicazioni per il Web
S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera
Copyright © 2003 - The McGraw-Hill Companies, srl
Contenuto per concessione del Politecnico di Milano