Architectures for Distributed Computing Chapter 5

Architectures for
Distributed Computing
Chapter 5
Piergiorgio Cremonese
Silvia Giordano
Netikos
SUPSI
Netikos Pisa - Italy
piergiorgio.cremonese@netikos.com
http://www.netikos.com
© SUPSI-DTI
Silvia Giordano
CH-6928 Manno
silvia.giordano@supsi.ch
http://www.supsi.ch
Architecture 1
10/06/2004
Contents
Network
Applications Architecture
J2EE Summary
Laboratory: Network Applications
Architecture
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 2
1
Overview
Concept
of tiers
The ancestors of the client/server
architectures
The current three tiers architecture
Multi-tiers architectures
practical example
© SUPSI-DTI
Silvia Giordano
Architecture 3
10/06/2004
Chapter goals:
Use
the modern view of current
applications
Understand the main features of evolving
applications and their related models
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 4
2
Introduction
client
server model behind distributed
applications and how this model was born and
is evolving:
View with tiers
One tier architecture
Two tiers architecture
Three tiers architecture
Multi-tiers architecture
© SUPSI-DTI
Silvia Giordano
Architecture 5
10/06/2004
Tiers
One

application is running on a single computer
Two

tier
tiers
application is running on two computers
Three

tiers
add a middle layer
n-tiers

© SUPSI-DTI
unlimited number of programs to run simultaneously
Silvia Giordano
10/06/2004
Architecture 6
3
Overview
Concept
of tiers
The ancestors of the client/server
architectures
The current three tiers architecture
Multi-tiers architectures
practical example
© SUPSI-DTI
Silvia Giordano
Architecture 7
10/06/2004
The ancestors
Mainframe

architecture
centralized intelligence
Users with simple terminals
File-sharing

© SUPSI-DTI
architecture
server downloads files from the shared location to
the desktop environment.
user jobs run (including logic and data) in the
desktop environment
for low usage
Silvia Giordano
10/06/2004
Architecture 8
4
Client/Server model
Client/server paradigm
❒ standard
❒ proprietary
Client must contact server
❒ server process must first be running
❒ server must have created socket (door) that welcomes client’s
contact
Client contacts server by:
❒ creating client-local socket
❒ specifying IP address, port number of server process
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 9
Main components of C/S model
A
presentation component:

A
business component:

A
perform some type of data manipulation.
data access component:

© SUPSI-DTI
presents information to an external source and obtains
input from that source.
interfaces either with a data storage system such as
database systems or hierarchical file systems, or with
some other type of external data source as a data
feed or an external application system.
Silvia Giordano
10/06/2004
Architecture 10
5
One Tier Architecture
Pros:

easier management
easier control
more secure
Cons:

© SUPSI-DTI
scalability
portability
lack of flexibility
Silvia Giordano
10/06/2004
Architecture 11
Two Tier Architecture
typical
client/server
architecture
pros

© SUPSI-DTI
faster development
and deployment of
applications
hardware-independent
database systems
small servers
fat client (Javaapplets)
Silvia Giordano
10/06/2004
Architecture 12
6
cons

© SUPSI-DTI
Two Tier Architecture
worst security,
reliability, scalability,
and control
effective for simple
applications
client application must
enforce its own
security process
each database must
also enforce its own
security process
scalability
Silvia Giordano
10/06/2004
Architecture 13
From Two To Three Tier Architecture

third (middle) tier server between
client and server
effective distributed client/server
design with hidden complexity
flexibility, maintainability,
reusability: provides separate
process management
scalability: can handle large
number-of-users
functions : queuing, application
execution, and database staging
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 14
7
Overview
Concept
of tiers
The ancestors of the client/server
architectures
The current three tiers architecture
Multi-tiers architectures
practical example
© SUPSI-DTI
Silvia Giordano
Architecture 15
10/06/2004
Three Tier Architecture
Client/server

© SUPSI-DTI
model sub-divided into:
the data layer
the logic layer, or middle-tier (difference with 2-tiers)
the presentation layer, or client
Silvia Giordano
10/06/2004
Architecture 16
8
Three Tier Architecture
fat
clients are
splitted into two
pieces :

