Architetture parte I ARCHITETTURE

Architetture parte I a.a. 2004-5 parte 1 a.a. 2004/05 Tecnologie Web 1 Parte I: ARCHITETTURE L evoluzione del Client/Server Database servers e Fat client Architetture Multi-Tier CORBA a.a. 2004/05 Tecnologie Web 2 1

Parte II ARCHITETTURE Business Objects: COM (Component Object Model) e DCOM (Distributed COM) Enterprise Java Beans (J2EE) Microsoft.NET SOA (Service Oriented Architecture) Web Services Parte III UML a.a. 2004/05 Tecnologie Web 3 Prerequisiti Concetti di object oriented design (breve accenno durante il corso) MS windows (utente) Internet WWW (utente) a.a. 2004/05 Tecnologie Web 4 2

Testi Di Riferimento Orfali, Harkey, Edwards: the Essential Distributed objects Survival guide, WILEY Orfali, Harkey: client/server Programming with Java and CORBA, WILEY Budi Kurniawan: Java for the Web with Servlets, JSP, and EJB: A Developer's Guide to J2EE Solutions, Paperback a.a. 2004/05 Tecnologie Web 5 L evoluzione del Client/Server HOST solution MINI solution Enterprise End User PC stand alone PC networking CLIENT SERVER a.a. 2004/05 Tecnologie Web 6 3

Allocazione Delle Componenti SERVER Data Management Logic/ Control NETWORK Presentation CLIENT a.a. 2004/05 Tecnologie Web 7 Allocazione Delle Componenti Un applicazione può essere suddivisa logicamente in tre parti: la presentazione che gestisce l interfaccia utente (gestione degli eventi grafici, controlli formali sui campi in input, help, ) la logica applicativa vera e propria la gestione dei dati persistenti su database Fisicamente queste componenti dovranno essere allocate su client e server. La scelta della politica di allocazione di queste componenti porta alla classificazione della pagina successiva. a.a. 2004/05 Tecnologie Web 8 4

