Sistemi Informativi Distribuiti

Transcript

1 Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1

2 Sistemi informativi distribuiti Un sistema informativo è un sistema hardware/software che consente l'esecuzione di operazioni per l'accesso e la modifica di informazioni. Un sistema si dice distribuito se i diversi componenti, che concorrono allo svolgimento delle funzionalità del sistema, sono eseguiti su calcolatori indipendenti (interconnessi in rete). Lo scopo di un sistema informativo è, in generale, automatizzare in tutto o in parte i processi svolti da un'organizzazione (azienda, ente, comunità di persone, ecc.) dislocata su un territorio Spesso il sistema informativo è solo una parte di un sistema più complesso nel mondo reale, che comprende persone ed oggetti Per progettare un sistema informativo distribuito è necessario definire protocolli di comunicazione tra i vari componenti formati per l'interscambio dei dati necessari a richiedere operazioni e a restituire le risposte Sistemi Informativi Distribuiti Giuseppe Loseto 2

3 Architettura di un sistema informativo distribuito - 1 client presentation layer application logic layer resource management layer sistema informativo Presentation layer: interfaccia verso utenti e sistemi esterni (client) per consentire l'accesso ai servizi forniti dal sistema Esempio: GUI (graphical user interface) Application logic (a.k.a. business logic, business processes, business rules): implementazione delle operazioni svolte dal sistema Resource management layer: interfaccia del sistema verso le sorgenti di dati su cui deve operare. data sources Sistemi Informativi Distribuiti Giuseppe Loseto 3

4 Architettura di un sistema informativo distribuito - 2 Il client e il presentation layer possono essere separati: è ad esempio il caso delle Web application, in cui il livello di presentazione è implementato in HTML + CSS + linguaggi di scripting, mentre il client è il Web browser integrati: un unico oggetto permette all'utente di accedere direttamente ai servizi del livello di logica applicativa Esempio: una banca può fornire l'operatività ai clienti tramite Web application e/o tramite app per smartphone Non è detto che il client agisca per un utente umano; può trattarsi di un altro sistema Similmente, tra le sorgenti dati possono esserci (R)DBMS, ma anche filesystem, altri tipi di basi di dati o sistemi esterni a cui il nostro sistema deve richiedere dati per poter svolgere i suoi compiti L'architettura vista può dunque essere ripetuta ricorsivamente, con sistemi che fungono da componenti per sistemi più grandi Sistemi Informativi Distribuiti Giuseppe Loseto 4

5 Metodologie di progetto Due principali metodologie di progetto per sistemi informativi distribuiti Top-down Bottom-up Sistemi Informativi Distribuiti Giuseppe Loseto 5

6 Progettazione top-down La funzionalità del sistema è divisa in componenti (moduli), che non possono operare separatamente ma sono interdipendenti (tightly coupled, fortemente accoppiati) Tipicamente l'hardware è omogeneo e il sistema è progettato come distribuito sin dal principio La progettazione è direttamente guidata dai requisiti (funzionali e non funzionali) del sistema Sistemi Informativi Distribuiti Giuseppe Loseto 6

7 Metodologia top-down 1. Definire canali di accesso e piattaforme client 2. Definire i formati di presentazione e i protocolli per i client. 3. Definire le funzionalità necessarie a fornire i contenuti ed i formati richiesti dal livello di presentazione. 4. Definire le sorgenti di dati e l'organizzazione dei dati necessarie per implementare la logica applicativa. client presentation layer application logic layer resource management layer information system Sistemi Informativi Distribuiti Giuseppe Loseto 7

8 Progettazione bottom-up - 1 Nuova applicazione Applicazione legacy In un progetto bottom-up, si parte da componenti di base che esistono già (legacy). Essi sono sistemi stand-alone che devono essere integrati in nuovi sistemi. I componenti non cessano necessariamente di operare anche come componenti stand-alone (perché le vecchie applicazioni devono continuare a funzionare contemporaneamente a quelle nuove). Questo approccio è molto applicato, perché spesso esistono già dei componenti che non possono essere facilmente sostituiti. I componenti del sistema risultano, in genere, debolmente accoppiati (loosely coupled) Sistemi legacy Sistemi Informativi Distribuiti Giuseppe Loseto 8