a thin client
the application
logic, running on a
server
easy
deployment of
simple clients
logic is centralized
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 17
Different Three Tier Architecture
Three
tier with TP monitor technology
Three tier with message server
Three tier with an application server
Three tier with an ORB architecture
Distributed/collaborative enterprise
architecture
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 18
9
Three tier with TP monitor technology
Transaction
Processing (TP) monitor (middle
tier)
message queuing, transaction scheduling, and
prioritization service
client connects to the TP monitor
the transaction is handled by TP monitor (client
is not blocked)
effective for scalability
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 19
Three tier with message server
intelligent
messages
messages = headers (with priority information),
address number and identification number
prioritized and processed asynchronously
good solutions for wireless infrastructures
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 20
10
Three tier with an application server
main
body of an application server to run on a
shared host
smaller client

© SUPSI-DTI
more secure
more scalable
Silvia Giordano
10/06/2004
Architecture 21
Three tier with an ORB architecture
support
distributed objects
two prominent distributed object technologies:

© SUPSI-DTI
Common Object Request Broker Architecture
(CORBA)
COM/DCOM
Silvia Giordano
10/06/2004
Architecture 22
11
Distributed/collaborative enterprise
architecture
based
on Object Request Broker
enhanced by using shared, reusable business
models (not just objects) on an enterprise-wide
scale
enterprise is a system comprised of multiple
business systems or subsystems
improve effectiveness organizationally,
operationally, and technologically
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 23
Three Tiers Architecture advantages
pros
of both one-tiered approach and the two-tiered
approach
flexible architecture
Object reuse
Easier system maintenance
More effective use of data and networks
Higher developer productivity through specialization
new perspectives of computational work in
methodological and also in production views: multi-tiers
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 24
12
Comparison of Tiers Architectures
Architecture
One tier
Two tiers
Three tiers
N tiers
© SUPSI-DTI
Silvia Giordano
Pros
Simple
Very high performance
Self-contained
Clean, modular design
Less network traffic
Secure algorithms
Can separate UI from business logic
Can separate UI, logic, and storage
Reliable, replicable data
Concurrent data access via
transactions
Efficient data access
Support multiple applications more
easily
Common protocol/API
Cons
No networking -- can't access remote
services Potential for spaghetti
code
Must design/implement protocol
Must design/implement reliable data
storage
Need to buy database product
Need to hire DBA
Need to learn new language (SQL)
Object-relational mapping is difficult
Quite inefficient
Must learn API (CORBA, RMI, etc.)
Expensive products
More complex; thus, more potential
for bugs
Harder to balance loads
Architecture 25
10/06/2004
Overview
Concept
of tiers
The ancestors of the client/server
architectures
The current three tiers architecture
Multi-tiers architectures
practical example
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 26
13
Applicazioni multi-tier: distribuzione delle
risorse
Il
concetto di base delle applicazioni multi-tier
è la distribuzione delle risorse (interfaccia,
computazioni, dati) fra varie macchine
Ogni tier accumuna componenti software
uniformi
Esempio tipico: applicazioni client-server (2tier: uno è il client, l’altro il server)
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 27
Applicazioni multi-tier
Le
applicazioni 2-tier erano le più diffuse nel
passato
Oggi la tendenza è di usare applicazioni 3-tier o
4-tier:

© SUPSI-DTI
Interfaccia utente, sul client
[protocollo standard, per esempio via web]
Logica di business, sul server
Dati di impresa, su un DBMS
Silvia Giordano
10/06/2004
Architecture 28
14
Applicazioni multi-tier
Macchina dell’utente finale
(client)
Interfaccia utente
Gestore protocollo
}
Server di applicazioni
Logica di business
Dati
© SUPSI-DTI
Silvia Giordano
Server dati
Architecture 29
10/06/2004
Applicazioni multi-tier
Interfaccia utente

Gestore protocollo

Logica di business

Dati
© SUPSI-DTI
Silvia Giordano
10/06/2004
Thin client: GUI basata su
FORM HTML
Applet: GUI fornita da un’applet
scaricata via web
Rich/thick client: GUI fornita
da un’applicazione stand-alone,
che però comunica tramite il
protocollo dato con il server
Batch/Poor client: interfaccia a
linea di comando, fornita da
un’applicazione stand-alone come
sopra
Architecture 30
15
Applicazioni multi-tier
Interfaccia utente

Gestore protocollo

Logica di business

Dati

