Architettura dei Sistemi
Software
Luca Cabibbo
Luca Cabibbo ASWLuca Cabibbo ASW
Introduzione aisistemi distribuiti
dispensa asw410
marzo 2018
Introduzione ai sistemi distribuiti1
A distributed system is one in which the failure of a computer
you didn’t even know existed can render your own computer unusable.
Leslie Lamport
Luca Cabibbo ASW
- Fonti
[POSA4] Pattern-Oriented Software Architecture (Volume 4): A Pattern Language for Distributed Computing. Wiley, 2007.
Coulouris, G, Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, 2012.
Shaw, M. Procedure Calls are the Assembly Language of Software Interconnections: Connectors Deserve First-Class Status. Technical report CMU/SEI-1994-TR-2, 1996.
Taylor, R.N., Medvidovic, N., and Dashofy, E.M. Software Architecture: Foundations, Theory, and Practice. John Wiley & Sons, 2010.
Chapter 5, Connectors
Bernstein, P. Middleware. Communications of the ACM, 1996.
Introduzione ai sistemi distribuiti2
Luca Cabibbo ASW
- Obiettivi e argomenti
Obiettivi
introdurre i sistemi distribuiti
introdurre i connettori e il middleware
introdurre i pattern POSA per gli stili di comunicazione distribuita
Argomenti
introduzione ai sistemi distribuiti
connettori
middleware
stili di comunicazione e pattern [POSA]
discussione
Introduzione ai sistemi distribuiti3
Luca Cabibbo ASW
* Introduzione ai sistemi distribuiti
Tutti i grandi sistemi informatici sono oggi sistemi distribuiti
Alcune possibili definizioni – un sistema distribuito è
intuitivamente, un sistema software in cui l’elaborazione è distribuita su più computer – anziché centralizzata su un singolo computer
un sistema di elaborazione in cui un numero di componenti coopera comunicando in rete [POSA4]
un sistema in cui i componenti hardware o software posizionati in computer collegati in rete comunicano e coordinano le proprie azioni solo tramite lo scambio di messaggi [Coulouris]
un sistema in cui il fallimento di un computer di cui nemmeno conosci l’esistenza può rendere inutilizzabile il tuo computer [Lamport]
Introduzione ai sistemi distribuiti4
Luca Cabibbo ASW
Introduzione ai sistemi distribuiti
Detto in altro modo (ed intuitivamente)
ogni sistema distribuito è costituito da un insieme di elementi software, in esecuzione su più nodi, collegati in rete – la rete consente a questi elementi software di comunicare tra di loro
nei sistemi distribuiti sono possibili diverse modalità di comunicazione tra gli elementi software distribuiti – così come sono possibili diverse modalità di organizzazione/strutturazione di questi elementi
studieremo entrambi questi aspetti nel seguito del corso
i sistemi distribuiti possono offrire numerosi benefici (ad es., sostengono scalabilità e disponibilità) – tuttavia, allo stesso tempo sollevano diversi problemi (ad es., di concorrenza, sicurezza e per la possibilità che si verifichino dei guasti)
la sfida posta dai sistemi distribuita è cercare di ottenere i possibili benefici, minimizzando gli svantaggi
Introduzione ai sistemi distribuiti5
Luca Cabibbo ASW
Benefici della distribuzione
Connettività e collaborazione
possibilità di condividere risorse hardware e software –compresi dati e applicazioni
Tolleranza ai guasti
grazie alla possibilità di replicare risorse hardware e software
Prestazioni e scalabilità
la possibilità di aggiungere risorse fornisce la capacità di migliorare le prestazioni e sostenere un carico che aumenta (scalabilità orizzontale)
Introduzione ai sistemi distribuiti6
Luca Cabibbo ASW
Benefici della distribuzione
Sistemi inerentemente distribuiti
alcune applicazioni sono inerentemente distribuite – non sono possibili opzioni diverse
Apertura
l’uso di protocolli standard aperti favorisce l’interoperabilità di hardware e software di fornitori diversi
Economicità
i sistemi distribuiti offrono, in genere, un rapporto qualità/prezzo migliore rispetto ai sistemi centralizzati (ovvero, basati su mainframe)
Introduzione ai sistemi distribuiti7
Luca Cabibbo ASW
Svantaggi legati alla distribuzione
Complessità
i sistemi distribuiti sono più complessi di quelli centralizzati
più difficile da progettare e da comprendere e valutare (in termini di qualità)
Sicurezza
l’accessibilità in rete pone problematiche di sicurezza
Non prevedibilità
i tempi di risposta dipendono dal carico del sistema e dal carico della rete, che possono cambiare anche rapidamente
Gestibilità
è necessario uno sforzo maggiore per la gestione dell’ambiente di esecuzione e delle applicazioni
Introduzione ai sistemi distribuiti8
Luca Cabibbo ASW
Svantaggi legati alla distribuzione
Complessità accidentale
introdotta dall’uso di strumenti di sviluppo non opportuni
Metodi e tecniche non adeguati
i metodi di analisi e progettazione più diffusi fanno spesso riferimento allo sviluppo di applicazioni mono-processo, mono-thread
i metodi di analisi e progettazione per sistemi distribuiti sono più complessi e meno diffusi
Continua re-invenzione e riscoperta di concetti e soluzioni
l’industria del software ha una lunga storia di ri-creazione di soluzioni (spesso incompatibili con le precedenti) di problemi che sono stati già risolti
questo è vero anche nel campo dei sistemi distribuiti
Introduzione ai sistemi distribuiti9
Luca Cabibbo ASW
Ipotesi errate comuni sui sistemi distribuiti
Ad esempio, Peter Deutsch ha identificato 8 ipotesi errate comuni sui sistemi distribuiti
si tratta di assunzioni che ognuno fa quando sviluppa per la prima volta un’applicazione distribuita – che possono provocare gravi guai e un’esperienza di apprendimento dolorosa
1. la rete è affidabile
2. la latenza è zero
3. la banda a disposizione è infinita
4. la rete è sicura
5. la topologia della rete non cambia
6. c’è un amministratore (che risolve tutti i problemi della rete)
7. il costo di trasporto è zero
8. la rete è omogenea
Introduzione ai sistemi distribuiti10
Luca Cabibbo ASW
- Parentesi: mainframe
La tecnologia dei sistemi centrali – più noti come mainframe – è ancora attuale e in continua evoluzione – si veda, ad es., Il Mainframe di Barbarino et al. (2010)
è una tecnologia “ricca di funzionalità sempre più avanzate e di innovazioni tecniche via via più sofisticate”
basata su tecniche/tattiche ad hoc per prestazioni, scalabilità, disponibilità, sicurezza, ...
“oggi i mainframe sono presenti e hanno un ruolo insostituibile in tutto il mondo nelle infrastrutture informatiche delle più importanti aziende industriali e finanziarie, nelle società di servizi pubbliche e private e nelle grandi istituzioni nazionali ed internazionali”
è una tecnologia adatta a sistemi molto grandi e complessi
è una tecnologia in competizione con altre tecnologie hardware moderne, come quelle dei sistemi multiprocessore e i cluster
Introduzione ai sistemi distribuiti11
Luca Cabibbo ASW
- Parentesi: virtualizzazione
Un’altra tecnologia importante oggi nel contesto dei sistemi software è quella della virtualizzazione
la virtualizzazione consente a un singolo server fisico di ospitare più macchine virtuali
questo “singolo server” potrebbe essere un server in un cluster o in un rack oppure anche un mainframe
in ogni caso, l’organizzazione dei server virtuali può essere basata sugli stili architetturali per sistemi distribuiti
anche se, fisicamente, viene adottata una soluzione centralizzata
infatti, un importante utilizzo dei mainframe è oggi ospitare soluzioni virtualizzate
Introduzione ai sistemi distribuiti12
Luca Cabibbo ASW
* Connettori
Nell’architettura di un sistema software è possibile distinguere due tipi principali di elementi software
componenti
elementi responsabili dell’implementazione di funzionalità e della gestione di dati/informazioni
connettori
elementi responsabili delle interazioni tra componenti –i connettori caratterizzano assemblaggio e integrazione di componenti
La distinzione tra componenti e connettori ha un ruolo fondamentale soprattutto nei sistemi distribuiti
poiché riflette l’indipendenza tra gli aspetti funzionali e quelli relativi alle interazioni
Introduzione ai sistemi distribuiti13
Luca Cabibbo ASW
Componenti e connettori – esempi
Alcune possibili tipologie di componenti
un modulo – ovvero, un pezzo di codice
un elemento software di natura statica
un processo – ovvero, un modulo in esecuzione
un elemento software di natura dinamica
una base di dati – caratterizzata dal suo schema
un elemento “dati”
Alcune possibili tipologie di connettori
una chiamata di procedura tra moduli
una chiamata di procedura remota, una pipe, oppure un protocollo che regola lo scambio di messaggi tra due processi
l’accesso a una base di dati da parte di un processo
Introduzione ai sistemi distribuiti14
Luca Cabibbo ASW
Componenti e connettori
I componenti [Shaw] sono il luogo della computazione e dello stato
ogni componente ha una specifica di interfaccia che definisce le sue proprietà – sia funzionalità che proprietà di qualità, ad esempio circa le prestazioni
ogni componente è di un qualche tipo
ad es., filtro, server, memoria, ...
l’interfaccia di un componente comprende la specifica dei “ruoli” che un componente può rivestire nell’interazione con altri componenti
ad es., l’essere il client oppure il server di un certo servizio
questi “ruoli” sono chiamati player [Shaw] oppure port [SAP]
Introduzione ai sistemi distribuiti15
Luca Cabibbo ASW
Componenti e connettori
I connettori [Shaw] sono il luogo delle relazioni tra componenti
i connettori sono mediatori di interazioni – sono “ganci” tra componenti
ogni connettore ha una specifica di protocollo che definisce le sue proprietà
queste proprietà comprendono regole sul tipo di interfacce che è in grado di mediare, nonché impegni sulle proprietà dell’interazione – come ad es. affidabilità, prestazioni e ordine temporale in cui avvengono le cose
ogni connettore è di un qualche tipo – ad es., chiamata di procedura remota, pipe, evento, broadcast, ...
il protocollo di un connettore comprende la specifica dei ruoli(role) che devono essere soddisfatti – ad es., client e server
la composizione dei componenti avviene mettendo in relazione player/port di componenti con ruoli di connettori
Introduzione ai sistemi distribuiti16
Luca Cabibbo ASW
Componenti e connettori
Introduzione ai sistemi distribuiti17
Component A
S
Component B
S
server
client
un componente
un player/port: un’interfaccia richiesta
un player/port: un’interfaccia fornita
un altro componente
un connettore
un ruolo
un altro ruolo
Luca Cabibbo ASW
Componenti e connettori
Alcuni esempi di semplici connettori
l’invocazione di un servizio
con i ruoli invokes-service e provides-service
una pipe – un flusso di dati asincrono, che preserva l’ordine dei dati
con i ruoli writer e reader
una coda per lo scambio di messaggi asincroni
un canale publish-subscribe
Introduzione ai sistemi distribuiti18
Luca Cabibbo ASW
Connettori
L’esperienza ha dimostrato che ci sono diverse motivazioni per trattare i connettori separatamente dai componenti [Shaw]
la distinzione tra componenti e connettori è un’applicazione del principio di separazione degli interessi
motivata dalla sostanziale indipendenza tra gli aspetti funzionali e quelli relativi alle interazioni (dimostrata dalla pratica)
la scelta e la progettazione dei connettori (ovvero, delle interazioni) è importante tanto quanto quella dei componenti
alcune scelte architetturali non hanno una collocazione naturale in nessuno dei componenti di un sistema
i connettori possono essere responsabili di qualità importanti di un sistema
ad es., è fondamentale nella realizzazione di sistemi basati sull’integrazione di componenti software pre-esistenti
Introduzione ai sistemi distribuiti19
Luca Cabibbo ASW
Connettori
L’esperienza ha dimostrato che ci sono diverse motivazioni per trattare i connettori separatamente dai componenti [Shaw]
la progettazione dei connettori può effettivamente essere fatta separatamente da quella dei componenti
i connettori sono tipicamente indipendenti dalle applicazioni – e dunque sono potenzialmente astratti e riutilizzabili in più contesti
spesso sistemi diversi sono basati sulle stesse modalità di interazione
questo non è invece vero per i componenti – che forniscono servizi specifici per un’applicazione
questo ha portato allo sviluppo di numerosi servizi di middleware – tecnologie software per l’implementazione di connettori, utili soprattutto nello sviluppo di sistemi distribuiti
Introduzione ai sistemi distribuiti20
Luca Cabibbo ASW
- Ulteriori caratteristiche dei connettori
[Taylor] propone una trattazione più approfondita dei connettori –descrivendone delle ulteriori caratteristiche e fornendone una classificazione
in generale, le caratteristiche fondamentali di un connettore sono le modalità di gestione del flusso di controllo e del flusso di dati tra due o più componenti
ad es., in una chiamata di procedura c’è un trasferimento dei parametri e un trasferimento del controllo dal chiamante al chiamato – e poi un trasferimento dei risultati e un trasferimento del controllo dal chiamato al chiamante
Introduzione ai sistemi distribuiti21
Luca Cabibbo ASW
Ruoli dei connettori
Ciascun connettore può rivestire uno o più dei seguenti ruoli
comunicazione – trasferimento di dati tra componenti
ad es., lo scambio di dati e risultati in una chiamata di procedura o il trasferimento di un messaggio
coordinamento – relativo al trasferimento del controllo tra componenti
ad es., il passaggio del controllo in una chiamata di procedura, o quello gestito da un load balancer
facilitazione – per mediare l’interazione tra componenti
ad es., meccanismi di load balancing, schedulazione o controllo della concorrenza
conversione (di formati e di interazioni) – per consentire l’interazione tra componenti eterogenei
Introduzione ai sistemi distribuiti22
Luca Cabibbo ASW
Tipologie di connettori
Queste sono le tipologie principali di connettori – attenzione, per ciascuna ci possono essere numerose varianti
chiamata di procedura
può essere locale o remota, sincrona o asincrona
eventi o messaggi – consentono la notifica di eventi o lo scambio di messaggi tra componenti, e ne abilitano la successiva elaborazione
può essere a-uno o a-molti, basata su polling (sincrono) o sottoscrizione (asincrona), con diversi livelli di affidabilità
Introduzione ai sistemi distribuiti23
Luca Cabibbo ASW
Tipologie di connettori
Queste sono ulteriori tipologie di connettori – anche per queste ci sono numerose varianti
connettori per l’accesso ai dati
ad es., per l’accesso a una base di dati
connettori per stream – per trasmettere grandi quantità di dati tra componenti
ad es., le pipe di Unix oppure i socket TCP/UDP
Introduzione ai sistemi distribuiti24
Luca Cabibbo ASW
Tipologie di connettori
Queste sono ulteriori tipologie di connettori – anche per queste ci sono numerose varianti
connettori di collegamento
il collegamento può essere effettuato a tempo di compilazione o linking (ad es., librerie) oppure a runtime (ad es., polimorfismo, plug-in o broker)
arbitri – facilitatori per risolvere possibili conflitti nell’interazione tra componenti
ad es., servizi di load balancing e schedulazione, oppure di gestione delle transazioni e controllo della concorrenza
adattatori – per consentire la comunicazione tra componenti che non sono stati progettati per interoperare direttamente
distributori – per effettuare il routing dei dati e del controllo
ad es., DNS
Introduzione ai sistemi distribuiti25
Luca Cabibbo ASW
* Middleware
In pratica, lo sviluppo dei sistemi distribuiti è sostenuto dal middleware
il middleware è un insieme di tecnologie e soluzioni software sviluppate per aiutare gli sviluppatori nella gestione della complessità e della eterogeneità presenti nei sistemi distribuiti
il middleware sostiene lo sviluppo dei connettori – sulla base di una molteplicità di paradigmi di interazione e astrazioni di programmazione per componenti distribuiti
il middleware è uno strato software “in mezzo”
tra componenti distribuiti
ma anche sotto ai componenti applicativi e sopra al sistema operativo e la piattaforma
Introduzione ai sistemi distribuiti26
Luca Cabibbo ASW
Middleware
Un servizio di middleware è [Bernstein]
un servizio distribuito, general-purpose e multi-piattaforma
che si colloca tra piattaforme e applicazioni
fornisce un’astrazione di programmazione distribuita – di solito implementa un insieme di protocolli e API standard
per aiutare a risolvere problemi di eterogeneità e distribuzione
Introduzione ai sistemi distribuiti27
Application Application
Platform- OS- Hardware
Platform- OS- Hardware
APIs
platform interface platform interface
Middleware(distributed system services)
Luca Cabibbo ASW
Middleware e connettori
Il middleware sostiene lo sviluppo dei sistemi distribuiti
l’utilizzo dei servizi di middleware facilita lo sviluppo dei connettori richiesti dalle applicazioni distribuite
altrimenti, i connettori sarebbero molto più complessi da sviluppare, da verificare e da mantenere
ogni tecnologia di middleware implementa uno o più paradigmi di interazione e comunicazione distribuita
ci sono diverse famiglie di middleware – ad es., RPC, oggetti distribuiti, comunicazione asincrona, componenti, servizi
inoltre, ogni servizio di middleware affronta e risolve alcuni problemi comuni nei sistemi distribuiti
può fornire trasparenza rispetto, ad es., a posizione, concorrenza, replicazione, fallimenti, esistenza, …
può mascherare qualche forma di eterogeneità nelle piattaforme (ad es., reti, HW, OS, linguaggi, …)
Introduzione ai sistemi distribuiti28
Luca Cabibbo ASW
Middleware – classificazione
Una possibile classificazione dei servizi e delle tecnologie di middleware [Gorton]
Introduzione ai sistemi distribuiti29
Transport
Application Servers
Business Process Orchestrators
Message Brokers
oggetti distribuiti, messaging
Java EE, .NET
BizTalk, WebSphereMessage Broker
BizTalk,Active BPEL
OS services socketsu TCP/UDP
Luca Cabibbo ASW
Tecnologie di middleware
Ci sono diverse famiglie di tecnologie di middleware – ad esempio
middleware per chiamate di procedure remote (RPC, remote procedure call)
le prime soluzioni di middleware realizzate
middleware per oggetti distributi (RMI, remote methodinvocation)
evoluzione di RPC – gli elementi distribuiti sono considerati oggetti – con identità, interfaccia, incapsulamento
middleware per la comunicazione asincrona (MOM, message-oriented middleware)
basato sullo scambio asincrono di messaggi ed eventi – e non su protocolli sincroni di richiesta/risposta
code di messaggi e publish-subscribe
possono offrire elevata flessibilità e affidabilità
Introduzione ai sistemi distribuiti30
Luca Cabibbo ASW
Tecnologie di middleware
Ci sono diverse famiglie di tecnologie di middleware – ad esempio
middleware per componenti distribuiti
evoluzione del middleware per oggetti distributi
consente sia la comunicazione sincrona che asincrona
i componenti vivono in contenitori (application server) in grado di gestire la configurazione e la distribuzione dei componenti, e fornire ad essi funzionalità di supporto
middleware orientato ai servizi
enfasi sull’interoperabilità tra componenti eterogenei, sulla base di protocolli standard aperti ed accettati universalmente
generalità dei meccanismi di comunicazione – sia sincroni che asincroni
flessibilità nell’organizzazione dei suoi elementi (servizi)
... in continua evoluzione ...
Introduzione ai sistemi distribuiti31
Luca Cabibbo ASW
Middleware
In pratica, il middleware è il software che sostiene il collegamento (chiamato anche plumbing/piping/wiring) tra componenti software – e rende facilmente programmabili i sistemi distribuiti
ciascun servizio di middleware offre una specifica modalità di interazione
ad es., RPC offre un paradigma di interazione basato sulla chiamata (sincrona) di procedure remote
la comunicazione asincrona offre, invece, un paradigma di programmazione basato sullo scambio (asincrono) di messaggi
sulla base di meccanismi di programmazione e API relativamente semplici
Introduzione ai sistemi distribuiti32
Luca Cabibbo ASW
Middleware e trasparenza
Inoltre, ogni servizio di middleware consente di solito di mascherare qualche tipo di eterogeneità comunemente presente nei sistemi distribuiti
il middleware maschera sempre l’eterogeneità delle reti e dell’hardware
alcuni servizi di middleware mascherano eterogeneità nel sistema operativo e/o nei linguaggi di programmazione
alcuni servizi di middleware mascherano eterogeneità nelle diverse implementazioni di uno stesso standard di middleware
ad es., alcune implementazione di Corba o Java EE
le astrazioni di programmazione offerte dal middlewarepossono fornire trasparenza rispetto ai seguenti aspetti
posizione, concorrenza, replicazione, fallimenti, mobilità
in alternativa, il programmatore dovrebbe farsi esplicitamente carico di queste eterogeneità e di questi aspetti
Introduzione ai sistemi distribuiti33
Luca Cabibbo ASW
Middleware e stili architetturali
Relazioni tra servizi di middleware e stili architetturali
l’applicazione di alcuni stili architetturali è sostenuta, dal punto di vista tecnologico, da opportuni servizi di middleware
ad es., lo stile C/S può essere basato su RPC o RMI, lo stile C/S a più livelli su middleware a componenti (applicationserver, AS), le SOA su middleware a servizi...
altri stili architetturali, invece, descrivono l’architettura (dell’infrastruttura) di alcuni servizi di middleware
ad es., RMI è basato su Broker, un AS su Container
È utile conoscere e comprendere queste relazioni
per capire quale servizio di middleware utilizzare per realizzare un certo stile architetturale – e per capire come utilizzare al meglio un certo servizio di middleware
per comprendere il funzionamento del middleware – e per realizzare (se serve) nuovi tipi di connettori
Introduzione ai sistemi distribuiti34
Luca Cabibbo ASW
Uso efficace del middleware
Se utilizzato in modo opportuno, il middleware consente di affrontare e risolvere diverse problematiche significative nello sviluppo dei sistemi distribuiti
semplifica molto l’implementazione dei connettori
in questo modo, consente di concentrarsi sullo sviluppo della logica applicativa – e non sui dettagli della comunicazione tra componenti e della piattaforma hardware/software utilizzata
Per aumentare effettivamente la produttività, il middleware scelto deve essere utilizzato in modo corretto
la decisione del middleware da utilizzare richiede delle considerazioni e delle decisioni esplicite
è dunque necessaria una buona comprensione del paradigma di comunicazione implementato dal middleware, nonché della sua struttura e dei suoi principi di funzionamento
Introduzione ai sistemi distribuiti35
Luca Cabibbo ASW
Uso efficace del middleware
Malgrado i molti benefici offerti dal middleware, il middleware non è una panacea per i sistemi distribuiti
il middleware non può risolvere “magicamente” i problemi derivanti da decisioni di progetto povere
che potrebbero avere conseguenze negative su stabilità, prestazioni e scalabilità
ad esempio, chi sviluppa applicazioni distribuite deve conoscere le differenza tra una chiamata di procedura remota e una chiamata locale
inoltre, le applicazioni distribuite devono essere preparate a gestire guasti nella rete e nei server
inoltre il middleware è focalizzato solo sulla comunicazione tra componenti
le responsabilità di natura applicativa sono completamente fuori dalla sua portata
Introduzione ai sistemi distribuiti36
Luca Cabibbo ASW
Sviluppo del middleware
Sviluppare middleware per la comunicazione nei sistemi distribuiti è un’attività estremamente complessa
fortunatamente, solo raramente c’è la necessità di progettare e implementare nuovi stili o paradigmi di interazione distribuita
infatti, sono disponibili un’ampia varietà di servizi di middleware, standard e commerciali, già usati con successo in moltissimi sistemi distribuiti
inoltre, i servizi di middleware sono in continua evoluzione
in genere, ogni servizio di middleware ha origine, a sua volta, dalla generalizzazione di altri connettori, di uso comune, realizzati con tecnologie precedenti
Introduzione ai sistemi distribuiti37
Luca Cabibbo ASW
* Stili di comunicazione e pattern [POSA]
Le tecnologie di middleware, malgrado le differenze nei dettagli, sostengono di solito pochi stili di comunicazione distribuita (“tipologie principali di connettori”) differenti – in particolare, due stili fondamentali di comunicazione tra componenti distribuiti sono
l’invocazione remota – consente ad un componente di invocare l’esecuzione di un’operazione di un componente remoto
la comunicazione asincrona – consente ad un componente di inviare un messaggio (contenente dei dati oppure la notifica di un evento) ad altri componenti, affinché questi possano elabora il messaggio
Ci sono anche altre tipologie di connettori e stili di comunicazione – ad es., le basi di dati condivise e lo streaming di dati
in questo corso ci concentriamo soprattutto su questi due stili di comunicazione, che sono di solito i più rilevanti nell’architettura di molti sistemi software
Introduzione ai sistemi distribuiti38
Luca Cabibbo ASW
Stili di comunicazione e pattern [POSA]
Questi due stili principali di comunicazione sono rappresentati da tre pattern architetturali [POSA] fondamentali
invocazione remota – Broker [POSA]
comunicazione asincrona – Messaging [POSA4] e Publisher-Subscriber [POSA4]
in pratica, ogni tecnologia di middleware supporta di solito uno o più stili di comunicazione ed implementa uno o più di questi tre pattern
Introduzione ai sistemi distribuiti39
Luca Cabibbo ASW
Stili di comunicazione e pattern [POSA]
Broker [POSA]
organizza il sistema distribuito in un insieme di componenti che interagiscono sulla base di invocazioni remote
il broker gestisce gli aspetti della comunicazione tra questi componenti distribuiti
Messaging [POSA]
organizza il sistema in componenti che interagiscono sulla base dello scambio di messaggi, in modo asincrono
i componenti si scambiano messaggi (che possono codificare dati, metadati, documenti, richieste, risposte) tramite un insieme di canali per messaggi
Publisher-Subscriber [POSA]
organizza il sistema in componenti che interagiscono sulla base dello scambio di notifiche di eventi, in modo asincrono
Introduzione ai sistemi distribuiti40
Luca Cabibbo ASW
Stili di comunicazione e pattern [POSA]
Introduzione ai sistemi distribuiti41
Domain Model
Domain Object
Layers
SharedRepository
Pipes and Filters
Reflection
Model-ViewController
Broker
Messaging
Publisher-Subscriber
internal partitioning
system evolution
user interface variation
functional variation
remote communication
distribution infrastructure
from mud to structure
Microkernel
data-driven processing
data stream processing
Luca Cabibbo ASW
* Discussione
Questa dispensa ha introdotto brevemente
i sistemi distribuiti, con i benefici ed i rischi associati (e la sfida posta dalla distribuzione)
i connettori, che sono gli elementi architetturali che consentono la comunicazione tra i componenti software nei sistemi distribuiti
il middleware, che semplifica lo sviluppo dei connettori nei sistemi distribuiti, sulla base di opportune astrazioni di programmazione distribuite, affrontando e risolvendo alcuni problemi comuni nei sistemi distribuiti
due stili principali di comunicazione distribuita, e i pattern [POSA] che li supportano
Questi argomenti verranno ripresi e discussi nel seguito del corso
inoltre, questa parte del corso presenterà anche alcuni stili fondamentali per sistemi distribuiti
Introduzione ai sistemi distribuiti42