Architetture parte I

1. Architettureparte I a.a. 2004-5 parte 1 Tecnologie Web

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

3. ARCHITETTURE Parte II 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 Tecnologie Web

4. Prerequisiti • Concetti di object oriented design (breve accenno durante il corso) • MS windows (utente) • Internet WWW (utente) Tecnologie Web

5. 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 Tecnologie Web

6. HOST solution MINI solution Enterprise CLIENT SERVER End User PC stand alone PC networking L’evoluzione del Client/Server Tecnologie Web

7. SERVER Data Management NETWORK Logic/ Control Presentation CLIENT Allocazione Delle Componenti Tecnologie Web

8. 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. Tecnologie Web

9. 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. Tecnologie Web

10. 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…) Tecnologie Web

11. Client Presentation Distributed Application Central Database Distributed Database Timesharing 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 Classificazione delle soluzioni Client/Server Tecnologie Web

12. Le “ere” del Client/Server Tecnologie Web Da: Byte Aprile 95

13. 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 Tecnologie Web

14. Monoliti (IT stovepipe) - II User interface Logic Data Management Enterprise Tecnologie Web

15. 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 Tecnologie Web

16. Architetture client/server - III Client Client Client User interface Logic Data Management Server Enterprise Tecnologie Web

17. 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 Tecnologie Web

18. 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 Tecnologie Web

19. 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 Tecnologie Web

20. Central Database (Fat Client) Esempio di prodotti Esempio di prodotti Applicazione Scritta in Visual Basic DriverODBC Driver ODBC Oracle Client DriverDB Oracle SQL*NET Protocollo di rete TCP/IP Ethernet TCP/IP Protocollo di rete Server Oracle RDBMS Tecnologie Web

21. 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 Tecnologie Web

22. 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à Tecnologie Web

23. Client Server declare open fetch update fetch update fetch update RDBMS: Stored Procedures • Utilizzando comandi • SQL l'interazione • client/server è • elevata: • declare C cursor • for select * from T • where ... • open C • fetch C • update ... Tecnologie Web

24. Client Server execute 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" Attenzione: le Stored Procedure non sono portabili da un RDBMS all’altro! Tecnologie Web

25. London DB New York Dati replicati DB Dati primari locali Tokio Dati primari DB Replicazioni Asincrone Tecnologie Web

26. 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) Tecnologie Web

27. item B not yet available Integrità referenziale • Replicazione di testata e dettagli di un ordine di acquisto DATI PRIMARI DATI REPLICATI order 100 order 100 item A item A item B Tecnologie Web

28. New York Tokio London Rome Hong Kong Sydney Singapore Glasgow Hamburg Routing delle repliche Tecnologie Web

29. 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. Tecnologie Web

30. 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 Tecnologie Web

31. Tipologie di Middleware • TP monitor (OLTP) • Message Oriented (MOM) • Publish/Subscribe • Object Request Broker (ORB)  • Object Transaction Monitor (OTM) Tecnologie Web

32. Market Share 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 Tecnologie Web

33. Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio Servizio TP Monitors Applicazioni “Service Oriented” 3-tier DATI Tecnologie Web

34. 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). 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 Tecnologie Web

36. Proprietà “ACID” • Una transazione deve essere: • Atomica • Consistente • Isolata • Durevole Tecnologie Web

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

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

39. Architetture Multi-Tier Mail/Groupware Servers Database Servers Mainframe Systems Dati Logica Applicativa NC . NetPC Interfaccia Utente PC Client Mobile Tecnologie Web

40. 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 Logica Applicativa Persistenza dei dati Applicazioni real-time batch, OLTP, M&Q 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 .. Tecnologie Web

42. 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) Tecnologie Web

43. 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 Tecnologie Web

44. Architetture three-tier - IV User Interface Service consumer Application Logic Service provider Data providers XMLDocuments DB Directory service 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) Tecnologie Web

46. 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 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) Tecnologie Web

48. 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 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 User Interface Data Components Logic Rules User Interface Tecnologie Web

50. 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 Tecnologie Web