Architetture parte I a.a. 2004-5 parte 1 a.a. 2004/05 Tecnologie Web

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

ARCHITETTURE Parte II Parte III UML Business Objects: Microsoft .NET 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

Prerequisiti Concetti di object oriented design (breve accenno durante il corso) MS windows (utente) Internet WWW (utente) a.a. 2004/05 Tecnologie Web

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

L’evoluzione del Client/Server HOST solution MINI Enterprise PC stand alone networking End User CLIENT SERVER Le architetture Client/Server nascono all’inizio degli anni ‘90 dall’esigenza di raccordare e coordinare due mondi cresciuti separatamente: Il sistema informativo aziendale, quasi sempre su mainframe, centralizzato e ben organizzato ma anche rigido e con interfacce utente poco amichevoli. Negli anni il sistema informativo si è spesso evoluto integrando, per motivi di risparmio o di decentramento anche minielaboratori (Unix o con sistemi proprietari come VMS o OS/400). I Personal Computer che si sono diffusi negli anni ‘80 e che, soprattutto con l’avvento delle interfacce grafiche e degli strumenti di produttività individuale (database locali, fogli elettronici, word processor) hanno aumentato le aspettative degli utenti in termini di velocità di realizzazione delle applicazioni e di facilità d’uso. L’avvento delle reti di PC ha poi formato isole poco integrate fra loro e, soprattutto, poco integrate con il sistema informativo aziendale. a.a. 2004/05 Tecnologie Web

Allocazione Delle Componenti Data Management Logic/ Control Presentation SERVER CLIENT NETWORK 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

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

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

Classificazione delle soluzioni Client/Server II Central Database (detto anche “fat client” o “two-tier”): 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

Classificazione delle soluzioni Client/Server Data Logic Presentation Char. Terminal X-Terminal PC Timesharing Client Distributed Application Central Database Server Centralized Decentralized 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. Central Database (detto anche “fat client” o “two-tier”): 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

Le “ere” del Client/Server Questo schema rappresenta una serie di “ondate” successive che riguardano le architetture: File server (file sharing): i server offrono servizi di file system condiviso Database server (fat client): applicazioni client/server che vedono il server come fornitore di dati, corrisponde al modello “Central Database” dello schema precedente Groupware: applicazioni collaborative che vedono i documenti (e non le tabelle relazionali) come principali dati manipolati TP monitors: sono le applicazioni di fascia alta (molti utenti) che le soluzioni database server non possono gestire Distributed objects: applicazioni ad oggetti (componenti) distribuiti - CORBA o DCOM lo schema è datato ma permette di descrivere l’evoluzione tecnologica della seconta metà degli anni 90 a.a. 2004/05 Tecnologie Web Da: Byte Aprile 95

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

Monoliti (IT stovepipe) - II User interface Logic Data Management Enterprise a.a. 2004/05 Tecnologie Web

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

Architetture client/server - III User interface Logic Data Management Server Enterprise a.a. 2004/05 Tecnologie Web

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

Architetture client/server - IV Problema: mancato riconoscimento dell’importanza della business logic Es: servizio accessibile da più device (telefonino, desktop)  stessa logica, interfaccia diversa Nuovo Client Nuovo Client User interface Client Logic Adapter Adapter Data Management Server Enterprise a.a. 2004/05 Tecnologie Web

Database Servers PRINCIPALI CARATTERISTICHE: Standard: SQL, ODBC, DRDA Stored Procedure Two Phase Commit Replicazioni Asincrone On-Line Data Warehouse 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 La soluzione presenta grandi vantaggi di produttività: il tool di sviluppo 4GL può sfruttare i cataloghi delle tabelle dei DB per essere propositivo nell’indicare al programmatore i dati da visualizzare sulle interfacce utente. I problemi di questa soluzione sono due: un client non può richiedere in modalità standard al server azioni che non riguardino i dati (ad esempio lanciare un job, o accendere una lampadina su di un pannello) questo perché il linguaggio di comunicazione è l’SQL la scalabilità (numero di utenti contemporanei) è limitata per il grande numero di risorse che vengono richieste al server (n° di processi, connessioni al DB…) a.a. 2004/05 Tecnologie Web