Classificazione delle soluzioni Client/Server I Timesharing: la soluzione monolitica precedente al client/server, tutto risiede sul server, il terminale è a caratteri, l interfaccia poco amichevole Client Presentation: solo la logica di gestione dell interfaccia utente è locale al client, è il caso degli X-Terminal ma anche dei browser (senza applet) Distributed Application: la logica applicativa è distribuita (ad esempio: controlli sul client, elaborazioni più pesanti sui server. A questa categoria appartengono soluzioni quali: stored procedure, architetture three-tier, browser+applet. a.a. 2004/05 Tecnologie Web 9 Classificazione delle soluzioni Client/Server II Central Database (detto anche fat client o twotier ): sul server rimangono solo i dati, in rete passano comandi SQL. E la soluzione più diffusa nella prima stagione del client/server Distributed Database: sui client risiedono anche i dati, la soluzione risolve alcune lentezze del fat client ma con problemi proibitivi di allineamento dati. Ha avuto successo solo in caso di utenti mobili (automazione forza vendita, tecnici di manutenzione impianti ) a.a. 2004/05 Tecnologie Web 10 5

Classificazione delle soluzioni Client/Server Timesharing Client Presentation Distributed Application Central Database Distributed Database Data Data Data Data Data Server Logic Logic Logic Presentation Data Logic Logic Logic Presentation Presentation Presentation Presentation Client Char. Terminal X-Terminal PC PC PC Centralized Decentralized a.a. 2004/05 Tecnologie Web 11 Le ere del Client/Server a.a. 2004/05 Tecnologie Web 12 Da: Byte Aprile 95 6

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 a.a. 2004/05 Tecnologie Web 13 Monoliti (IT stovepipe) - II User interface Logic Data Management Enterprise a.a. 2004/05 Tecnologie Web 14 7

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 a.a. 2004/05 Tecnologie Web 15 User interface Architetture client/server - III Client Client Client Logic Data Management Enterprise Server a.a. 2004/05 Tecnologie Web 16 8

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 a.a. 2004/05 Tecnologie Web 17 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 Data Management Enterprise Adapter Server Adapter a.a. 2004/05 Tecnologie Web 18 9

PRINCIPALI CARATTERISTICHE: Standard: SQL, ODBC, DRDA Stored Procedure Two Phase Commit Replicazioni Asincrone On-Line Data Warehouse Database Servers VANTAGGI: Alta produttività dei linguaggi 4GL Prodotti maturi ed efficienti Buona standardizzazione LIMITI: Espressività limitata al solo modello entity relationship Limitata scalabilità e tuning per grandi sistemi Oracle DB2 MS SQL Server Sybase Informix a.a. 2004/05 Tecnologie Web 19 Central Database (Fat Client) Esempio di prodotti Applicazione Driver ODBC Driver DB Protocollo di rete Scritta in Visual Basic Driver ODBC Oracle Oracle SQL*NET TCP/IP Ethernet Protocollo di rete TCP/IP RDBMS Oracle a.a. 2004/05 Tecnologie Web 20 10

Problemi del Fat Client I Forte sollecitazione della rete - prestazioni penalizzate Forte uso delle risorse dei client Scalabilità difficile Manutenzione costosa Accesso ai dati poco protetto da errori di programmazione In internet download degli applet lento a.a. 2004/05 Tecnologie Web 21 Miglioramenti al modello Database Server Problemi del fat client : uso delle Stored Procedure Decentramento: Replicazioni Asincrone On- Line progettare siti distribuiti su più sedi riducendo i problemi di scalabilità a.a. 2004/05 Tecnologie Web 22 11

RDBMS: Stored Procedures Utilizzando comandi SQL l'interazione client/server è elevata: declare C cursor for select * from T where... Client declare open Server open C fetch fetch C update fetch update update... fetch update a.a. 2004/05 Tecnologie Web 23 RDBMS: Stored Procedure Con le stored procedure l'interazione client/server è ridotta e più efficiente: create procedure P @nome varchar(40) declare C cursor... while (ci sono dati) begin fetch... if... update... end Client execute Server execute P "Rossi" Attenzione: le Stored Procedure non sono portabili da un RDBMS all altro! a.a. 2004/05 Tecnologie Web 24 12

Replicazioni Asincrone London New York DB DB Dati replicati Dati primari locali Dati primari DB Tokio a.a. 2004/05 Tecnologie Web 25 Replicazione Asincrona - caratteristiche Un prodotto di replicazione dovrebbe garantire: Configurabilità dei dati da replicare Sincronizzazione automatica dei DB Propagazione cambiamenti "al più presto" Protezione delle transazioni e integrità referenziale dei dati replicati Routing ottimizzato dei dati Supporto di più RDBMS Supporto di RDBMS localizzati sui PC client (mobile computers) a.a. 2004/05 Tecnologie Web 26 13

Integrità referenziale Replicazione di testata e dettagli di un ordine di acquisto DATI PRIMARI order 100 DATI REPLICATI order 100 item A item B item A item B not yet available a.a. 2004/05 Tecnologie Web 27 Routing delle repliche New York Tokio London Singapore Hong Kong Sydney Glasgow Hamburg Rome a.a. 2004/05 Tecnologie Web 28 14

Routing delle repliche 1. informazioni trasferite da New York a Tokio e a Londra, 2. poi da queste ultime ai siti a livello sottostante. 3. New York aggiorna 8 siti tramite due siti (router) minimizza il volume di messaggi trasmessi da New York. ogni passaggio ad un livello intermedio implica dei tempi di giacenza dell'informazione da replicare mantenere basso il numero di livelli intermedi. a.a. 2004/05 Tecnologie Web 29 Middleware Middleware: : software di sistema che permette l interazione a livello applicativo fra programmi in un ambiente distribuito Facilitano e gestiscono interazioni tra applicazioni su piattaforme eterogenee LAN ristrette Complesse applicazioni Utilizzo di tecnologie Web a.a. 2004/05 Tecnologie Web 30 15

80 60 40 20 0 1st Qtr 2nd Qtr Market Share Tipologie di Middleware TP monitor (OLTP) Message Oriented (MOM) Publish/Subscribe Object Request Broker (ORB) Object Transaction Monitor (OTM) a.a. 2004/05 Tecnologie Web 31 TP Monitors (OLTP: On Line Transaction Processing) PRINCIPALI CARATTERISTICHE: Proprietà ACID Bilanciamento carico dei server Sincronizzazione in Two Phase Commit Gestione pool di risorse VANTAGGI: Scalabilità e tuning per grandi sistemi Adatti ad applicazioni mission critical LIMITI: Minore produttività (pochi standard) Uso limitato di linguaggi 4GL CICS IMS Tuxedo Encina/TxSeries MS Transaction Server TIBCO Etx a.a. 2004/05 Tecnologie Web 32 16

Applicazioni Service Oriented TP Monitors DATI a.a. 2004/05 Tecnologie Web 33 TP Monitors al client sono offerti servizi (procedure remote dotate di parametri di input e output). i servizi, dotati di logica applicativa, accedono ai dati. Il TPM nasconde ai client la locazione dei servizi possono essere distribuiti e duplicati su più server permettendo così di applicare tecniche di bilanciamento di carico e di gestione delle cadute di un server). a.a. 2004/05 Tecnologie Web 34 17