9 Metodologia bottom-up 1. Definire i canali di accesso e le piattaforme client 2. Esaminare le risorse esistenti e le funzionalità che offrono 3. Definire dei wrapper per le risorse esistenti e integrare le loro funzionalità in una interfaccia coerente 4. Adattare l'output del livello di logica applicativa in modo che possa essere usato con i canali d'accesso e i protocolli definiti per i client. client presentation layer application logic layer resource management layer information system Sistemi Informativi Distribuiti Giuseppe Loseto 9

10 Confronto tra le metodologie di progetto La progettazione top-down è più semplice perché condizionata da meno vincoli. Il progetto risulta così più facilmente conforme ai requisiti di sistema: funzionali (operazioni da svolgere) non funzionali (prestazioni, disponibilità, sicurezza, etc.) L'approccio top-down è però applicabile solo se il sistema deve essere realizzato da zero. Attualmente nella maggioranza dei casi si parte da sistemi legacy: la progettazione dev'essere, gioco forza, di tipo bottom-up. Molto del lavoro in tali casi riguarda il middleware, livello intermedio necessario per integrare i componenti legacy fornendo interfacce comuni affrontando l'eterogeneità hardware e software dei componenti affrontando le problematiche (non previste nei sistemi legacy) legate alla natura distribuita del nuovo sistema Sistemi Informativi Distribuiti Giuseppe Loseto 10

11 Componenti del sistema, layer e connessioni Ogni box rappresenta un componente del sistema. Ogni freccia rappresenta una connessione tra due componenti. Una maggiore modularità permette maggior distribuzione e parallelismo, agevola l'incapsulamento, la progettazione basata su componenti e il riuso. Però più componenti implicano più connessioni: occorre mantenere più sessioni, è richiesta una maggior coordinazione. Il sistema diventa più complesso da monitorare e gestire. Più sono i livelli, maggiore è il numero di passi intermedi da compiere per completare un'operazione. Impatto sulle prestazioni del sistema. I progettisti devono bilanciare la flessibilità della progettazione modulare con le richieste prestazionali delle applicazioni. Non c'è problema di progettazione che non si possa risolvere aggiungendo un livello di indirezione. Non c'è problema di prestazioni che non si possa risolvere eliminando un livello di indirezione. Sistemi Informativi Distribuiti Giuseppe Loseto 11

12 Middleware: obiettivi Il middleware costituisce un livello di indirezione tra i client e il resto del sistema Così facendo: Semplifica il progetto dei client riducendo il numero di interfacce Fornisce accesso ai componenti sottostanti in modo trasparente Si occupa di individuare le risorse, accedervi e raccogliere i risultati Funge da piattaforma per l'integrazione tra più sistemi Sistemi Informativi Distribuiti Giuseppe Loseto 12

13 Middleware: vantaggi e limiti L'adozione di uno strato di middleware permette di Centralizzare il controllo (semplifica la progettazione del sistema) Modularizzare e distribuire su un cluster di nodi sia i componenti di logica applicativa sia quelli di gestione delle risorse Maggiore scalabilità Conferire proprietà al sistema, tecnicamente difficili (costose) da implementare ma di utilità generale (riusabili in sistemi diversi), es.: Tolleranza ai guasti (fault tolerance) Bilanciamento del carico (load balancing) Logging Sicurezza e policy configurabili per l'accesso alle risorse Replica (replication) dei dati Persistenza Di contro, l'uso di middleware comporta Maggior overhead di comunicazione tra i componenti del sistema Necessità di un'interfaccia stabile non solo tra presentazione e logica applicativa, ma anche tra logica applicativa e gestione delle risorse Sistemi Informativi Distribuiti Giuseppe Loseto 13

14 Comunicazione tra moduli La comunicazione tra moduli può avvenire mediante interazioni Bloccanti Più semplici da progettare e implementare Minori performance Non bloccanti Maggiori performance Maggiore disaccoppiamento Ma richiede più risorse ed è più difficile da implementare Le tecnologie nuove prevedono spesso interazioni bloccanti, poi evolvono verso il modello non bloccante client Call idle time Answer request() do with answer queue queue receive process return server Receive Response Sistemi Informativi Distribuiti Giuseppe Loseto 14

15 Riferimenti Alonso, Casati, Kuno, Machiraju, Web Services Concepts, Applications, Challenges, Springer, 2004, cap. 1 Sistemi Informativi Distribuiti Giuseppe Loseto 15