Università degli studi di Bologna
Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
A. A. 2008/2009
Distributed Planning Service:
un sistema per la fruizione di
operazioni di pianificazione
Corso di Reti di Calcolatori LS
Prof. Antonio Corradi
Progetto di Davide Campellone
Matricola: 0000231967
Obiettivi
Sviluppare un’applicazione distribuita
Utilizzare un’infrastruttura di supporto alla
comunicazione di più componenti in rete
eterogenei
Valutare le problematiche di un sistema
distribuito
load-balancing delle risorse
fault-tollerance
Distributed Planning Service
Permette di usufruire dei servizi offerti da differenti sistemi di pianificazione
Libera implementazione delle diverse parti del sistema
Il pianificatore non deve essere implementato all’interno dell’applicazione che
ne ha bisogno, per cui non deve condividere con essa risorse di sistema
E’ possibile mettere a disposizione più tipologie di pianificatore
E’ possibile mantenere i risultati della computazione di ciascun pianificatore
le stesse computazioni non devono essere ripetute più volte
più applicazioni possono usufruire dei risultati delle pianificazioni richieste
da una certa applicazione
Distributed Planning Service
Gestisce le
informazioni sugli
utenti del sistema
Client
Authentication Unit
Planning Server
Gestisce i Planning Server e le
informazioni sulle attività di
pianificazione del sistema. Il
Client richiede l’apertura di
sessioni di pianificazione
Planning Unit
Planning Server
Planning Server
Authentication Unit
permette ai Client di gestire le informazioni sugli account, necessarie ad un
utente per usufruire dei servizi di Distributed Planning Service (registrazione di un
nuovo account, cancellazione o modifica di account esistenti)
permette alla Planning Unit di ricevere le informazioni sugli utenti che
richiedono le operazioni di pianificazione (informazioni di registrazione ed
informazioni sulle passate attività di pianificazione)
necessità di una struttura dati per mantenere le informazioni suddette
i servizi della Authentication Unit sono necessari allo svolgimento delle normali
attività del sistema
necessità di garantire il servizio anche a fronte di un guasto (fault
tollerance)
replicazione delle strutture dati (copie calde)
garantire la disponibilità del servizio anche a fronte di un numero relativamente
elevato di richieste
load-balancing delle risorse del sistema
Authentication Unit
modello di replicazione Master/Slave
nessuna
garanzia
di fault
tollerance
vengono
individuati
solamente
i guasti 
sul caduta
Master del servizio per guasti singoli
una sola unità risponde a tutte le richieste
necessità di messaggi per il mantenimento della coerenza tra le due strutture dati
Richieste da Client e Planning Unit
Richieste da Client e Planning Unit
Authentication
Master
Unit
Slave
Aggiornamento
struttura dati
Controllo attività
Authentication Unit
ciascun sottosistema svolge anche un ruolo attivo (load -balancing)
necessità di individuare un guasto su entrambi i sottosistemi
aumento dei messaggi non significativo
Richieste
Richieste
da Client
daieClient
Planning Unit
Richieste
Richieste
da Client
dalla ePlanning
PlanningUnit
Unit
UserServer
UserPlanningDbServer
Aggiornamento
struttura dati
Aggiornamento
struttura dati
Controllo attività
Controllo attività
UserServer e UserPlanningDbServer
UserServer:
•mantiene le informazioni sugli utenti, rendendole disponibili ai Client
• un Client può registrare un nuovo account, cancellarne o modificarne le informazioni
• le informazioni sul suo db vengono considerate più attendibili di quelle del db di
UserPlanningDbServer
UserPlanningDbServer:
• mantiene le informazioni sugli utenti, rendendole disponibili alla PlanningUnit
• la PlanningUnit verifica le credenziali degli Client che hanno richiesto l’apertura di una
sessione di pianificazione
Implementazione
Client
PlanningUnit
UserPlanningDbServer
UserServer
Planning Server
CORBA
Planning Server
Client
garantire la comunicazione tra le parti del sistema, senza vincoli realizzativi sulle
stesse
JacOrb 2.2.4, implementazione Open Source di CORBA
UserServer e UserPlanningDbServer realizzati in Java
Test su una rete di 3 computer
Implementazione
utilizzo del Name Service di CORBA
DII (Dynamic Invocation Interface)
Semantiche differenti per le richieste
invoke
send_oneway
Differenti politiche di attivazione dei Servant
explicit activation (interfacce per il mantenimento della coerenza delle
strutture dati, interfaccia per il controllo di UserPlanningDbServer)
on-demand activation, con l’utilizzo di Servant Locator (interfacce per le
operazioni richieste dai Client e dalla Planning Unit, interfaccia per il
controllo di UserServer)
Comportamento del sistema
Planning
Unit
Client
registerUse
r
UserServer
functionsPOA/FunctionsImpl
substitutingPOA/substitutingImpl
getUser
Problemi
Aggiornamento
UserPlanningDbServer
andato aUserServer
caduto.
nell’aggiornamento
buon fine.
ne sostituisce
del
db. UserServer
le
funzionalità
ritenta
la richiesta.
updateDbRegister
operazione fallita
aggiornamento
ok
UserPlanningDbServer
dbCoherencePOA/dbCoherenceImpl
Comportamento del sistema
UserServer
UserPlanningDbServer
checkUserPlanningDbServer
checkReplyPOA/CheckImpl
checkUserPlanningDbServer
substitutingPOA/substitutingImpl
dbCoherencePOA/dbCoherenceImpl
getWholeUserServerDb
Comportamento del sistema
UserServer
UserPlanningDbServer
checkUserPlanningDbServer
checkUserPlanningDbServer
checkReplyPOA/CheckImpl
checkDone
checkUserServer
substitutingPOA/substitutingImpl
getWholeUserPlanningDbServerDb
dbCoherencePOA/dbCoherenceImpl
Comportamento del sistema
UserServer
UserPlanningDbServer
non attivo.
UserServer prosegue
con il db locale non
aggiornato.
getWholeUserPlanningDbServerDb
dbCoherencePOA/dbCoherenceImpl
getWholeUserServerDb
UserServer non attivo.
UserPlanningDbServer
non prosegue
l’esecuzione.
UserPlanningDbServer
dbCoherencePOA/dbCoherenceImpl
Comportamento del sistema
UserServer
UserPlanningDbServer
rileva un problema di
coerenza sul suo db, a
seguito di una richiesta
di aggiornamento
updateDbRegister
UserPlanningDbServer
Problema di coerenza
dbCoherencePOA/dbCoherenceImpl
sul database
getWholeUserServerDb
dbCoherencePOA/dbCoherenceImpl
UserPlanningDbServer
db
di UserServer
Problema di coerenza
sulrichiede
databasel’intero
UserPlanningDbServer
richiede l’intero db di
UserServer
coherencyError
getWholeUserServerDb
dbCoherencePOA/dbCoherenceImpl
UserServer rileva un
errore di coerenza
sul database
Conclusioni
Sono state valutate alcune funzionalità dell’ambiente
CORBA, in particolare nella sua implementazione opensource Jacorb 2.2.4
Sono stati raggiunti gli obiettivi prefissati
Il modello proposto è utilizzabile anche in altri sistemi
distribuiti
Sviluppi futuri
gestione della sicurezza nella comunicazione delle credenziali
degli utenti
realizzazione delle altre parti del sistema