Middleware per la
sincronizzazione di
ambienti eterogenei
Progetto di Reti di Calcolatori LS
Emanuele Crescentini
matr. 218973
Ingegneria Informatica LS
Problema

Necessità di sincronizzazione di un sistema
gestionale eterogeneo:
PHP, MySQL
?
?
Pocket Outlook
Office Outlook
Garantita da
Microsoft
Problema

Necessità di una sincronizzazione
“intelligente”:
Quando due dati discordano:
- mantengo il più recente?
- mantengo il meno recente?
- chiedo all’utente?
Obiettivo

Studiare (ed implementare) un middleware
che permetta la sincronizzazione tra elementi
di diverse architetture.

Supportare politiche che per una scelta
“intelligente” della sincronizzazione.
Analisi del problema

Eterogeneità
Standard?

Coordinamento tra entità
C/S o distribuito?

Politiche di sincronizzazione
Scelte Progettuali

Eterogeneità  XML

Coordinamento tra entità  C/S con carico
minimo sul server

Politiche di sincronizzazione  file di policy
in XML
Implementazione
Local Software
GUI Importer Policy
WebServer-DB
Importer
Application Layer
Application Layer
Network Layer
Network Layer
Protocollo di sincronizzazione
Comunicazione in due
operazioni distinte per
ottimizzare la
connessione
Diagramma delle classi
Policy
<?xml version="1.0"
encoding="ISO-8859-1"?>
<!-- Local: creato in locale.
Remote: creato in rem.-->
<policy>
<new>
<!-- possibilità: keep/skip/ask
-->
<local>
keep
</local>
<remote>
skip
</remote>
</new>
<different>
<!-- possibilità:
keeplocal/keepremote/ask-->
<localnewer>
keeplocal
</localnewer>
<remotenewer>
keeplocal
</remotenewer>
<samedate>
keepremote
</samedate>
</different>
</policy>
Estensione: Server replicati
Vogliamo ora replicare il server per incrementare la
QoS del servizio. Dobbiamo garantire le seguenti
condizioni:
 Servizio attivo 24/7;
 Fault-tolerance;
 Trasparente al client.
Cluster di server secondo il modello del bilanciamento
di carico.
Ogni copia può realizzare il protocollo di scambio con
il client, e il sistema provvede alla sincronizzazione e
al bilanciamento.
Cluster: struttura
Introduciamo un broker, a sua volta replicato (per
evitare “bottleneck”).
Cluster: struttura



Due broker identici che operano
indipendentemente (copie attive, ma senza
sincronizzazione finale)
Client conosce l’indirizzo dei due broker
(primario e secondario)
Il broker comunica al client l’indirizzo del
server con cui dovrà operare ( politica)
Cluster: protocollo
Ibrido tra modello a
copie attive e a
bilanciamento di
carico: lock e sync
fittizi per i server che
non dovranno operare,
ma solo aggiornare la
LockList.
 Ipotesi ottimistica che
il trasferimento non
fallisca mai (altrimenti
ci pensa il
LockManager).

Cluster: broker
Monitoring
Singleton “doppio”
Parametro per il load balancing
Cluster: protocollo di recovery
Il broker assegna ad
un server già attivo il
compito di effettuare
la recovery su di un
server tornato attivo.
Cluster
L’introduzione del cluster ha apportato le seguenti modifiche ai
componenti:
Client
Layer di rete:
- Supporto al doppio server (in questo caso broker)
- Riconnessione al server passato dal broker.
Server
Layer di rete:
- Comunicazione col broker
- Supporto al restoring
Layer applicativo:
- Supporto a lock e sync “fittizi”
- Supporto a invio e ricezione dell’intera lista dei Lock
Il servizio resta compatibile con la modalità C/S senza
intermediari.
Sviluppi futuri




Migliorare l’affidabilità abbandonando la politica
positivista (maggiore complessità nel protocollo di
coordinazione broker/server)
Replicazione broker secondo un modello
Master/Slave con monitoraggio
Coordinamento distribuito senza mediatore, o con
mediatore dinamico
Modifiche del layer di rete a supportare diverse
connessioni (es: bluetooth)
DEMO
config
bin
temp