© SUPSI-DTI
Silvia Giordano
Web-based: le comunicazioni con
la UI sono trasportate come
pacchetti HTTP
(GET/POST/PUT)
XML-based: le comunicazioni con
la UI sono trasportate come
messaggi SOAP
Custom: le comunicazioni con la
UI sono trasportate secondo un
protocollo privato (via socket)
Altro: (CORBA, protocolli
specifici di un dominio)
Architecture 31
10/06/2004
Applicazioni multi-tier
Interfaccia utente
Gestore protocollo
Logica di business
Dati
© SUPSI-DTI
Silvia Giordano
10/06/2004
Applicazione
all-in-one: server
tradizionale
Applicazione basata su Enterprise
beans: entity beans, session
beans, ecc.
Applicazione basata su Web
components: servlet, JSP
Applicazione basata su Web
services: componenti JAX-RPC
Architecture 32
16
Applicazioni multi-tier
Interfaccia utente
Un

Gestore protocollo
Un

Logica di business

qualunque DBMS relazionale
Per cui sia disponibile un driver
JDBC
DB specializzato
DB orientato agli oggetti
DB semistrutturato
…
Un
legacy system con funzione di
data warehouse
Dati
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 33
Applicazioni multi-tier via web
Usare
come protocollo di comunicazione la
tecnologia web presenta molti vantaggi pratici

© SUPSI-DTI
È possibile realizzare applicazioni accessibili con un
semplice browser
I task di formattazione vengono lasciati al linguaggio
di markup (HTML+CSS, WML, ecc.)
Rimane possibile creare rich client, fornendo così vari
livelli di interazione per gli stessi servizi
Silvia Giordano
10/06/2004
Architecture 34
17
Applicazioni multi-tier via web
© SUPSI-DTI
Silvia Giordano
Architecture 35
10/06/2004
Applicazioni multi-tier via web
Interfaccia utente

tecnologie più comunemente usate
per applicazioni multi-tier via web
con J2EE:

Gestore protocollo

Logica di business

Dati
© SUPSI-DTI
Silvia Giordano
10/06/2004
Interfaccia utente basata su web
Tomcat o application server analoghi
come gestore di protocollo
Logica di business basata su Servlet o
JSP
Dati accessibili tramite JDBC
L’uso di tecnologie basata su Java
e/o open source ci garantisce la
durata dell’investimento
Architecture 36
18
Overview
Concept
of tiers
The ancestors of the client/server
architectures
The current three tiers architecture
Multi-tiers architectures
practical example
© SUPSI-DTI
Silvia Giordano
Architecture 37
10/06/2004
Esempio1: Forum via servlet
Directory
Dati
Utente
Web Server
Applet
Servlet
Browser
DBMS
JDBC
Dati
magazzino
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 38
19
Esempio1: Forum via cgi
Directory
Dati
Utente
Web Server
javascript
CGI
Browser
DBMS
ODBC/DBI
Dati
magazzino
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 39
Esempio2 H2S: Un sistema proprietario
da HTTP a SMS
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 40
20
Physical Architecture
Silvia Giordano
M
© SUPSI-DTI
S
/G
IN
S2
ET
N
R
TE
TS
PO
S1
Architecture 41
10/06/2004
Logical Architecture
WEB
httpd
HTTP
AS
H2Sd
checker
listener
H2S
client
SMS
gateway
smsq
smss
H2S receiver
SMS
Browser
SMS
IP
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 42
21
Esempio2: H2S via servlet
Web
HTTP
browser
jk
Controller
Jsp
Servlet
DS
LDAP
smsq
smsSender H2SServer
© SUPSI-DTI
Silvia Giordano
H2S
H2S
Client
DB
JDBC
Application Server
Architecture 43
10/06/2004
Esempio2: H2S via CGI
HTTP
Web
browser
cgi
CGI
application
smsq
H2S
smsSender H2SServer
© SUPSI-DTI
Silvia Giordano
10/06/2004
H2S
Client
DS
LDAP
DB
JDBC
Application Server
Architecture 44
22
Architecture CGI
DB
http
Web cgi CGI
browser
smsq
H2S
smsSender H2SServer
© SUPSI-DTI
Silvia Giordano
H2SClient
Architecture 45
10/06/2004
Components Role

Web
Access Functionality
UnSafe Document Repository (imgs,..)

Application Server
Dynamic Presentation
Check Controls
Business Logic
Security
Data Access Functionality

Manages requests coming from the access point
(e.g. Web)
JSP

© SUPSI-DTI
Presentation Layer: it is implemented as an
exetension of HttpServlet: compiled at
RunTime
Silvia Giordano
10/06/2004
Architecture 47
Application Server
Servlet