Normalizzazione dei Servizi Le cinque forme normali del partizionamento applicativo I II III IV V I servizi hanno una interfaccia formale e pubblica Ciascuna funzione business appare in un servizio Ciascun funzione business appare in un solo servizio I servizi incapsulano i dati Le applicazioni incapsulano i dati Source: Gartner Group Un modulo software è normalizzato se aderisce almeno alla prima forma normale. Gli obiettivi della normalizzazione sono quelli di migliorare la chiarezza del disegno e di ridurre, o in alcuni casi eliminare, la ridondanza della logica Si possono identificare cinque forme normali come indicato in figura. Le prime tre forme normali implicano un livello di strutturazione del codice utilizzando modelli di programmazione tradizionali Le ultime due forme normali introducono il concetto di incapsulamento dei dati e quindi stanno alla base dei paradigmi object-oriented a.a. 2004/05 Tecnologie Web 35 I servizi di un TP Monitor Gestione dei processi server: attivazione, funnelling, monitoraggio e bilanciamento carichi Gestione delle Transazioni: proprietà ACID Gestione della comunicazione client/server a.a. 2004/05 Tecnologie Web 36 18

Proprietà ACID Una transazione deve essere: Atomica Consistente Isolata Durevole a.a. 2004/05 Tecnologie Web 37 Desktop La scalabilità dei sistemi 1 user 2 users 100s Division Work- group Depart- ment Enter- prise 1000s 10,000s Internet 100,000s Shared Data Connections Security Context Multithreading Load Balancing Msg Q ing High Avail Multithread Multisite Multinode Fonte: Microsoft a.a. 2004/05 Tecnologie Web 38 19

80 60 40 20 0 80 60 40 20 0 80 60 40 20 0 80 60 40 20 0 1st Qtr 1st Qtr 1st Qtr 1st Qtr 2nd Qtr 2nd Qtr 2nd Qtr 2nd Qtr Market Share Market Share Market Share Market Share 80 60 40 20 0 80 60 40 20 0 80 60 40 20 0 80 60 40 20 0 1st Qtr 1st Qtr 1st Qtr 1st Qtr 2nd Qtr 2nd Qtr 2nd Qtr 2nd Qtr Market Share Market Share Market Share Market Share Architetture Two-Tiers e Three-Tiers DB minore uso delle risorse DB DB livello intermedio DB DB suddivisione più razionale dei compiti a.a. 2004/05 Tecnologie Web 39 DB Architetture Multi-Tier Database Servers Mail/Groupware Servers Mainframe Systems Dati Logica Applicativa Interfaccia Utente NC. NetPC PC Client Mobile a.a. 2004/05 Tecnologie Web 40 20