Central Database (Fat Client) Esempio di prodotti Esempio di prodotti Applicazione Scritta in Visual Basic Driver ODBC Driver ODBC Oracle Client Driver DB Oracle SQL*NET Protocollo di rete TCP/IP La figura mostra una configurazione classica per un’architettura Database Server (Fat Client). Si notino gli strati che ogni richiesta ad DB deve attraversare ed il numero di componenti che devono essere installate (e mantenute nel tempo) per ogni client. Ethernet TCP/IP Protocollo di rete Server Oracle RDBMS a.a. 2004/05 Tecnologie Web

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 Il modello “Central Database”, chiamato in letteratura anche fat client, è un modello in cui la logica applicativa delle transazioni interattive risiede completamente sui PC Client. L’applicazione interroga il database con comandi SQL e riceve come risposta result set (liste di righe risultato di comandi select) ed esiti di errore. Questa soluzione, benché molto diffusa attualmente, presenta alcuni inconvenienti: I messaggi che passano sulla rete sono numerosi e anche di grandi dimensioni. Le architetture fat client, come indica il nome stesso, richiedono potenziamento dei PC, in particolare CPU e memoria, che potrebbero essere risparmiati se le operazioni più pesanti fossero eseguite sul server. Una minima modifica al codice o una nuova release di qualche libreria richiedono la software distribution su tutti i PC L’accesso ai dati non è controllato: i programmatori possono far generare istruzioni SQL direttamente dai programmi su PC per accedere in modifica potenzialmente a qualsiasi tabella. E’ invece preferibile centralizzare il codice che accede ai dati critici lasciando la gestione di questo codice in pochi punti e a pochi programmatori esperti. La scalabilità del server di database potrebbe essere insufficiente al crescere del numero di client o delle esigenze, obbligando in un futuro ad investimenti consistenti. Un’architettura più distribuita consentirebbe una scalabilità migliore. a.a. 2004/05 Tecnologie Web

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à Si è tentato di superare i limiti esposti senza mettere in discussione tutta l’architettura (e senza perdere i vantaggi di produttività dei 4GL) Le stored procedure permettono di risolvere parzialmente i problemi di scarse prestazioni (vedi prossime slide) con le replicazioni asincrone si possono progettare siti distribuiti su più sedi riducendo i problemi di scalabilità a.a. 2004/05 Tecnologie Web

RDBMS: Stored Procedures Utilizzando comandi SQL l'interazione client/server è elevata: declare C cursor for select * from T where ... open C fetch C update ... Client Server declare open fetch update In un collegamento client/server il numero di round trip (micro dialoghi richiesta-risposta) è assai elevato con forte penalizzazione delle prestazioni a.a. 2004/05 Tecnologie Web

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 execute P "Rossi" Client Server execute Creando una procedura installata nel database è possibile ridurre di molto il numero di round trip La portabilità fra database non è più garantita perché siamo fuori dallo standard SQL Non è risolto il problema della scalabilità (il numero delle risorse impiegate non cambia) Attenzione: le Stored Procedure non sono portabili da un RDBMS all’altro! a.a. 2004/05 Tecnologie Web

Replicazioni Asincrone Dati primari Dati primari locali London Tokio New York DB Dati replicati Con le replicazioni asincrone è possibile replicare una parte di dati di un database verso altri database, la replica avviene tramite “trigger” che fanno partire un messaggio di replica delle variazioni verso gli altri database nell’istante in cui la variazione avviene nel database master. La replica non è sincronizzata con la modifica sul master (il master non attende l’esecuzione delle repliche remote) a.a. 2004/05 Tecnologie Web

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

Integrità referenziale Replicazione di testata e dettagli di un ordine di acquisto DATI PRIMARI DATI REPLICATI order 100 order 100 Nell’esempio in figura, sul database primario avviene l’inserimento di un nuovo ordine composto da due righe d’ordine. Essendo logicamente un’unica operazione l’inserimento viene effettuato all’interno di un’unica transazione (logical unit of work) La lettura prematura da parte di un’applicazione dei dati replicati potrebbe teoricamente causare inconsistenze, non essendo ancora stata riportata la seconda riga di ordine. Per questo motivo è importante che la replica avvenga tenendo conto del fatto che sul database primario i dati erano stati inseriti in un’unica transazione garantendo anche per i dati replicati l’integrità referenziale. item A item A item B item B not yet available a.a. 2004/05 Tecnologie Web

