sistemi informativi dee - politecnico di bari architetture dei sistemi distribuiti
TRANSCRIPT
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari
Architetture dei sistemi distribuitiArchitetture dei sistemi distribuiti
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Sommario Sommario
• Architetture multiprocessore• Architetture client server• Architetture a oggetti distribuiti• Calcolo interoganizzativo
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Sistemi distribuitiSistemi distribuiti
• Sistemi in cui l’elaborazione delle informazioni è distribuita su diversi computer
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Vantaggi Vantaggi
• Condivisione delle risorse• Apertura• Simultaneità• Scalabilità• Fault tolerance
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Svantaggi Svantaggi
• Complessità• Protezione• Gestibilità• Non prevedibilità
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture multiprocessoreArchitetture multiprocessore
• Il software consiste in una serie di processi che possono essere eseguiti su processori separati
• Tipico nei sistemi real time: – Sistemi che raccolgono le informazioni in base alle quali
prendono decisioni e inviano segnali agli attuatori che modificano l’ambiente del sistema
– I processi possono essere eseguiti su un unico processore sotto il controllo di uno scheduler
– L’uso di processori multipli ( non obbligatorio) migliora le prestazioni del sistema
– La ripartizione dei processi è determinata da un dispatcher• Es. sistema di controllo del traffico
• I sistemi composti da processi multipli non sono necessariamente dei sistemi distribuiti
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture Architetture
• Tipi di architetture di sistema– Client server:
• Il sistema può essere considerato come un insieme di servizi forniti ai client che ne fanno uso
– A oggetti distribuiti• Il sistema è un insieme di oggetti interagenti in cui non c’è
distinzione tra fornitore e utente di servizi– Peer-to-peer: utilizzate principalmente per sistemi
personali– A servizi distribuiti
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari middlewaremiddleware
“software di mezzo”• Un sistema distribuito necessita di un software
che gestisca le diverse componenti di un sistema distribuito – Le diverse componenti possono essere implementate in
linguaggi di programmazione diversi ed eseguiti su differenti tipi di processore
Il middleware deve gestire la comunicazione e lo scambio di dati tra le diverse componenti
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture client serverArchitetture client server
• Un’applicazione viene modellata come un insieme di servizi forniti da un server e un insieme di client che li utilizza– Client, server
• identificano i processi logici (possono essere utilizzati per individare i processori su cui i processi sono eseguiti)
– Client: • devono conoscere i server disponibili• Non sanno dell’esistenza di altri client
– Server:• Diversi processi server possono essere eseguiti su un
singolo processore server
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Struttura logica dell’applicazioneStruttura logica dell’applicazione
• Un’applicazione è strutturata in 3 strati :– Presentazione:
• Rappresentazione dei dati e interazioni con l’utente
– Elaborazione applicativa:• Implementa la logica dell’applicazione
– Gestione dei dati:• Esegue tutte le operazioni sul database
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari
Architettura client server e Architettura client server e struttura logica dell’applicazionestruttura logica dell’applicazione
• Se si sta progettando un sistema distribuito ogni strato dell’applicazione dovrebbe essere distribuito su un computer diverso
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture client serverArchitetture client server
• A due livelli– Thin-client– Fat-client
• A tre livelli• A livelli multipli
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura two-tierArchitettura two-tier
È un’applicazione organizzata in un server (o diversi server identici) e un insieme di client
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Thin clientThin client
• Tutte le elaborazioni applicative e la gestione dei dati sono gestite dal server
• Il client si occupa soltanto di eseguire il software di presentazione– Esempio
• un sistema centralizzato ereditato – L’interfaccia viene migrata verso PC, l’applicazione funge da
server e gestisce tutte le elaborazioni applicative e le gestioni dei dati
• I client sono semplici dispositivi di rete (anziché dei pc), il dispositivo usa un browser internet e l’interfaccia è implementata tramite tale sistema
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Svantaggi del thin clientSvantaggi del thin client
• Pesante carico di lavoro sul server e sulla rete• La potenza di elaborazione dei dispositivi client
viene sprecata
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Fat clientFat client
• Client: – elaborazione della logica dell’applicazione– Presentazione
• Server:– È un server di transazione che gestisce le transazioni al
database
• Esempio– Bancomat, lo sportello è il client, il server è un mainframe
che gestisce il database dei conti dei clienti, l’hardware dello sportello esegue molte delle elaborazioni relative al cliente associate a una transazione, lo sportello non si connette direttamente al database ma a un monitor di telelaborazione , un middleware che organizza le comunicazioni con i client e serializza le transazioni
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Svantaggi del fat clientSvantaggi del fat client
• La gestione del sistema è più complessa:– Le funzionalità dell’applicazione sono divise su diversi
computer– Quando deve essere modificato il software è necessario
reinstallare su ogni computer client– Costi notevoli
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Svantaggi del two-tierSvantaggi del two-tier
• Gli strati logici sono mappati su due soli sistemi– Problemi di scalabilità e prestazioni ( nel thin client)– Problemi di gestione del sistema ( nel fat client
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura three-tierArchitettura three-tier
• La presentazione, l’elaborazione applicativa e la gestione dei dati sono processi logicamente separati ed eseguiti su processori diversi– Esempio
• Un sistema di internet banking: il database dei clienti, mainframe fornisce i servizi di gestione dei dati, un server web fornisce i servizi applicativi estratti conto, invio di pagamenti, ecc, il computer dell’utente, dotato di un browser internet è il client
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Vantaggi dell’architettura three-tierVantaggi dell’architettura three-tier
• Ottimizzazione del trasferimento delle informazioni tra il server web e il server database: è possibile usare un protocollo veloce di basso livello
• Utilizzo di un middleware efficiente per recuperare le informazioni dal database
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura multi-tierArchitettura multi-tier
• Il modello three-tier può essere esteso ad un modello multi-tier in cui sono presenti server aggiuntivi:
• Usato quando le applicazioni devono accedere e utilizzare dati di database diversi
• Tra il server applicativo e i server database si posiziona un server di integrazione che raccoglie i dati distribuiti e li invia all’applicazione come se provenissero da un unico database
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari 3-multitier vs 2-tier3-multitier vs 2-tier
• Maggiore scalabilità: – le architetture 3 e multi tier distribuiscono l’elaborazione
applicativa su diversi server: • sono più scalabili delle architetture a due livelli
• Minor traffico di rete– rispetto alle thin-client
• Facilità nell’aggiornamento della parte applicativa (essendo posizionata centralmente)
• Risposta più rapida alle richieste dell’utente (essendo l’elaborazione distribuita sui server applicativo e database)
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari
Uso delle diverse applicazioni Uso delle diverse applicazioni client serverclient server
• Due livelli thin-client:– Sistemi ereditati in cui non è attuabile la separazione tra
l’elaborazione applicativa e la gestione dei dati– Applicazioni di calcolo intensivo ( es. compilatori) con minima
gestione dati– Applicazioni dati intensivi con elaborazione applicativa
inesistente• Due livelli fat-client
– Elaborazione applicativa fornita da software off-the shelf( es. foglio di calcolo)
– Elaborazione di calcolo intensivo di dati ( es. visualizzazione)– Funzionalità end-user stabili e realizzare in un ambiente con
gestione del sistema ben salda• Tre o multi livelli
– Applicazioni su vasta scala con centinaia o migliaia di client– Dati e applicazioni volatili– Dati integrati da sorgenti multipli
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Limiti del modello client serverLimiti del modello client server
• Scarsa flessibilità del progetto:– Occorre decidere dove bisogna fornire i servizi
• Progettare la scalabilità• Fornire mezzi per distribuire il carico tra diversi
server in caso di aggiunta di nuovi client
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture a oggetti distribuitiArchitetture a oggetti distribuiti
• I componenti fondamentali sono oggetti che dotano di un’interfaccia un insieme di servizi da essi forniti– Altri oggetti richiamano questi servizi
• Non vi è distinzione logica tra client e server• Gli oggetti possono essere distribuiti su diversi
computer di una rete e comunicare attraverso un middleware che fornisce un’interfaccia trasparente tra gli oggetti, Object Request Broker, ORB
• Un insieme di servizi permette agli oggetti di comunicare e di essere aggiunti e rimossi dal sistema
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Vantaggi del modello Vantaggi del modello
• Ritardare le decisioni su dove e come collocare i servizi
• architettura molto aperta• Flessibile• Scalabile • È possibile riconfigurare il sistema
dinamicamente attraverso la migrazione di oggetti sulla rete
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Esempio Esempio
Un’applicazione di vendita al dettaglio può essere strutturata secondo approcci differenti:
1. usando un modello logico di architettura ad oggetti distribuiti:– Le funzionalità del sistema sono fornite in termini di servizi o combinazione di
servizi • (es. controllo delle scorte, dell’ordine, delle merci ecc.)
– Forniti usando una serie di oggetti distribuiti, oggetti business forniscono servizi specifici del dominio, domain specific
• Tale modello logico può essere realizzato come modello di implementazione
1. Usando un approccio ad oggetti distribuiti per implementare un sistema client server:
2. Il modello logico è un modello client server ma sia client che server sono realizzati come oggetti distribuiti che comunicano attraverso un software bus
1. Il sistema è facilmente modificabile, es passare da un’architettura two tier ad una three tier
2. Il server o i client possono essere implementati come singolo oggetto distribuito ma essere composti da oggetti più piccoli che forniscono specifici servizi
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Altri esempiAltri esempi
Sistemi in cui le architetture ad oggetti distribuiti sono indicate:Sistemi data miningcatena di negozi al dettaglio con vendita di generi alimentari e di arredamento che vuole cercare relazioni tra gli acquisti:
Ogni database può essere incapsulato in un oggetto distribuito con un’interfaccia che fornisce accesso di sola lettura ai prpri dati
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari oggetti distribuiti vs client serveroggetti distribuiti vs client server
• Le architetture a oggetti distribuiti sono più complesse da progettare
• I sistemi client server riflettono il modo naturale di pensare ai sistemi,
• Riproducono molte transazioni umane in cui gli utenti richiedono e ricevono servizi da altri utenti specializzati in tali servizi
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari
Implementazione di Implementazione di un’architettura a oggetti un’architettura a oggetti
distribuiti distribuiti
• Richiede un middleware per gestire la comunicazione tra gli oggetti distribuiti– il middleware è detto Object Request Broker (ORB)
• Gli oggetti possono essere implementati utilizzando linguaggi di programmazione diversi, eseguiti su piattaforme diverse e non aver bisogno di conoscere tutti i nomi degli altri oggetti del sistema
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Il middlewareIl middleware
• Il middleware deve garantire la comunicazione trasparente tra gli oggetti:
È richiesto a due livelli:• Comunicazione logica:
– fornisce funzionalità che permettono agli oggetti su computer diversi di scambiarsi dati e controllare le informazioni
• Standard sviluppati sono CORBA, COM per facilitare la comunicazione tra oggetti su piattaforme diverse
• Componenti:– Il middleware fornisce una base per lo sviluppo di
componenti compatibili• Standard come EJB, CORBA, ActiveX forniscono una base per
l’implementazione di componenti con metodi standard che possono essere interrogati e utilizzati da altri componenti
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Calcolo distribuito inter-organizzativoCalcolo distribuito inter-organizzativo
• Calcolo distribuito– Un’organizzazione ha un insieme di server sui quali
distribuire il carico– i server sono tutti collocati nella stessa organizzazione– Possono essere applicati standard e processi operativi interni– I client hanno il limitato compito dell’esecuzione
dell’interfaccia utente (per i sistemi web-based)
• Nuovi modelli di calcolo distribuito– Peer-to-peer (p2p)
• Basato sull’esecuzione del calcolo da parte di nodi di rete individuali
– orientato ai servizi• Basato su standard per lo scambio di dati
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture peer-to-peerArchitetture peer-to-peer
• Sono sistemi decentralizzati dove i calcoli possono essere eseguiti da ogni nodo della rete e non ci sono distinzioni tra client e server.
• Il sistema generale viene progettato per trarre vantaggio dalla potenza di calcolo e della memoria disponibile su una vasta rete di computer
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Applicazioni del peer-to-peerApplicazioni del peer-to-peer
• usate per lo più per:– sistemi personali
• Condivisione di file, sistemi di messaggeria istantanea• Fornire comunicazione diretta tra utenti senza utilizzare un
server intermedio
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Prospettive sul p2pProspettive sul p2p
• L’architettura logica della rete è l’architettura di distribuzione del sistema
• L’architettura dell’applicazione è l’organizzazione generica dei componenti all’interno di ogni tipo di applicazione
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura logica del p2pArchitettura logica del p2p
• Architetture – decentralizzate – Semi-centralizzate
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura decentralizzataArchitettura decentralizzata
• Ogni nodo della rete può essere a conoscenza di ogni altro nodo e può connettersi ad esso per scambiare dati– Nella pratica, però, i nodi vengono organizzati in
“località” con alcuni nodi che fungono da ponte ad altre località
• I nodi della rete non sono solo elementi funzionanti, ma anche commutatori di comunicazione che indirizzano i dati e i segnali di controllo da un nodo all’altro
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Vantaggi/svantaggi Vantaggi/svantaggi
• Ridondanza – Tolleranza agli errori e ai nodi che si disconnettono dalla
rete
• Overhead del sistema:– La stessa ricerca può essere elaborata da diversi nodi
con aumento della comunicazione tra diversi peer
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architettura semi-centralizzataArchitettura semi-centralizzata
• Uno o più nodi fungono da server per semplificare la comunicazione tra i nodi
• Un server aiuta a stabilire il contatto tra i nodi della rete e a coordinare i risultati del calcolo
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari P2p vs service orientedP2p vs service oriented
• P2p più efficiente• Problemi: protezione fiducia• Preferibili in applicazioni non critiche con
relazioni di lavoro già esistenti tra le organizzazioni
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Architetture orientate ai serviziArchitetture orientate ai servizi
• Web-service– Una rappresentazione standard di risorse elaborative o
informative che può essere utilizzata da altri programmi
• Usando un web-service le organizzazioni che vogliono rendere accessibili le proprie informazioni ad altri programmi possono farlo definendo e pubblicando un’interfaccia di servizio che specifica i dati disponibili e come accedervi
• Un webservice è un’istanza della più generica nozione di servizio:
– Un atto o una prestazione offerta da un parte a un’altra[Lovelock, 1996]La sua erogazione è indipendente dall’applicazione che sta
usando il sistema
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Modello di servizioModello di servizio
• Un fornitore offre un servizio definendo la sua interfaccia e implementandone la sua funzionalità
• Un richiedente si collega al servizio dalla propria applicazione che deve includere codice per richiamare quel servizio e per elaborarne i risultati
• Per assicurarsi che il servizio sia accessibile agli utenti esterni, il fornitore inserisce un record in un registro dei servizi che comprende informazioni sul servizio e su cosa fa
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari
Modello service oriented vs Modello service oriented vs modello distributed-object modello distributed-object
• I servizi possono essere offerti da ogni fornitore di servizio dentro o fuori un’organizzazione
• I fornitori di servizio rendono pubbliche le informazioni sul servizio in modo che qualsiasi utente autorizzato possa utilizzarlo
– Fornitore ed utente non devono negoziare cosa il servizio fa• Le applicazioni possono attendere il collegamento ai servizi finchè non
sono consegnati o fino all’esecuzione– Le applicazioni possono cambiare fornitore di servizio dinamicamente mentre il
servizio è in esecuzione• Un fornitore può riconoscere nuovi servizi che possono essere creati
collegando i servizi esistenti in modo innovativo• Gli utenti possono pagare i servizi a seconda dell’utilizzo anziché della
fornitura– Anziché acquistare un componente costoso, l’utente può utilizzare un servizio
esterno che pagherà solo quando necessario• Le applicazioni possono essere più piccole poiché possono implementare la
gestione delle eccezioni come servizio esterno• Le applicazioni possono essere reattive e adattarsi alle variazioni
dell’ambiente collegandosi a diversi servizi
Sistemi Sistemi InformativiInformativiDEE - Politecnico di BariDEE - Politecnico di Bari Vantaggi/svantaggi Vantaggi/svantaggi
• Architetture debolmente accoppiate– I collegamenti ai servizi possono cambiare durante
l’esecuzione
• Sviluppo basato su standard– Standard sviluppati solo di recente