Action
Actions triggered by events: used for logic and
presentation
PreCompiled
Classes

Le servlet sono per certi versi analoghe alle
applet
Le servlet stanno a un application server come le
applet stanno a un browser
In entrambi i casi, un contenitore estende le proprie
capacità caricando componenti esterni: si tratta quindi
di plug-in

Le applet risiedono normalmente

© SUPSI-DTI
Sul server, da cui vengono recuperate via HTTP
Nella cache locale del browser
Le servlet risiedono normalmente sul server, in un’area nota
all’application server
Silvia Giordano
Architecture 49
10/06/2004
Applet & Servlet
Le

© SUPSI-DTI
applet si usano spesso senza servlet
applet che non necessitano di processing
server-side: ricevono un po’ di parametri
all’avvio, e si limitano a mostrarli
in altri casi, le applet si collegano a un server
(non servlet) scritto in Java o altri linguaggi, e
usano un protocollo privato
volendo, le applet possono comunicare con il
server via HTTP (simulano una FORM)
Silvia Giordano
10/06/2004
Architecture 50
25
Applet & Servlet
Le

© SUPSI-DTI
servlet si usano spesso senza applet
spesso processano input proveniente da FORM
tradizionali
in altri casi, i dati possono essere generati da
una pagina con Javascript, memorizzati in campi
hidden di una FORM “invisibile” e inviati al
servlet
è anche possibile che un servlet processi input
proveniente da altre sorgenti
Silvia Giordano
Architecture 51
10/06/2004
Applet & Servlet
Applet
e servlet si possono anche usare
insieme (come nel nostro esempio)

È
© SUPSI-DTI
l’applet raccoglie e pre-elabora i dati, offrendo
una bella GUI all’utente
quando i dati sono pronti, li manda al server via
HTTP
il server li passa alla servlet per l’elaborazione
server-side
però un uso poco comune
Silvia Giordano
10/06/2004
Architecture 52
26
Differenza fra Servlet e CGI
Gli
script CGI vengono eseguiti dal S.O.,
quindi sono potenzialmente meno portabili
Le Servlet vengono eseguite dalla JVM
integrata nell’application server, quindi sono
“isolate” dal S.O. e dunque più portabili
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 53
Differenza fra Servlet e CGI
Gli
script CGI vengono caricati ed eseguiti
una volta per ogni richiesta – quindi, il costo
di avvio (latenza) è alto
Le Servlet vengono caricate solo una volta;
poi si crea un Thread (di Java) per ogni
richiesta – operazione meno costosa, e
dunque si ha una latenza più bassa
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 54
27
Differenza fra Servlet e CGI
Gli
script CGI possono essere scritti in
qualunque linguaggio: potete scegliere il
linguaggio più adatto al particolare scopo
Le Servlet devono essere scritte
necessariamente in Java: spesso va bene,
ma a volte non è conveniente
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 55
Differenza fra Servlet e CGI
Il protocollo CGI è supportato da tutti i Web
server (anche se a volte con qualche piccola
differenza)
Le Servlet sono supportate solo da alcuni Web
server (quelli che fungono da application server)

c’è comunque una buona scelta di prodotti commerciali
È sempre possibile affiancare un application server a
un web server, anche su due porte diverse sulla stessa
macchina fisica

© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 56
28
Server che supportano le Servlet
Versione Servlet
supportata
Versione JSP supportata
Apache & Sun – Tomcat
2.4
2.0
Apache + Jserv
2.0
1.0
Borland AppServer
2.3
1.2
IBM WebSphere Application Server
2.4
2.0
2.2
1.1
2.4
2.0
Prodotto
IONA iPortal Application Server
(ora migrati su Jboss)
javaSystem Application Server 8
... e parecchi altri …
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 57
Struttura delle Servlet

Le Servlet sono classi Java
che implementano
l’interfaccia
javax.servlet.Servlet
Una classe può implementare
Servlet direttamente
Ma più comunemente
estende HttpServlet

© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 58
29
Dialogo con le Servlet
Il
dialogo fra Servlet e il
browser è di tipo
client/server
client

→ server
interfaccia ServletRequest
server

