Architetture per le
applicazioni web-based
Mario Cannataro
1
Sommario
u Internet e le applicazioni web-based
u Caratteristiche delle applicazioni web-based
u Soluzioni per l’architettura three-tier
F Livello utente
F Livello applicativo
F Livello dati
u Valutazione delle possibili soluzioni
u Conclusioni
2
1
Internet
e le applicazioni web-based
u Internet, da “semplice” veicolo per lo scambio di
informazioni, sta evolvendo verso una piattaforma per:
F lo sviluppo, la diffusione e l'esecuzione di applicazioni distribuite
(web-based)
u L’evoluzione delle tecnologie:
F sta radicalmente cambiando il modo di realizzare e diffondere il
software
i Network Centric Computing, CORBA
F il concetto stesso di software è destinato a mutare per adattarsi
alla nuova realtà
i Software “free”
3
Applicazioni web-based
u Applicazioni che permettono di accedere, tramite web,
alle applicazioni / sistemi informativi aziendali
F Inizialmente, via interfaccia web a preesistenti sistemi aziendali
(scarsa integrazione)
F Successivamente, completa integrazione fra sistemi informativi
aziendali tradizionali e i server Web.
u Tutto il patrimonio informativo (di processo) aziendale
può essere utilizzato via Web, ottenendo così una serie
di vantaggi tecnologici ed economici
4
2
Applicazioni web-based:
vantaggi
u Possibilità di aumentare o uniformare i canali d’accesso
alle applicazioni aziendali:
F TCP/IP = infrastruttura
F web-browser = client
u Facilità di aggiornamento e distribuzione:
F gestione centralizzata sul server,
F “pubblicazione” e/o update ⇒ distribuzione “universale”,
u Accesso multi-piattaforma:
F l’accesso è indipendente, entro certi limiti, dall’hardware e dal
sistema operativo utilizzato dagli utenti.
5
Applicazioni web-based:
vantaggi
u Riduzione dei costi di gestione (cost-of-ownership):
F attraverso l’impiego di client leggeri, siano essi Network
Computer o Personal Computer, purchè l’interfaccia utente sia
esclusivamente il browser
F uniformando e centralizzando i servizi trasversali (sicurezza,
accounting, assistenza).
u Scalabilità:
F un’applicazione web-based ben progettata può crescere insieme
alle esigenze dell’azienda
F diverse dimensioni (rete, server applicativo, database)
6
3
Applicazioni web-based:
caratteristiche
u Contesto di esecuzione
F Internet, Intranet, Extranet
* impatto su: client, requisiti del server, sicurezza
u Gestione della Sicurezza
F Tecnologia basata su crittografia asimmetrica e certificati digitali
i SET, Https, SSL
* Impatto non solo su client, server e processi organizzativi
(gestione dei certificati), ma anche:
* integrazione con la politica di sicurezza aziendale
i autenticazione su server web,
i autorizzazione tramite database aziendale preesistente
7
Applicazioni web-based:
caratteristiche
u Mantenimento dello stato dell’applicazione: ovvero,
informazioni consistenti sullo stato della connessione tra
l’utente (browser) e il server (http, …)
F Il modello d’interazione HTTP non ha il concetto di sessione,
F il server deve esplicitamente memorizzare informazioni sul
(browser) client e associargli un identificativo di sessione, per
correlare le successive richieste
F gli stati intermedi di un’elaborazione (ad es. contenuto del
“carrello della spesa”), sono visibili a seconda del contesto
u Ampiezza di Banda e stima carico
F Dimesione messaggi VS tempi di risposta
8
4
Applicazioni web-based:
caratteristiche
u Gestione delle transazioni:
F garantire un affidabile flusso di dati tra le diverse componenti
F gestire possibili stati di inconsistenza, dovuti tipicamente alla
caduta della connessione (condizioni ACID).
u Accesso a DBMS:
F utilizzare un'interfaccia standard per l'accesso ai dati
F confinare, in pochi moduli dell'applicazione, i dettagli dei
particolari DBMS utilizzati (stringhe di connessione).
9
Architetture di riferimento per le
applicazioni web-based
u L’architettura per la progettazione, lo sviluppo, e
l'erogazione delle applicazioni web-based ha un ruolo
centrale:
F interfaccia di progettazione e programmazione tra l'utente
(requisiti) e il dominio applicativo (applicazioni aziendali)
F substrato di riferimento per la risoluzione di problemi comuni ai
diversi domini (approccio generale)
F disponibilità sempre maggiore di software “free”, il cui codice è
a volte disponibile e modificabile
10
5
Architettura a tre livelli
Interfaccia
utente
Database
Lan
Internet
Logica
funzionale
11
Architettura a tre livelli
Applet
Java
Controlli
ActiveX
HTML
Script
Servlet
Java
ASP
JSP
Script
CGI
Applicazioni
Objects
Plug-in
Browser
API
Server HTTP
Stored
Procedures
DBMS
Livello utente
Livello
applicativo
Livello dati
12
6
Livello utente
u Interfaccia utente dell’applicazione:
F acquisizione dati, elaborazione locale, visualizzazione risultati
F combinazione di elementi diversi (browser, dati, programmi)
u Elaborazione sul client, VS Fruibilità (estetica/funzionale)
per il maggior numero di utenti
F dipende dal Contesto di esecuzione
u Requisiti generali:
F Leggerezza, pagine scaricabili dall’utente in tempi brevi
F Universalità, pagine fruibili da qualunque utente
13
Livello applicativo
u Funzionalità:
F gestire gli accessi e il colloquio con gli utenti
F realizzare la logica funzionale dell’applicazione, indipendentemente dal server HTTP
F accedere alle funzionalità di gestione dati, senza grosse
assunzioni sul tipo di DBMS e sul formato dei dati stessi
u Problematiche:
F mantenimento e gestione delle sessioni
i Cookies, URL-Rewriting, Session-Tracking
F gestione della coerenza della navigazione
F trattamento dei dati personali
14
7
Livello applicativo - CGI
u Common Gateway Interface (CGI)
F interfaccia standard per la cooperazione tra il server HTTP e un
programma eseguibile
F versatilità e semplicità VS inefficienza, scarsa manutenubilità
F ormai obsoleta
15
Livello applicativo - ASP
u Active Server Pages (ASP)
F pagine HTML + codice script (es. VBscript - Visual Basic script)
sul server
i il codice Vbscript viene interpretato ed eseguito dal server HTTP
F Semplicità e rapidità di costruzione, (Visual Interdev)
F L’esecuzione delle ASP sul server HTTP, può degradare le
prestazioni
F VBScript (scripting) inadeguato per progetti complessi
F Tecnologia proprietaria
16
8
Livello applicativo - JSP
u Java Server Pages (JSP)
F Simili alle ASP, pagine Html + codice Java
F Basate su Java, del quale ereditano le caratteristiche di
espressività, sicurezza e portabilità
i applicazione indipendente dalle componenti del livello applicativo,
i integrazione con le Servlet e gli Enterprise Java Beans,
i l’integrazione ASP con componenti OCX richiede una buona
conoscenza della tecnologia COM
F Per contro le JSP sono una soluzione nuova e poco collaudata, a
fronte della maturità e stabilità raggiunta dalle ASP
i scarsa disponibilità ambienti di sviluppo per JSP
17
Livello applicativo - Servlet
u Java Servlet: classi Java per applicazioni server
F portabilità - eseguite in una Java Virtual Machine (JVM), interna
o esterna al server HTTP
F efficienza - al contrario dei programmi CGI, le Servlet vengono
interpretate una sola volta, alla prima invocazione, dopo di che
rimangono in memoria per servire successive richieste.
F potenza espressiva
F utilizzo personalizzabile ed ottimizzato dei cookies
F completo accesso a filesystem e socket
18
9
Enterprise JavaBeans
u Specifica JavaSoft
F definisce un modello a componenti (lato server), per lo sviluppo
ed erogazione di applicazioni Java, su un’architettura multi-tier,
distribuita e ad oggetti
u Focus su:
F sviluppo della business logic, piuttosto che sviluppo di
infrastrutture di basso livello, (accesso dati, concorrenza,
transazioni, threading)
Enterprise
Bean
Enterprise
Bean
EJB Container
Clients
EJB Server
19
Livello applicativo:
approccio Microsoft
Microsoft Visual Basic + ASP + ADO (Active Data Objects)
Browser
utente
ASP
HTTP
VbScript
Dati
ADO
IIS
NT
20
10
Livello applicativo:
approccio Java/Sun
Http Server
Client
Browser
DBMS
Servlet
HTML
JDBC
Ciclo di vita Servlet
21
Esempio di architettura
basata su Servlet
Utente
Contenu
ti Statici
(HTML)
Servlet
JDBC
Dati
Java Runtime Environment (JVM)
APACHE JServ
APACHE
Java Servlet
Developmen
t Kit
UNIX / WINDOWS NT
22
11
Livello dati
u Funzionalità:
F garantire l'accesso strutturato e affidabile ai dati, attraverso
un'interfaccia standard
F controllo transazioni centralizzato (sul DBMS) VS controllo
decentralizzato (Livello applicativo e DBMS).
u Approcci:
F CGI,⇒ interfaccia DBI simile al JDBC Java
F ASP, ⇒ interfaccia ADO (Active Data Objects) o ODBC
i ADO permette un accesso diretto al DBMS,
i la presenza di un Manager ODBC, comporta un passo aggiuntivo.
F Servlet Java, ⇒ API JDBC
i utilizzo di codice SQL nei servlet, inviato al DBMS, oppure
i invocazione di Stored Procedures, contenute nella base di dati.
23
Valutazioni: Livello Utente
LIVELLO
UTENTE
HTML
ACCESSIBILITÀ ELABORAZIONE
PRO
CONTRO
LOCALE
Massima
Bassa
Portabilità su tutti i browser. Penalizzazione elaborativa
sul server
Uso di Script Media
Bassa
Possibilità
di
semplici Riduce poco la complessità
elaborazioni locali
del server
Applet Java Media, (eventuali Elevata
Maggiore
elaborazione, Necessarie molte risorse sul
incompatibilità tra
anche di tipo grafico
Client. Tempi elevati di
JVM)
download/elaborazione.
Possibili
incompatibilità
JVM.
Controlli Ottima in ambiente Buona
Prestazioni elevate, se si usa Scarsa
portabilità,
in
Active X Windows, No su
Windows in combinazione aggiunta ai CONTRO delle
altri ambienti
con HTML, DHTML e Applet Java.
Scripting.
24
12
Valutazioni: Livello Applicativo
LIVELLO
CGI
APPLICATIVO
Velocità
di Discreta (Perl) .
realizzazione
Efficienza
Bassa
(attivazione
di
processo per invocazione).
Portabilità
Buona (Perl)
Manutenzione
Difficoltosa.
Accesso ai dati
Buono (DBI).
Mantenimento delle Difficoltoso
sessioni
ASP
SERVLET + JSP
Ottima (ambienti di sviluppo Media
dedicati)
(difficile generazione Html)
Ottima (VbScript su IIS)
Buona (servlet attive per tutta
la sessione)
Inesistente (solo Windows e Ottima (richiede una JVM)
IIS)
Difficoltosa (generalmente per Buona (paradigma OO e Java)
gli script).
Ottima per MS SQL server, Ottima
(JDBC
supporta
meno per altri DBMS (Ado è efficientemente molti DBMS)
ancora immatura)
Medio
Ottimo (in prospettiva EJB)
25
Valutazioni: Livello Dati
LIVELLO DATI
Architettura
Accesso ai dati
PIATTA – Ogni procedura accede al DBMS
in maniera indipendente effettuando una
propria connessione
Posizionamento
Codice SQL puro viene inserito all’interno
codice applicazione delle varie procedure e viene inviato al DBMS
Accesso a DBMS CGI in C++, ma soprattutto Java (Servlet),
Object Oriented
permettono un accesso efficace a DBMS OO
CENTRALIZZATA – Una sola procedura
effettua la connessione al DBMS e gestisce
tutte le richieste di accesso
All’interno delle procedure è effettuata una
chiamata a Stored Procedure nel DBMS
Le ASP, pensate per RDBMS, possono
supportare ma con difficoltà i DBMS OO
26
13
Conclusioni
u Livello utente
F Elaborazione sul client dettata dalle necessità dell'applicazione
u Livello applicativo
F ASP è ormai una soluzione ben collaudata e molto diffusa
F I Servlet non sono ancora molto usati
i prestazioni inferiori alle ASP e carenza di ambienti di sviluppo
F ma beneficieranno delle evoluzioni della piattaforma Java
i portabilità, manutenibilità progetti complessi
u Livello dati
F Stored Procedures (app. esterni) per una gestione efficiente
F Confinare i punti di accesso ai dati
27
14