Routing delle repliche New York Tokio London In questo caso le informazioni vengono trasferite da New York a Tokio e a Londra, poi da queste ultime ai siti a livello sottostante. In questo modo New York aggiorna 8 siti tramite due siti che fanno funzione di router; questo minimizza il volume di messaggi trasmessi da New York. Peraltro, ogni passaggio ad un livello intermedio implica dei tempi di giacenza dell'informazione da replicare, pertanto è importante mantenere basso il numero di livelli intermedi. Singapore Hong Kong Sydney Glasgow Hamburg Rome a.a. 2004/05 Tecnologie Web

Routing delle repliche informazioni trasferite da New York a Tokio e a Londra, poi da queste ultime ai siti a livello sottostante. 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

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

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

TP Monitors (OLTP: On Line Transaction Processing) Market Share 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 I TP Monitor sono presenti sul mercato da molti anni. Il loro principale vantaggio è quello di sfruttare al meglio le risorse dei sistemi (vedi il funneling più avanti) e per questo motivo sono stati concepiti nel passato (quando tali risorse erano assai costose). In seguito sono stati impiegati soprattutto per garantire la scalabilità dei sistemi di fascia alta (centinaia-migliaia di utenti contemporanei). I TP Monitor offrono garanzie di affidabilità e permettono il bilanciamento del carico fra server che offrono gli stessi servizi. Maggiore limite al loro impiego è la limitata produttività causata dall’impossibilità di impiegare strumenti 4GL (i cataloghi dei DB non sono accedibili poiché i TP Monitor nascondono la struttura dei dati ai client). a.a. 2004/05 Tecnologie Web