© SUPSI-DTI
Silvia Giordano
→ client
interfaccia ServletResponse
Architecture 59
10/06/2004
Metodi di Servlet
Metodo
Descrizione
init()
Inizializza la servlet
(e alloca risorse)
service()
Serve una richiesta
destroy()
Elimina la servlet
(e libera le risorse)
getServletInfo()
Restituisce informazioni sulla
servlet (una stringa)
getServletConfig()
Restituisce la configurazione
della servlet
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 60
30
Ciclo di vita di una Servlet

Al primo caricamento
viene chiamato init()
Per ogni richiesta,
viene chiamato il
metodo service()
Alla fine, viene
chiamato destroy()

© SUPSI-DTI
es: quando il container
termina
Silvia Giordano
10/06/2004
Architecture 61
Servlet e HttpServlet
L’interfaccia delle Servlet è piuttosto
generica…
GenericServlet la implementa e la estende con
metodi di utilità

Gestione parametri, gestione contesto, file di log
La classe di sistema HttpServlet specializza
GenericServlet per il protocollo HTTP

© SUPSI-DTI
ci sono HttpServletRequest e
HttpServletResponse associate
Silvia Giordano
10/06/2004
Architecture 62
31
Un esempio (una HttpServlet)
public class SimpleServlet extends HttpServlet {
public void doGet(HttpServletRequest richiesta,
HttpServletResponse risposta)
throws ServletException, IOException
{
String titolo = “Risposta dalla mia Servlet";
risposta.setContentType("text/html");
PrintWriter out = risposta.getWriter();
out.println("<HTML><HEAD><TITLE>");
out.println(titolo);
out.println("</TITLE></HEAD><BODY>");
out.println("<H1>" + titolo + "</H1>");
out.println("<P>... resto della pagina ...");
out.println("</BODY></HTML>");
out.close();
}
© SUPSI-DTI
Silvia Giordano
10/06/2004
}
Architecture 63
Gestione della persistenza
È
importante ricordare che ogni singola
richiesta HTTP viene trattata
separatamente da tutte le altre

© SUPSI-DTI
come fa una povera servlet a gestire sessioni
che comprendono più di una richiesta?
come fanno più servlet che costituiscono una
sola applicazione a passarsi dati e comunicare
fra di loro?
Silvia Giordano
10/06/2004
Architecture 64
32
Gestione della persistenza
Abbiamo

sostanzialmente due vie
Gestire manualmente la persistenza
Adatto
quando i dati da rendere persistenti sono pochi o
poco strutturati
Bastano in genere poche righe di codice

Affidarci agli Scope Object offerti dal framework
Adatto
per usi sofisticati
Consente vari livelli di persistenza
© SUPSI-DTI
Silvia Giordano
Architecture 65
10/06/2004
Gestione manuale della persistenza
Usando

© SUPSI-DTI
i cookie
la servlet scrive i dati che
vuole rendere persistenti
tramite i cookie
successive richieste – alla
stessa servlet o a servlet
diverse – si porteranno
dietro i cookie scritti nel
client
Silvia Giordano
10/06/2004
Usando

sessionID
la servlet associa un
identificatore unico ad
ogni sessione
il sessionID viene usato
come chiave per accedere
a un DB sul server
successive richieste
accedono al DB con la
stessa chiave
Architecture 66
33
Gestione dei cookie – scrittura
Si crea un cookie con
1.
cookie = new Cookie(nome,valore);
Si impostano gli attributi del cookie
2.
cookie.setComment(...);
cookie.setDomain(...);
cookie.setMaxAge(...);
...eccetera
Si invia il cookie con la risposta
3.
risposta.addCookie(cookie);
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 67
Gestione dei cookie – lettura
1.
Si recuperano i cookie dalla richiesta
k = rich.getCookies();
2.
Si cerca il “nostro” cookie
for (i=0; i<k.length; i++)
if (k[i].getName().equals(“nostro”))
{ nostro=k[i]; break; }
3.
Si estrae il valore memorizzato nel cookie
(se lo abbiamo trovato)
valore=nostro.getValue();
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 68
34
Gestione del session ID
1.
Si estrae la sessione dalla richiesta,
creandola se necessario (primo accesso):
HttpSession sess=
richiesta.getSession(true);
2.
Si memorizzano/leggono i dati:
a.
b.
© SUPSI-DTI
da un DB, usando sess.getID() come chiave
dalla sessione stessa, usando
sess.putAttribute(chiave,valore) e
sess.getAttribute(chiave)
Silvia Giordano
Architecture 69
10/06/2004
Gli Scope Objects

