Applicazioni Distribuite
Design di Applicazioni Distribuite
In COMET
Introduzione
Applicazioni Distribuite
Eseguono su nodi Geograficamente
Distribuiti connessi tramite
Reti locali
Reti geografiche
Introduzione
In COMET
Applicazione Distribuita strutturata in
Sottosistemi Distribuiti
Ogni Sottosistema corrisponde ad un nodo
logico
Sottosistema progettato come “componente
configurabile”
Ogni componente è definito come collezione
di Task concorrenti ognuno eseguito su un
nodo logico
Ogni componente ha un’ interfaccia ben definita
Interfaccia di comunicazione orientata ai
messaggi
Cosa vedremo…
Progettazione delle componenti di
Sottosistema in COMET
Interfacce di comunicazione distribuita
Gestione delle transazioni
Progettazione di sottosistemi server
Distribuzione dei dati
Passi da seguire nella fase di Design
Decomposizione del Sistema
Si struttura l’ Applicazione Distribuita in
Componenti
Possono eseguire su nodi separati in
ambiente distribuito
Decomposizione del Sottosistema
Si strutturano i Sottosistemi in
Task concorrenti
Oggetti che incapsulano l’ informazione
Decomposizione del Sistema
Per scomporre un’ Applicazione Distribuita in
Sottosistemi si utilizzano
Stessi criteri del caso Centralizzato
Criteri aggiuntivi necessari ad assicurare
Sottosistemi progettati come componenti
distribuite
Componenti mappabili su nodi distribuiti
Decomposizione del Sistema
Si fa distinzione tra
Aggregate Subsystems
Sottosistemi raggruppati per funzionalità
comuni
Composite Subsystems
Componenti che aderiscono al principio della
distribuzione geografica
Decomposizione del Sistema:
Aggregate Subsystems
In COMET un Aggregate Subsystem è un
raggruppamento logico di sottosistemi e/o
oggetti
E’ rappresentato con un Aggregate Object
Contiene altri oggetti
In UML può essere rappresentato con un
Package
un Package non può comparire in un
collaboration diagram
Decomposizione del Sistema:
Composite Subsystem
In COMET un Composite Subsystem è una
Componente che incapsula gli oggetti che
contiene
Non aggiunge funzionalità
è un contenitore logico e fisico
Tutte le funzionalità fornite dalla
componente derivano dagli oggetti che esso
contiene
Aspetti da considerare nella Progettazione
di Componenti Distribuite
In alcuni casi si hanno delle restrizioni nella
progettazione delle componenti
Servizi forniti da un Sottosistema associati
con una particolare locazione fisica
Servizi dipendenti da parametri di tipo
Hardware
Design delle Interfacce di
Comunicazione
Task in diversi Sottosistemi possono
comunicare usando diversi tipi di messaggi
Loosely Coupled Message Communication
Da l’ idea di una coda FIFO di messaggi o di
una coda rispetto alla priorità degli stessi
Comunicazione asincrona
In ambiente distribuito si può richiedere che il
produttore riceva una notifica positiva o negativa
che indica se il messaggio è arrivato oppure no
Un Timeout è associato ad ogni messaggio
Design delle Interfacce di
Comunicazione
Tightly Coupled Message Communication
Comunicazione sincrona
Un esempio è la comunicazione client/server
singola o multipla con attesa di risposta
Una risposta potrebbe essere una notifica
negativa quando il nodo server non ricevesse il
messaggio
Client e Server possono avere un dialogo che
coinvolge tanti messaggi e risposte
Si può aprire una connessione
Design delle Interfacce di Comunicazione:
Subscription/Notification Message Communication
E’ una forma di comunicazione uno a molti
Due tipi di comunicazione
Broadcast Comunication
un messaggio non atteso è spedito a tutti i
destinatari
Multicast Comunication
I Task sottoscrivono un gruppo e ricevono i
messaggi riferiti al gruppo
Il Sender manda un messaggio al gruppo senza
conoscere i membri
Un esempio di Subscription/Notification:
(message multicast) Comunication
Design delle Interfacce di Comunicazione:
Brokered Communication
Un object broker è un intermediario nelle
interazioni tra client e server
I server registrano con l’ object broker i servizi
che forniscono e le locazioni dei servizi stessi
questo tipo di mediazione è detto “Name
Service”
Il client non deve conoscere la locazione dei
servizi
Chiede al broker una lista dei servizi forniti
Design delle Interfacce di Comunicazione:
Brokered Communication
L’ object broker riceve la richiesta del client
determina la locazione del server (nodo su cui
risiede)
Inoltra il messaggio al server alla specifica
locazione
Il messaggio arriva al server e la richiesta viene
inoltrata
L’ object broker riceve la risposta dal server e la
inoltra al client
Due approcci
Forwarding design approach
Handle driven design approach
Due esempi di Brokered message
Comunication
Design delle Interfacce di Comunicazione:
Brokered Communication
Esiste una variante della Brokered
Communication detta Yellow Page Brokering
Il client conosce il tipo del servizio richiesto ma
non il server specifico
Il client manda una richiesta all’ object broker
richiedendo tutti i server per un dato servizio
L’ object broker risponde con una lista di server
che matchano con la richiesta del client
Il client specifica il server voluto
dopo aver comunicato con l’ utente
Il broker ritorna un “service handle” al client
che può comunicare direttamente con il server
Un esempio di Brokered
Communication (Yellow pages)
Design delle Interfacce di
Comunicazione: Negotiated
Communication
In Sistemi multi-agente è necessario permettere
agli agenti di negoziare con altri
Un agente client agisce in base all’ utente
fa una proposta “negoziabile” ad un agente
server
può richiedere una comunicazione con altri
agenti server
L’ agente server determina le opzioni disponibili
offre al client una o più opzioni (o rifiuta la
richiesta) che si avvicinano di più alla richiesta
del client
Design delle Interfacce di
Comunicazione: Negotiated
Communication
In particolare:
Il client può richiedere
una delle opzioni offerte dal server
proporre ulteriore opzioni
rifiutare l’ offerta
Il server a questo punto può
accettare la richiesta
se può soddisfarla
rifiutare la richiesta
Un esempio di Negotiated message
Communication
Transaction Management
Una Transazione consiste di due o più operazioni
che svolgono un’ unica funzione logica
Le operazioni possono essere completate
Tutte
Parzialmente
Le transazioni sono generate dal client e mandate
al server per il processing
Ci sono transazioni che devono essere atomiche
I servizi devono
Iniziare la transazione
fare il commit o abortire la transazione
Transaction Management: Un Esempio
Transazione di trasferimento tra due accounts in
due banche diverse
La transazione consiste di due operazioni
atomiche
di prelievo
di accredito
La transazione può essere
committed
entrambe le operazioni sono eseguite
aborted
nessuna operazione viene eseguita
Transaction Management: Protocollo di
Commit a due Fasi
Un server viene designato Commit Server
C’ è un partecipante server per ogni nodo
Nella prima fase del protocollo:
Il Commit Server manda un messaggio “prepareto-commit” a tutti i server
ogni partecipante
Blocca il record
effettua l’ update
Manda un messaggio “ready-to-commit” al
Commit Server
Un partecipante manda un messaggio “refuseto-commit” se non può fare l’ update
Transaction Management: Protocollo di
Commit a due Fasi
Il Commit Server aspetta di ricevere le risposte da
tutti i partecipanti
Ricevuti tutti i messaggi procede con la seconda
fase
Nella seconda Fase:
Il Commit Server manda il messaggio “commit” ai
partecipanti
Se tutti i partecipanti hanno risposto nella prima
fase “ready-to-commit”
Ogni server partecipante
Rende permanente l’ aggiornamento
Rilascia il record
manda un messaggio “commit-completed al
Commit Server
Il Commit Server aspetta i “commit-completed”
Schematizzazione della Prima fase del
protocollo di Commit s due fasi
Schematizzazione della Seconda fase del
protocollo di Commit a due fasi
Transaction Management: Note sul
Protocollo di Commit a due Fasi
Se un partecipante risponde ad un messaggio
“prepare-to-commit” con uno “ready-to-commit”
può completare la transazione
Un partecipante deve completare la
transazione anche se c’ è un ritardo
Se qualche partecipante risponde “refuse-tocommit” il Commit Server manda un messaggio
“abort” a tutti i partecipanti
Questi fanno il roll-back di tutti gli
aggiornamenti
Considerazioni sulla progettazione di
Transazioni
Una transazione composta potrebbe voler
effettuare solo roll-back parziale
In transazioni che coinvolgono l’ interazione con
l’ utente non è desiderabile tenere bloccata una
risorsa mentre l’ utente considera opzioni
E’ conveniente splittare le transazioni in più
sottotransazioni
Progettazione di Sottosistemi Server
Un Sottosistema Server fornisce un servizio per i
sottosistemi client
Incapsula oggetti (dati)
In questo modo un oggetto attivo (Thread fornito
dal sottosistema distribuito) accede l’ oggetto
passivo
Può incapsulare più oggetti passivi e fornire
servizi (thread) per ogni oggetto incapsulato
Il server risponde a richieste di lettura e/o
aggiornamento dei dati mantenuti dall’ oggetto
passivo
Sottosistema Server Sequenziale
Tratta le richieste dei client in modo sequenziale
Completa una richiesta prima di iniziare la
successiva
Tipicamente ha una coda di messaggi di
richieste di servizi
E’ progettato come un task
Fornisce uno o più servizi
Ha un tipo di messaggio per ogni servizio
Risponde a richieste inoltrate dai task client per
accedere il servizio
Sottositema Server Sequenziale
Il Server Coordinator
Interpreta il messaggio del client
Invoca l’ appropriata operazione fornita da un
oggetto server
Si usano i parametri del messaggio come
parametri dell’ operazione
Traduce la risposta dell’ oggetto server in un
messaggio di risposta al servizio
L’ oggetto Server
Processa la richiesta del client
Ritorna l’ appropriata risposta al Server
Coordinator
Esempio di
Sottositema Server Sequenziale
Sottositema Server Concorrente
Si Usa quando si ha un’ alta mole di richieste
Caratterizzato da diversi Task
Accedono in modo concorrente ai dati
C’ è bisogno di avere un accesso sincronizzato ai
dati
Per questo scopo si può utilizzare l’ algoritmo dei
lettori e scrittori multipli
I Task Lettori possono accedere il dato in modo
concorrente
Solo uno scrittore per volta può aggiornare il dato
in un certo momento
Dopo che i lettori hanno terminato
Sottositema Server Concorrente
Se il client comunica la richiesta in modo
asincrono si può usare un approccio a “callback”
Il client manda un puntatore ad un’ operazione
(funzione) al Server con la richiesta originale
Il Server usa questo Handle per effettuare una
chiamata di procedura remota
Dopo aver servito la richiesta
Esempio di
Sottositema Server Concorrente
Distribuzione dei Dati
Sia i server sequenziali che concorrenti sono
sottosistemi single-server
I dati che incapsulano sono centralizzati
Svantaggi potenziali dei Server centralizzati
possono diventare dei bottleneck per il sistema
sono soggetti a fallimento di tipo singolo
Se va giù un nodo non si può continuare
Esistono due approcci nella distribuzione dei dati
Distribuzione dei Dati
Basata su “Server Distribuiti”
I dati presenti in diverse locazioni sono
memorizza ti in quelle locazioni
Ogni locazione ha un server locale
Risponde alle richieste del client per i dati
relativi a quella locazione
Basata sulla “Replicazione dei Dati”
Gli stessi dati sono replicati in più di una
locazione
Devono esistere procedure per aggiornare in
modo coerente le copie locali dei dati replicati