Applicazioni Web-based e non
Elementi di base di un’applicazione
• I dati da trattare (dati sugli utenti, sul servizio offerto,
etc.)
• Logica applicativa (business logic), ovvero le
funzionalità che l’applicazione deve offrire, il tipo di
trattamento dei dati previsto (quali operazioni si
possono fare), etc.
• Interfaccia utente
– interfaccia web (e.g., per browser, o testuale)
– stand-alone (applicazione locale alla macchina su cui gira)
Laboratorio di Servizi Web Ardissono
1
Architetture delle applicazioni
•
•
•
•
Monoliti
Client/server (two-tier)
Three-tier
N-tier
Laboratorio di Servizi Web Ardissono
2
Monoliti (IT stovepipe) - I
• Popolari ai tempi dei mainframe
• Monoliti:
– pezzi di codice indivisibili
– controllavano l’intera logica dell’applicazione, dalla
gestione (e memorizzazione) dei dati, fino all’interfaccia
utente
– gestivano applicazioni stand-alone
• Popolarità dovuta a:
– mainframe adatti ad eseguire pochi processi stand-alone,
anzichè diversi processi comunicanti
– non c’erano ancora i database
Laboratorio di Servizi Web Ardissono
3
Monoliti (IT stovepipe) - II
User interface
Logic
Data Management
Enterprise
Laboratorio di Servizi Web Ardissono
4
Architetture client/server - I
• Dalla fine degli anni ‘70 alla metà degli anni ‘80
– Diffusione di server più piccoli ed economici dei
mainframe, e di workstations e PC
– Diffusione di RDBMS
• Suddivisione delle applicazioni in due parti:
– backend (server): gestione di database (+ o – complessi) e
dei compiti di manipolazione dei dati
– frontend (client): gestione interfaccia utente
 maggiore scalabilità, rispetto a monoliti (carico
computazionale distrbuito sui client)
 sviluppo più veloce di applicazioni che accedono agli
(stessi) dati
Laboratorio di Servizi Web Ardissono
5
Architetture client/server - III
Client
Client
Client
User interface
Logic
Data
Management
Server
Enterprise
Laboratorio di Servizi Web Ardissono
6
Architetture client/server - II
Svantaggi:
• Traffico di messaggi intenso (frontend comunica
continuamente con server dati)
• Logica di business non gestita in componente separata
dell’architettura: suddivisa tra frontend e backend
•  client e server di applicazione dipendono l’uno
dall’altro
– difficile riutilizzare interfaccia in servizio che accede a dati
diversi
– difficile utilizzare DB da frontend diversi
– tendenza a cablare la business logic nell’interfaccia utente
 cambio di logica significa cambiare anche interfaccia
Laboratorio di Servizi Web Ardissono
7
Architetture client/server - IV
• Problema: mancato riconoscimento dell’importanza
della business logic
– Es: servizio accessibile da più device (telefonino, desktop)
 stessa logica, interfaccia diversa