Ciascun componente web (servlet o pagine JSP,
che vedremo più avanti) può accedere a 4
Scope Objects:
ServletContext – il container
HttpSession – la sessione corrente
HttpServletRequest – la richiesta corrente
JspContext – la pagina corrente (per JSP)

Ogni Scope Object fornisce metodi
putAttribute() e getAttribute() per
memorizzare a recuperare oggetti arbitrari
associati a chiavi alfanumeriche
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 70
35
ServletContext
ServletContext
rappresenta il container che sta
eseguendo la Servlet corrente (e, di solito, tutte
le altre)

Il ServletContext è unico all’interno della JVM
Alcuni container offrono varie configurazioni:
Una
sola JVM per tutte le servlet: ServletContext è globale,
come pure i dati memorizzati in esso
Più JVM, ciascuna delle quali esegue più servlet: ci sono più
ServletContext; per avere un contesto globale occorre usare
un DB esterno
© SUPSI-DTI
Silvia Giordano
Architecture 71
10/06/2004
ServletContext
Per ottenere il ServletContext, basta chiamare il
metodo della servlet getServletContext()
Da tenere a mente: il ServletContext è
condiviso; più servlet in esecuzione allo stesso
tempo potrebbero accedere concorrentemente
ai dati…
Soluzione: usare i costrutti Java per la mutua
esclusione (synchronized)

© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 72
36
HttpSession
Una sessione può persistere per un periodo di
tempo specificato, e coprire più richieste HTTP
(e anche più visite distinte)
Solitamente, una sessione è associata a un
singolo utente dell’applicazione web
Il framework si occupa della persistenza della
sessione

Usando cookie se il browser li supporta
Tramite URL rewriting altrimenti

© SUPSI-DTI
Silvia Giordano
Architecture 73
10/06/2004
HttpSession
Per ottenere l’HttpSession, basta chiamare il
metodo getSession() della richiesta (come
già visto)
Anche l’HttpSession potrebbe essere usato
concorrentemente, se abbiamo Servlet che
fanno partire nuovi Thread
Se si usa URL rewriting, bisogna avere cura di
chiamare encodeURL() su ogni URL che viene
inclusa nella risposta!

Argomenti avanzati
Molte operazioni sulle o delle servlet generano eventi
(modello publish/subscribe)
Caricamento
Creazione
e scaricamento di una servlet
o associazione di una sessione
ecc.

© SUPSI-DTI
Altre componenti web possono registrare il loro
interesse ad essere notificate quando l’evento x si
verifica, implementando l’interfaccia xListener
Uso molto raro…
Silvia Giordano
Architecture 75
10/06/2004
Argomenti avanzati
Re-routing,

inclusione e filtri
È possibile alterare il cammino “naturale” di
richieste e risposte
Re-routing:
le richieste possono essere inoltrate da
una servlet a un’altra (o a un CGI!)
Inclusione: la risposta di una servlet (o CGI) può
essere inclusa in quella di un’altra
Filtri: la richiesta o risposta può passare attraverso
uno o più post-processori, che la possono modificare
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 76
38
Caratteristiche delle Servlet

Velocità

Portabilità

molto veloci, il codice è compilato, e una volta
caricato viene tenuto in memoria dal server – bassa
latenza e alta banda
ottima – Java è sempre lo stesso ovunque
Fattori temporali

© SUPSI-DTI
provare una Servlet richiede (i) modificare il codice
(ii) compilare il codice (iii) riconfigurare il web
server: non è adatto alla prototipazione rapida
Silvia Giordano
10/06/2004
Architecture 77
Caratteristiche delle Servlet

Competenze

con poche aggiunte, basta conoscere Java
Per servlet complesse, occorre conoscere Java bene…
Supporto

© SUPSI-DTI
il supporto da parte di terzi è ancora un po’ limitato (ma in
crescita: si aspetta che diventi standard in Apache)
la tecnologia è portabile, ma al momento dipende molto da
Sun/IBM/Borland/Oracle
Ci sono ambienti di sviluppo molto belli e completi (inclusi
Eclipse e IBM WebSphere Studio)
Silvia Giordano
10/06/2004
Architecture 78
39
Deployment
Punto
dolente!
Ogni server ha modalità
proprie per la
configurazione
Esistono però formati
standard di deployment

