Sistemi Informativi Distribuiti

Corso di Sistemi Informativi
Modulo II
Corso di Laurea Magistrale in
Ingegneria Gestionale
A. A. 2013- 2014
SISTEMI INFORMATIVI – MODULO II
Sistemi Informativi Distribuiti
1
Sistemi Informativi
A.A. 2013/14
Sistemi informativi distribuiti
DEI - Politecnico di Bari
• 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
Architettura di un sistema
informativo distribuito - 1
Sistemi Informativi
A.A. 2013/14
DEI - Politecnico di Bari
• Presentation layer: interfaccia verso utenti
e sistemi esterni (client) per consentire
l'accesso ai servizi forniti dal sistema
client
client
presentation
presentation
layer
layer
application
application logic
logic
layer
layer
resource
resource
management
management layer
layer
sistema informativo
– 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
data sources
sources
Sistemi Informativi Distribuiti – Giuseppe Loseto
3
Sistemi Informativi
A.A. 2013/14
DEI - Politecnico di Bari
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
Sistemi Informativi
A.A. 2013/14
Metodologie di progetto
DEI - Politecnico di Bari
• Due principali metodologie di progetto per sistemi informativi
distribuiti
– Top-down
– Bottom-up
Sistemi Informativi Distribuiti – Giuseppe Loseto
5
Sistemi Informativi
A.A. 2013/14
Progettazione top-down
DEI - Politecnico di Bari
• 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
Sistemi Informativi
A.A. 2013/14
Metodologia top-down
DEI - Politecnico di Bari
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
Sistemi Informativi Distribuiti – Giuseppe Loseto
information system
1. Definire canali di accesso
e piattaforme client
7
Sistemi Informativi
A.A. 2013/14
Progettazione bottom-up - 1
DEI - Politecnico di Bari
Applicazione
legacy
Nuova
applicazione
•
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
Sistemi Informativi
A.A. 2013/14
Metodologia bottom-up
DEI - Politecnico di Bari
1. Definire i canali di accesso
e le piattaforme client
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.
presentation
layer
application logic
layer
resource
management layer
Sistemi Informativi Distribuiti – Giuseppe Loseto
information system
2. Esaminare le risorse esistenti
e le funzionalità che offrono
client
9
Sistemi Informativi
A.A. 2013/14
DEI - Politecnico di Bari
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
Sistemi Informativi
A.A. 2013/14
DEI - Politecnico di Bari
•
•
•
•
•
•
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
Sistemi Informativi
A.A. 2013/14
Middleware: obiettivi
DEI - Politecnico di Bari
• 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
Sistemi Informativi
A.A. 2013/14
Middleware: vantaggi e limiti
DEI - Politecnico di Bari
• 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
Sistemi Informativi
A.A. 2013/14
Comunicazione tra moduli
DEI - Politecnico di Bari
• La comunicazione tra moduli può
avvenire mediante interazioni
client
server
Call
Receive
– Bloccanti
• Più semplici da progettare e
implementare
• Minori performance
idle time
Response
Answer
– 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
request()
queue
do with answer
Sistemi Informativi Distribuiti – Giuseppe Loseto
receive
process
return
queue
14
Sistemi Informativi
A.A. 2013/14
DEI - Politecnico di Bari
Riferimenti
• Alonso, Casati, Kuno, Machiraju, Web Services – Concepts,
Applications, Challenges, Springer, 2004, cap. 1
Sistemi Informativi Distribuiti – Giuseppe Loseto
15