Architetture Three-Tier: molti tipi di interfacce utente, la stessa applicazione Web+ActiveX o applet Java Web+script lato server (ASP, JSP o servlet) Visual Basic, C++, Delphi Client/Server Lotus Notes, Exchange Groupware Applicazioni real-time batch, OLTP, M&Q Logica Applicativa Persistenza dei dati a.a. 2004/05 Tecnologie Web 41 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.. a.a. 2004/05 Tecnologie Web 42 21

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) a.a. 2004/05 Tecnologie Web 43 Architetture three-tier - III Motif User interface Client Presentation layer Windows Client Telephony Client Mac Client Logic Business layer Business Rules Business Rules Business Rules Data Management Data layer Data Service Data Service Data Service Enterprise a.a. 2004/05 Tecnologie Web 44 22

Architetture three-tier - IV User Interface Service consumer Application Logic Service provider DB XML Documents Data providers Directory service a.a. 2004/05 Tecnologie Web 45 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) a.a. 2004/05 Tecnologie Web 46 23

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 a.a. 2004/05 Tecnologie Web 47 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) a.a. 2004/05 Tecnologie Web 48 24

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 a.a. 2004/05 Tecnologie Web 49 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 Data Components User Interface Logic Rules User Interface a.a. 2004/05 Tecnologie Web 50 25

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 a.a. 2004/05 Tecnologie Web 51 Infrastructure services Architetture n-tier - II forniscono funzionalità supplementari alle componenti dell applicazione (messaging, supporto alle transazioni, ) Data layer: livello dei dati dell applicazione a.a. 2004/05 Tecnologie Web 52 26

Architetture n-tier - III Browser Firewall Application client Presentation Logic Business Logic Services DB XML Documents a.a. 2004/05 Tecnologie Web 53 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 Business logic a.a. 2004/05 Tecnologie Web 54 27

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) Browser utente Request: http://patzer/hello.html Response: HTML code Web Server Local File System /htdocs/hello.html a.a. 2004/05 Tecnologie Web 55 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 Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione Web Server Business logic a.a. 2004/05 Tecnologie Web 56 28

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) a.a. 2004/05 Tecnologie Web 57 Programma Web Server 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) a.a. 2004/05 Tecnologie Web 58 29

Publish & Subscribe Publish BORSA.MILANO.* Subscribe BORSA.MILANO.COMIT BORSA.MILANO.SANPAOLO=31.123 BORSA.MILANO.COMIT=7.739 Subscribe BORSA.* BORSA.MILANO.COMIT=7.739 BORSA.MILANO.SANPAOLO=31.123 BORSA.MILANO.COMIT=7.739 BORSA.NEWYORK.COCACOLA=$135 Information Bus a.a. 2004/05 Tecnologie Web 59 Modelli di comunicazione fra programmi Program A Conversational Program B Program A Request/Reply (RPC) Call Program Return B Indipendenza dalla locazione fisica del destinatario Program A Program A Message Passing Send Receive Program B Message Queuing Enqueue Dequeue Queue Program B Indipendenza dalla locazione fisica e dalla disponibilità immediata del destinatario Indipendenza dalla locazione fisica, dalla Publish Publish and Subscribe Subscribe Indipendenza dalla locazione fisica, dalla Program Program A B disponibilità immediata, dall identità e dal Program numero di destinatari C a.a. 2004/05 Tecnologie Web 60 30