User interface
Client
Nuovo Client
Nuovo Client
Logic
Adapter
Adapter
Data
Management
Enterprise
Server
Laboratorio di Servizi Web Ardissono
8
Architetture three-tier - I
• Introdotte all’inizio degli anni ‘90
• Business logic trattata in modo esplicito:
– livello 1: gestione dei dati (DBMS, file XML, …..)
– livello 2: business logic (processamento dati, …)
– livello 3: interfaccia utente (presentazione dati, servizi)
• Ogni livello ha obiettivi e vincoli di design propri
• Nessun livello fa assunzioni sulla struttura o
implementazione degli altri:
– livello 2 non fa assunzioni su rappresentazione dei dati, né
sull’implementazione dell’interfaccia utente
– livello 3 non fa assunzioni su come opera la business logic ..
Laboratorio di Servizi Web Ardissono
9
Architetture three-tier - II
• Non c’è comunicazione diretta tra livello 1 e livello 3
– Interfaccia utente non riceve, né inserisce direttamente dati
nel livello di data management
– Tutti i passaggi di informazione nei due sensi vengono
filtrati dalla business logic
• I livelli operano senza assumere di essere parte di una
specifica applicazione
–  applicazioni viste come collezioni di componenti
cooperanti
–  ogni componente può essere contemporaneamente parte
di applicazioni diverse (e.g., database, o componente logica
di configurazione di oggetti complessi)
Laboratorio di Servizi Web Ardissono
10
Architetture three-tier - III
User interface
Presentation layer
Motif
Client
Logic
Business layer
Data Management
Data layer
Windows
Client
Telephony
Client
Mac
Client
Business
Rules
Business
Rules
Business
Rules
Data
Service
Data
Service
Data
Service
Enterprise
Laboratorio di Servizi Web Ardissono
11
Architetture three-tier - IV
User Interface
Application Logic
Service
consumer
Service
provider
Data
providers
DB
XML
Documents
Laboratorio di Servizi Web Ardissono
Directory
service
12
Vantaggi di architetture three-tier - I
• Flessibilità e modificabilità di sistemi formati da
componenti separate
– componenti utilizzabili in sistemi diversi
– modifica di una componente non impatta sul resto del
sistema (a meno di cambiamenti negli API)
– ricerca di bug più focalizzata (separazione ed isolamento
delle funzionalità del sistema)
– aggiunta di funzionalità all’applicazione implica estensione
delle sole componenti coinvolte (o aggiunta di nuove
componenti)
Laboratorio di Servizi Web Ardissono
13
Vantaggi di architetture three-tier - II
• Interconnettività
– API delle componenti superano il problema degli adattatori
del modello client server  N interfacce diverse possono
essere connesse allo stesso servizio etc.
– Facilitato l’accesso a dati comuni da parte di applicazioni
diverse (uso dello stesso gestore dei dati da parte di business
logics diverse)
• Gestione di sistemi distribuiti
– Business logic di applicazioni distribuite (e.g., sistemi
informativi con alcuni server replicati e client remoti)
aggiornabile senza richiedere aggiornamento dei client
– Aggiornamento dei client comunque costoso
Laboratorio di Servizi Web Ardissono
14
Vantaggi di architetture three-tier - III
• Applicazioni distribuite geograficamente
– Data server centrale
– Business logic gestita da server logici regionali
– Client remoti (ev. con business logic per maggior
scalabilità)
• Per ridurre traffico di rete e latency del servizio, anche
il data server centrale può essere replicato (ma,
gestione consistenza dati)
Laboratorio di Servizi Web Ardissono
15
Svantaggi di architetture three-tier - I
• Dimensioni delle applicazioni ed efficienza
– Pesante uso della comunicazione in rete  latenza del
servizio
– Comunicazione tra componenti richiede uso di librerie SW
per scambio di informazioni  codice voluminoso
• Legacy software
– Molte imprese usano software vecchio (basato su modello
monolitico) per gestire i propri dati 
• difficile applicare il modello three-tier per nuove
applicazioni
• introduzione di adapters per interfacciare il legacy SW
Laboratorio di Servizi Web Ardissono
16
Three-tier è concettuale, non fisico
Si possono implementare architetture three-tier
su due livelli di macchine, o anche su uno solo...
Data and Logic Server
Clients
User
Interface
Data
Components
Logic
Rules
User
Interface
Laboratorio di Servizi Web Ardissono
17
Architetture n-Tier - I
Permettono configurazioni diverse. Elementi
fondamentali:
• Interfaccia utente (UI)
– gestisce interazione con utente
– può essere un web browser, WAP minibrowser, interfaccia
grafica, …
• Presentation logic
– definisce cosa UI presenta e come gestire le richieste utente
• Business logic
– gestisce regole di business dell’applicazione
Laboratorio di Servizi Web Ardissono
18
Architetture n-Tier - II
• Infrastructure services
– forniscono funzionalità supplementari alle componenti
dell’applicazione (messaging, supporto alle transazioni, …)
• Data layer:
– livello dei dati dell’applicazione
Laboratorio di Servizi Web Ardissono
19
Architetture n-Tier - III
Browser
Firewall
Application client
Presentation Logic
Services
Business Logic
DB
XML
Documents
Laboratorio di Servizi Web Ardissono
20
Applicazione Web-based tipica - I
• Interfaccia utente: gestita sul browser utente
• Logica applicativa: gestita sul server, che si
interfaccia al web attraverso Web Server
• Livello dei dati: su database, eventualmente
localizzato su macchina diversa da quella del Web
Server, per questioni di sicurezza
Browser
utente
HTTP
Web
Server
Laboratorio di Servizi Web Ardissono
Business logic
21
Applicazione Web-based tipica - II
• Richiesta di pagina HTML statica (pagina HTML
memorizzata nel file system dell’applicazione – il
codice della pagina non viene generato eseguendo
programmi applicativi sul server)
Request: http://patzer/hello.html
Local File System
Web
Server
Browser
utente
/htdocs/hello.html
Response: HTML code
Laboratorio di Servizi Web Ardissono
22
Applicazione Web-based tipica - III
• Richiesta di pagina dinamica (pagina HTML generata
dinamicamente, sulla base della richiesta del client –
codice della pagina generato eseguendo programmi
applicativi sul server)
Request:
http://www.di.unito.it/service1.html
Browser
utente
Web
Server
Business logic
Response: pagina HTML di
risposta, con eventuali link
e bottoni per continuare interazione
Laboratorio di Servizi Web Ardissono
23
Browser Web
• Può essere visto come interfaccia utente universale
– Invoca Web Server per richiedere pagine statiche o
dinamiche
– Riceve contenuti web da Web Server invocato e li presenta
sulla macchina dell’utente
• Browser moderni (MS Explorer, Netscape Navigator, …)
interpretano codice HTML
• Alcuni browser interpretano codice XML
– Può eseguire script (e.g., javascript) localmente, per
effettuare semplici computazioni (e.g., controllo correttezza
input utente)
– Può scaricare plug-in da Web Server per eseguire
programmi localmente (e.g., animazioni Flash o altro)
Laboratorio di Servizi Web Ardissono
24
Web Server
• Programma che
– gira su una macchina server accessibile da internet
– resta in ascolto di richieste (da parte di client web)
su porta HTTP. E.g., http://www.di.unito.it:8080
– gestisce le richieste che arrivano (recupera pagina
html richiesta, esegue programmi, invoca
programmi associati a servizi richiesti, etc.)
– restituisce a client una risposta (risultato della
richiesta, messaggio di errore)
Laboratorio di Servizi Web Ardissono
25
La Piattaforma J2EE
• J2SE: Java 2 Platform, Standard Edition.
– Ambiente runtime per esecuzione di applicazioni Java e
insieme di API (Application Programming Interface)
per sviluppare applicazioni di vario tipo (applets,
applicazioni stand-alone, …)
• J2EE: Java 2 Platform, Enterprise Edition:
– framework per lo sviluppo di applicazioni server-side
complesse
• J2ME: Java 2 Platform, Micro Edition:
– framework per lo sviluppo di applicazioni su micro
device (PDA, telefonini Java-enabled, etc.)
Laboratorio di Servizi Web Ardissono
26
Proprietà
• J2EE: adatta allo sviluppo di applicazioni Web-based
a livello di impresa, e.g., per commercio elettronico
• Il suo competitor è Microsoft .net
• Impresa (enterprise): organizzazione di business
• Enterprise software applications: applicazioni SW
che facilitano la gestione delle attività di impresa
– interagire con clienti e partners via Internet
– facilitare l’interazione tra le varie parti di un’impresa,
eventualmente distribuite geograficamente
– gestione del business: resource planning, gestione inventari,
...
Laboratorio di Servizi Web Ardissono
27
Caratteristiche di applicazioni “enterprise”
• Necessità informative: spesso le stesse informazioni
sono utilizzate sotto forma diversa dai consumatori 
attività di business diverse processano le stesse
informazioni, ma utilizzando formati diversi
• Complessità dei processi di business: necessità di
raccogliere, gestire e condividere informazioni,
basandosi su una logica complessa
• Eterogeneità delle applicazioni: un’impresa utilizza
molte applicazioni basate su architetture e tecnologie
diverse (legacy software)
Laboratorio di Servizi Web Ardissono
28
Requisiti di gestione del software d’impresa
• Velocizzazione del processo di sviluppo delle
applicazioni: cambiano gli standard, le tecnologie, le
applicazioni devono entrare in uso velocemente
• Affidabilità e disponibilità: il SW deve essere
sempre accessibile (Web) ed essere affidabile (e.g.,
transazioni)
• Sicurezza: protezione delle informazioni dell’azienda
• Scalabilità: accesso efficiente a risorse, tolleranza al
carico di milioni di utenti (Web)
• Integrazione: le applicazioni vanno integrate nei
sistemi informativi già esistenti
Laboratorio di Servizi Web Ardissono
29
J2EE
• Si sono sviluppate soluzioni diverse per affrontare i
vari problemi
• J2EE: permette di integrare tali soluzioni e facilita lo
sviluppo del SW
– Modello di programmazione con approccio alla costruzione
di applicazioni basato su API
– Infrastruttura che permette di eseguire le applicazioni in
modo efficiente e scalabile
• basato su Java  portabile
• basato sul concetto di Contenitore  servizi di gestione di base
(messaggi, transazioni, ciclo di vita delle componenti, …) forniti
dall’infrastruttura
• Modulare, componenti riusabili
Laboratorio di Servizi Web Ardissono
30
In questo corso di laboratorio
• Utilizzeremo JWSDP (Java Web Services
Development Pack) come infrastruttura per lo
sviluppo di applicazioni Web-based
• Sperimenteremo l’uso di tecnologie di
–
–
–
–
accesso a Database mediante JDBC
gestione di XML
gestione di applicazioni Server-side (Servlets, JSP)
…
• Non sperimenteremo l’uso degli EJB (Enterprise Java
Beans), trattati nel corso di Sperimentazioni di
Ingegneria del Software (SpisII)
Laboratorio di Servizi Web Ardissono
31