© SUPSI-DTI
Silvia Giordano
Sono parte delle specifiche
J2EE
Architecture 79
10/06/2004
Confronto fra CGI, Perl e Servlet
Caratteristica
CGI
mod_perl
Servlet
Portabile fra web server
si
no (solo Apache)
si (limitata)
Portabile fra S.O.
si (con poche varianti)
parziale
si
Un processo per ogni
richiesta
si
no
no
Perdite di memoria
(leak)
no
si
no (in teoria)
Linguaggio
C, Perl, sh, ecc.
Perl
Java
Tipi stretti
no
no
si
Persistenza
no (va fatta a mano)
no (va fatta a mano)
si
Persistenza verso DB
no (va fatta a mano)
si
si
Portabilità fra DB
no (ad hoc)
no (ad hoc)
si (via JDBC)
Controllo dei diritti
no (solo via S.O.)
no (solo via S.O.)
si (diritti Java)
Supporto da IDE
no
no
si (es.: WebSphere)
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 80
40
JavaServer Pages – JSP

Le pagine JSP sono normali
documenti testuali
Contentono un mix di markup
standard (es., HTML) e di
istruzioni speciali
Concettualmente simili alle
pagine ASP (ma più potenti e
portabili)
© SUPSI-DTI
Silvia Giordano
Architecture 81
10/06/2004
JSP e Servlet
Le Servlet funzionano bene per pagine con
tanto contenuto e poca “grafica”
Però tutta la pagine deve essere generata in
Java...

...bisogna mettere mano al codice Java anche solo
per cambiare il colore di sfondo!
JSP (come ASP) immerge codice (Java) in
pagine HTML

© SUPSI-DTI
separazione fra presentazione e logica
Silvia Giordano
10/06/2004
Architecture 82
41
Esempio: una pagina JSP
<HTML>
<%@ page language=“java” import=“it.netikos.JSP” %>
<H1>Benvenuto!</H1>
Oggi è
<jsp:useBean id=“calendario” class=“JSPCalendar” />
<UL>
<LI>giorno: <%= calendario.getDayOfMonth() %>
<LI>mese: <%= calendario.getMonth() %>
<LI>anno: <%= calendario.getYear() %>
</UL>
<% if (calendario.get(Calendar.AM_PM)==Calendar.AM) { %>
buon giorno!
<% } else { %>
buona seeeeeraaaaa...
<% } %>
</HTML>
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 83
Elementi di una pagina JSP

Una pagina JSP può contenere cinque tipi
di elementi:
1.
2.
3.
4.
5.
© SUPSI-DTI
direttive JSP, fra <%@ e %>
azioni JSP, fra <jsp: e />
(ma vedremo più avanti una versione estesa)
espressioni, fra <%= e %>
scriptlet, ovvero codice fra <% e %>
parti fisse, tutto il resto
Silvia Giordano
10/06/2004
Architecture 84
42
Direttive JSP
Ci

© SUPSI-DTI
sono tre tipi di direttive:
di pagina (linguaggio, dimensioni buffer,
trattamento errori, ecc.)
include (per inserire altri file dentro la pagina)
taglib (estensioni del linguaggio JSP)
Silvia Giordano
Architecture 85
10/06/2004
Azioni JSP
(istanzia un bean e gli
assegna un nome)
jsp:setProperty (assegna un valore a una
proprietà di un bean)
jsp:getProperty (legge il valore di una
proprietà, lo converte in stringa, e lo manda
in output)
... e alcune altre
jsp:useBean
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 86
43
Espressioni
fra <%= e %> viene valutata
Il valore ottenuto viene converito in stringa
La stringa viene sostituita al posto di <%= ...
%>
L’espressione
© SUPSI-DTI
Silvia Giordano
Architecture 87
10/06/2004
Scriptlet
Il
codice fra <% e %> viene eseguito
L’immersione può anche essere parziale,
come nel nostro esempio precedente:
<% if (calendario.get(Calendar.AM_PM)==Calendar.AM) { %>
buon giorno!
<% } else { %>
buona seeeeeraaaaa...
<% } %>
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 88
44
Trattamento delle pagine JSP
Ma,
esattamente, cosa
accade quando un web
server deve trattare una
pagina JSP?
Quali
caratteristiche
derivano alle JSP da
questo trattamento?
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 89
Trattamento delle pagine JSP