TP Monitors 3-tier Applicazioni “Service Oriented” DATI Servizio La figura mostra la vista logica che il TP Monitor offre ad un client: al client sono offerti servizi (procedure remote dotate di parametri di input e output). Sono i servizi, dotati di logica applicativa, ad accedere ai dati. Il TPM nasconde ai client la locazione dei servizi (che 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

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

Normalizzazione dei Servizi 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 Le cinque forme normali del partizionamento applicativo I I servizi hanno una interfaccia formale e pubblica II Ciascuna funzione business appare in un servizio III Ciascun funzione business appare in un solo servizio IV I servizi incapsulano i dati V Le applicazioni incapsulano i dati Source: Gartner Group Un modulo software è normalizzato se aderisce almeno alla prima forma normale. a.a. 2004/05 Tecnologie Web

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

Una transazione deve essere: Proprietà “ACID” Una transazione deve essere: Atomica Consistente Isolata Durevole a.a. 2004/05 Tecnologie Web

La scalabilità dei sistemi Desktop Work- group Depart- ment Division Enter- prise 1 user 2 users 100s 1000s 10,000s Internet 100,000s Shared Data Connections Security Context Multithread Multithreading Load Balancing Multinode Msg Q’ing Multisite High Avail Fonte: Microsoft a.a. 2004/05 Tecnologie Web

Architetture Two-Tiers e Three-Tiers Market Share Market Share DB minore uso delle risorse suddivisione più razionale dei compiti livello intermedio DB Market Share DB Market Share DB Market Share a.a. 2004/05 Tecnologie Web

Architetture Multi-Tier Mail/Groupware Servers Database Servers Mainframe Systems Dati Logica Applicativa Key point: This is a transition slide. Use to introduce the topic of building 3-tier applications. NC . NetPC Interfaccia Utente PC Client Mobile a.a. 2004/05 Tecnologie Web

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

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

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

Architetture three-tier - III Motif Client Windows Client Telephony Client Mac Client User interface Presentation layer 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

Architetture three-tier - IV User Interface Service consumer Application Logic Service provider Data providers XML Documents DB Directory service a.a. 2004/05 Tecnologie Web

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

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

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

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

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 a.a. 2004/05 Tecnologie Web

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

Architetture n-Tier - II Infrastructure services forniscono funzionalità supplementari alle componenti dell’applicazione (messaging, supporto alle transazioni, …) Data layer: livello dei dati dell’applicazione a.a. 2004/05 Tecnologie Web

Architetture n-Tier - III Browser Firewall Application client Presentation Logic Services Business Logic XML Documents DB a.a. 2004/05 Tecnologie Web

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 Web Server Browser utente HTTP Business logic a.a. 2004/05 Tecnologie Web

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 Browser utente Web Server /htdocs/hello.html Response: HTML code a.a. 2004/05 Tecnologie Web

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 Web Server Browser utente Business logic Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione a.a. 2004/05 Tecnologie Web

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

Web Server Programma 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

Publish & Subscribe Information Bus 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

Modelli di comunicazione fra programmi Conversational Request/Reply (RPC) Program A B Call Return Message Passing Receive Send Message Queuing Queue Enqueue Dequeue Publish and Subscribe C Publish Subscribe Indipendenza dalla locazione fisica del destinatario Indipendenza dalla locazione fisica e dalla disponibilità immediata del destinatario Indipendenza dalla locazione fisica, dalla disponibilità immediata, dall’identità e dal numero di destinatari a.a. 2004/05 Tecnologie Web

Service-oriented or Event-driven Decision Framework: SOA interactions have interface “contracts” that describe the sequence and contents of a two-way communication process spanning two or more messages. By contrast, event-driven notification is a one-way, non-interactive form of communication that is documented by event descriptors that hold message schema. 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 Server Interface proxy Interface stub Event-driven Notification Uses event descriptor metadata Many-to-many connections Sink (recipient) determines flow Dynamic, parallel, asynchronous flows Can react to new external input while process is in flight Source Event Sink SOA and event-driven architecture have many similarities. Both are ways of combining multiple software modules into large, distributed applications. They go beyond conventional application design by separating the interface definition (or event descriptors) from the software implementation. Either may be enabled through Web services, although neither requires Web services. However, they differ in the way they organize the relationships among the modules. At the risk of oversimplification, SOA uses directed, generally bi-directional, request/response communication to delegate work to a subordinate procedure, whereas event-driven architecture uses unidirectional messaging to communicate among two or more, largely independent peer procedures. In a SOA, a client application will find, then bind to and invoke a service. In an event-driven relationship (notification), sources do not find, bind or invoke sinks. The only communication is through the data in a software event. An event source does not need to know who or what is supposed to receive the event or what the sink will do with it. Just as object-oriented developers think about and define objects, event-oriented developers think about and define events as a primary focus of attention. Applications often intermingle service and event relationships in the same set of applications. Action Item: IS architects and developers must understand the local business requirements and process models to determine if SOA, event-driven architecture or some combination of them is the best solution. a.a. 2004/05 Tecnologie Web

Applicazioni del Middleware Applicazioni interattive, sincrone “request-reply”: TP Monitor (OLTP) Object Request Broker (ORB) Object Transaction Monitor (OTM) e Application Server (AS) Comunicazioni unidirezionali, asincrone “store & forward”: Message Oriented (MOM) Publish/Subscribe SVILUPPO NUOVE APPLICAZIONI INTEGRAZIONE APPLICAZIONI o e-BUSINESS a.a. 2004/05 Tecnologie Web

Approccio ad Oggetti a.a. 2004/05 Tecnologie Web

Approccio ad Oggetti (1) Incapsulamento di dati e regole (attributi e metodi di una Classe) Ereditarietà Polimorfismo a.a. 2004/05 Tecnologie Web

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

Relazioni fra gli oggetti File Directory Generalizzazione / Specializzazione Aggregazione Associazione a.a. 2004/05 Tecnologie Web

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

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

Object Request Broker (ORB) Market Share a.a. 2004/05 Tecnologie Web

Object Request Brokers OMG CORBA Microsoft COM/DCOM Distributed Operating Environment Integrated Storage Business Process User Interface & Navigation Tools a.a. 2004/05 Tecnologie Web

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

Object management architecture a.a. 2004/05 Tecnologie Web

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

Dall’HTML statico alle applicazioni Client/Server 1 Dall’HTML statico alle applicazioni Client/Server The Internet/intranet technology has quickly evolved from static HTML achieving several enhancements: graphic controls for data entry, dynamic HTML, Java Script, ActiveX controls and Java applets. a.a. 2004/05 Tecnologie Web

CORBA e Internet a.a. 2004/05 Tecnologie Web

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