introduzione ai sistemi distribuiti - luca...

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.


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


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]


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


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)


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)


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


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


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


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


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


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


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


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]


Luca Cabibbo ASW


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


Luca Cabibbo ASW



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


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


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


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


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


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


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à


Luca Cabibbo ASW


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


Luca Cabibbo ASW


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


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


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


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, …)


Luca Cabibbo ASW

Middleware – classificazione

Una possibile classificazione dei servizi e delle tecnologie di middleware [Gorton]


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à


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 ...


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


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


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


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


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


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


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


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


Luca Cabibbo ASW


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


Luca Cabibbo ASW



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 distribuiti - luca...

Documents