La prima volta che al server viene richiesta una
certa pagina JSP, oppure se la pagina è stata
modificata rispetto all’ultimo accesso
precedente, la pagina viene compilata e
diventa una Servlet (.java)
La Servlet viene a sua volta compilata e
produce un file eseguibile (.class)
Il codice del .class viene caricato nel server,
viene eseguito, e tenuto pronto per eventuali
altre richieste successive
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 90
45
Trattamento delle pagine JSP
Container
p.class
Java compiler
client
client
client
p.java
JSP compiler
p.jsp
p.jsp
© SUPSI-DTI
Silvia Giordano
Spazio web
10/06/2004
Architecture 91
Caratteristiche di JSP
Ereditano
tutte le buone caratteristiche delle
Servlet
In più, rendono facile fare modifiche:

© SUPSI-DTI
la compilazione è automatica – si può fare
prototipazione rapida
se si vuole modificare l’aspetto delle pagine HTML,
non c’è bisogno di toccare il codice – il livello di
competenze richiesto è più basso
Silvia Giordano
10/06/2004
Architecture 92
46
Uso tipico di JSP
Il merito principale delle JSP è di separare la
presentazione (parte HTML) dalla logica
applicativa (parte codice)
Per sfruttare al meglio questa separazione, è
bene ridurre al minimo le scriptlet <% … %>, e
spostare tutta la logica all’interno di JavaBean
appropriati
Implementazione in stile MVC (Model-ViewController)

© SUPSI-DTI
Silvia Giordano
Architecture 93
10/06/2004
Uso tipico di JSP
L’architettura MVC prevede un modello astratto
della realtà che si vuole modellare (M)
Separatamente, uno strato di software legge lo
stato del modello e ne produce una vista (V)
Analogamente, uno strato di software detto
controller interpreta le azioni dell’utente e le
effettua apportando modifiche al modello (C)
Nel nostro caso, M è implementato come un
insieme di Javabean; pagine JSP fungono da V e
C

Con una chiara separazione fra
presentazione e logica applicativa:
La pagina JSP può essere creata
inizialmente dal programmatore, ma poi
migliorata graficamente e mantenuta da
un designer HTML
Il programmatore può cambiare il
comportamento dell’applicazione
modificando i bean, senza più toccare la
pagina JSP

© SUPSI-DTI
Silvia Giordano
Architecture 95
10/06/2004
H2S Architecture via JSP (1)
http
Web
jk
Controller
browser
Jsp
Servlet
smsq
smsSender H2SServer
© SUPSI-DTI
Silvia Giordano
10/06/2004
DB
jdbc
H2S
H2SClient
Architecture 96
48
H2S Architecture via JSP (2)
http
Web
jk
Controller
browser
Jsp
DB
smsq
jdbc
smsSender H2SServer
© SUPSI-DTI
Silvia Giordano
H2SClient
H2S
Architecture 97
10/06/2004
Components Role

Web/Application Server
Access Functionality
UnSafe Document Repository (imgs,..)
Application Server CGI

Dynamic Presentation
Check Controls
Business Logic
Security
Data Access Functionality

© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 98
49
JavaServer Faces
JavaServer Faces (JSF) è una tecnologia di
interfaccia utente per applicazioni Web, basata
sulle tecnologie tipiche di Java (servlet e JSP)
In particolare, fornisce una tag library che
mette a disposizione molti tag per la
costruzione di interfacce grafiche, la
validazione dell’input, e il routing degli eventi

© SUPSI-DTI
Silvia Giordano
Architecture 99
10/06/2004
JavaServer Faces
I tag JSF vengono tradotti con opportuni
elementi di FORM HTML (o, potenzialmente,
con altri meccanismi adatti allo scopo)
I FORM così generati sono dinamici

Componenti GUI possono apparire all’interno di
<c:if>, <c:forEach>, ecc.
Il framework si occupa del re-rendering e del
dispatching
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 100
50
References

Java Servlet 2.4 Specification

Java Servlet Web site

Java Servlet Technology

http://java.sun.com/products/servlet/download.html#specs
http://java.sun.com/products/servlet
Capitolo 11 di E. Armstrong, J. Ball et al., “The J2EE 1.4 Tutorial”,
Novembre 2003
M. Hall, J. Brown, “Core Servlets Java and JavaServer
Pages, vol 1: Core Technologies”, 2nd edition
C. McClanaham, E. Burns, “JavaServer Faces Specification”, v1.0
JavaServer Face Web page
http://java.sun.com/products/jsf
© SUPSI-DTI
Silvia Giordano
10/06/2004
Architecture 101
51