Middleware per la sincronizzazione di ambienti eterogenei Progetto di Reti di Calcolatori LS Emanuele Crescentini matr Ingegneria Informatica LS

Problema Necessità di sincronizzazione di un sistema gestionale eterogeneo: Office Outlook Pocket Outlook PHP, MySQL 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 Network Layer Application Layer GUI Importer Policy Importer Local Software WebServer-DB

Protocollo di sincronizzazione Comunicazione in due operazioni distinte per ottimizzare la connessione

Diagramma delle classi

Policy keep skip keeplocal keeplocal keepremote

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 Parametro per il load balancing Singleton “doppio”

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 configtempbin