Service-oriented or Event-driven Service-oriented Architecture Interaction Uses interface metadata One-to-one connections Client directs flow Linear path of execution Closed to unforeseen input once a flow is started Client Interface proxy Server Interface stub Event-driven Notification Uses event descriptor metadata Many-to-many connections Sink (recipient) determines flow Source Dynamic, parallel, asynchronous flows Can react to new external input while process is in flight Event Sink a.a. 2004/05 Tecnologie Web 61 Applicazioni del Middleware Applicazioni interattive, sincrone request-reply : TP Monitor (OLTP) SVILUPPO NUOVE APPLICAZIONI Object Request Broker (ORB) Object Transaction Monitor (OTM) e Application Server (AS) Comunicazioni unidirezionali, asincrone store & forward : Message Oriented (MOM) Publish/Subscribe INTEGRAZIONE APPLICAZIONI o e-business a.a. 2004/05 Tecnologie Web 62 31

Approccio ad Oggetti a.a. 2004/05 Tecnologie Web 63 Approccio ad Oggetti (1) Incapsulamento di dati e regole (attributi e metodi di una Classe) Oggetto Grafico Ereditarietà Disegna( ) è contenuto Polimorfismo SpazioGrafico Scala : intero ModificaScala () LeggiScala () Forma CoordinateCentro Disegna( ) LeggiCoordinate( ) ModificaCoordinate( ) Arco Da A Window Dimensioni FormeContenute ScrollDown( ) ScrollUp( ) contiene Cerchio Rettangolo Lista Forme Contenute a.a. 2004/05 Tecnologie Raggio Web Altezza 64 Larghezza Primo( ) Prossimo( ) 32

Approccio ad Oggetti (2) Librerie di classi e Frameworks (infrastrutture di classi) Legami (binding) statici e dinamici Relazioni tra gli oggetti: specializzazione associazione aggregazione a.a. 2004/05 Tecnologie Web 65 Relazioni fra gli oggetti Mammiferi Directory Generalizzazione / Specializzazione Aggregazione Cani Impiegato File Associazione lavora presso Azienda a.a. 2004/05 Tecnologie Web 66 33

Approccio ad Oggetti - motivazioni Rende automatici alcuni principi di buona programmazione (modularità, incapsulamento) Favorisce il Riuso del Software Semplifica la manutenzione del software Possiede una buona base metodologica (OMT, Use Case, UML, ) Favorisce lo sviluppo a componenti a.a. 2004/05 Tecnologie Web 67 Limiti storici della Programmazione ad Oggetti SmallTalk, C++, non interoperabili Gli oggetti sono locali al processo che li ha generati Quindi sono oggetti non persistenti OODBMS privi di standard e spesso legati ai linguaggi di programmazione a.a. 2004/05 Tecnologie Web 68 34

80 60 40 20 0 1st Qtr 2nd Qtr Market Share Object Request Broker (ORB) Object Request Broker a.a. 2004/05 Tecnologie Web 69 Object Request Brokers Microsoft COM/DCOM OMG CORBA Tools User Interface & Navigation Distributed Operating Environment Business Process Integrated Storage a.a. 2004/05 Tecnologie Web 70 35

CORBA (Common Object Request Broker Architecture) Uno standard per architetture distribuite ad oggetti definito dall Object Management Group (OMG) http://www.omg.org/ a.a. 2004/05 Tecnologie Web 71 Object management architecture a.a. 2004/05 Tecnologie Web 72 36

Java di SunSoft Interpretato (bytecode) È direttamente portabile su molte piattaforme Sicuro Adatto ad applicazioni Internet/Intranet Annulla i costi della software distribution Indirizzato ad hardware di basso costo a.a. 2004/05 Tecnologie Web 73 1 Dall HTML statico alle applicazioni Client/Server a.a. 2004/05 Tecnologie Web 74 37

CORBA e Internet a.a. 2004/05 Tecnologie Web 75 HTML Dinamico Tier 1 Tier 2 Application server Tier 3 browser 1. richiesta.jsp Internet (htpp) 4. ritorna html HTML Web 2. richiesta dati Server JSP servlet Business 3. generazione html Objects servlet DATI a.a. 2004/05 Tecnologie Web 76 38