Sistemi Mobili M - Università di Bologna
Transcript
Sistemi Mobili M - Università di Bologna
Sistemi Mobili M Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica II Ciclo - A.A. 2010/2011 Corso di Sistemi Mobili M (6 cfu) 08 – Cenni di Sincronizzazione Dati e SyncML Docente: Paolo Bellavista [email protected] http://lia.deis.unibo.it/Courses/sm1011-info/ http://lia.deis.unibo.it/Staff/PaoloBellavista/ Principi Mobile Middleware - Sistemi Mobili M 1 Motivazioni: Scenario del Commesso Viaggiatore Mobile Device Local DB replic a itinerario clienti da visitare te Mobile Device nize Local DB o r h c syn Central DB possibilità anche di temporanea disconnessione update Customer A Company Mobile Device Local DB Customer B Principi Mobile Middleware - Sistemi Mobili M Customer C 2 Due Macro-Tipologie di Sincronizzazione Possibili Sincronizzazione a livello di processo System A System B modifica Process Process Data item 1 modifica modifica Data Item 1 Data Item 1 Process A time Sincronizzazione a livello di dati Process B sincroniz. Process A detection modifica time sincroniz. Data item 1 sincroniz. Main? System Process B modifica Data Item 1 Data item 1 Principi Mobile Middleware - Sistemi Mobili M 3 Qualche Volta è Possibile Merging di Dati durante Sincronizzazione System A System B Ordine 50 unità Ordine 25 unità Stock Product A: 100 Stock Product A: 100 System A System B Ordine: 50 Ordine : 25 Stock Product A: 50 Stock Product A: 75 Applicare modifiche in fase di sincroniz. Operazioni disconnesse Main? System Main? System Stock: 100 Stock: 25 Inserire ordine, ridurre stock Inserire ordine, ridurre stock Nessun conflitto in questo caso; sempre vero? Principi Mobile Middleware - Sistemi Mobili M 4 Sincronizzazione: Modelli ed Elementi di Base Fino a che non sarà disponibile in modo seamless e a costo limitato una realizzazione efficace dell’ideale di cloud computing, importanza di operazioni disconnesse e di sincronizzazione in secondo step Joking a parte ☺, costo (economico, energetico, …) e lentezza connettività + connettività discontinua spingono verso operazioni disconnesse e gestione copie Gradi di libertà nella sincronizzazione: Quando lanciare operazioni di sincronizzazione Trigger manuale Trigger automatico Vedi anche problemi analoghi per replicazione nel distribuito Come sincronizzare (stili di sincronizzazione) Pessimistico – permettere unica copia modificabile; sincronizzazione come copia dell’unica istanza modificata Ottimistico – consentire che copie multiple possano essere modificate; tentare poi di riconciliare modifiche avvenute in secondo step Con quali costi? Principi Mobile Middleware - Sistemi Mobili M 5 Sincronizzazione: Modelli ed Elementi di Base Meccanismo di base spesso utilizzato: versioning Diverse soluzioni possibili; in generale problema aperto su come fare versioning per migliorare processo sincronizzazione in approccio ottimistico Usualmente semplici meccanismi versioning soddisfano proprietà: Se versione B deriva da modifica A, allora versione di B maggiore di A Se due copie sono state modificate concorrentem. in locazioni diverse, allora i numeri di versione non sono comparabili ⇒ Sequenza lineare di versioni ad ogni locazione singola; comunque possibilità di fare detection di modifiche concorrenti Due fasi (oltre a propagazione update): Detection di modifica (copie clean o dirty, anche approccio conservativo) Reconciliation (necessariamente bisogna considerare sintassi e semantica dei dati) Log di operazioni di modifica – riconciliazione come calcolo di log complessivo che comincia dall’ultima versione comune prima di modifica Comparazione di stato – opera direttamente su dati modificati Principi Mobile Middleware - Sistemi Mobili M 6 Architetture per Sincronizzazione In casi realistici, sempre sincronizzazione come processo solamente fra due nodi che detengono copie Architettura centralizzata con nodo con ruolo di master per ogni istanza di dato Architettura ad albero (sincronizzazione fra nodo e suo singolo parent) Architettura più generale come grafo ciclico connesso (maggiore flessibilità ma gestione più complessa: ad esempio, quali versioni precedenti considerare per comparazione di stato?) Raramente utilizzata in sistemi di sincronizzazione attuali Algoritmi di riconciliazione possono beneficiare di conoscere la natura (ad es. struttura) delle info condivise Capacità di riconciliazione crescenti passando da info opache, con struttura nota, con identificatore unico anche per parti, con semantica nota, con soluzioni application-specific Principi Mobile Middleware - Sistemi Mobili M 7 Un Paio di Esempi Notevoli File system (ad es. Coda per citare uno degli esempi più vecchi): Conoscete la differenza fra Networked File System (NFS) e Distributed File System (DFS), vero? Tipicamente DFS si occupano di consistenza nell’albero dei direttori, non a livello di singolo contenuto di file (delegato a plug-in synchronizer esterno); spesso richiesta di intervento esplicito dell’utente Analogia con mantenimento consistenza albero XML Conoscete gli strumenti antenati diff e patch in Unix? Oppure esempio di strumento più raffinato come rsync? Principi Mobile Middleware - Sistemi Mobili M 8 Un Paio di Esempi Notevoli Concurrent Versions System (CVS) per lavoro collaborativo su sviluppo software: Prime versioni banali con server centralizzato che rilasciava lock a un solo partecipante per volta; nessun bisogno di riconciliazione Ora generalmente approccio ottimistico e architettura centralizzata: algoritmo 3-way merge; detection di conflitti e richiesta intervento dell’utente Anche primi approcci non centralizzati, con utilizzo di change set (ciascuno dei quali atomico e con id unico): sincronizzazione come applicazione ordinata e completa di tutti change set Principi Mobile Middleware - Sistemi Mobili M 9 Middleware per Synchronization Sempre più rilevante in sistemi e servizi mobili, supporto a livello middleware per sincronizzazione applicazioni API di sincronizzazione a disposizione di sviluppatori Operazioni di update detection e di riconciliazione come operazioni tipicamente locali Invece azioni necessarie di propagazione update come operazioni che necessitano di definizione protocolli e connettività anche temporanea Spesso basate su sistemi di messaging o pub/sub Esempio di soluzione (parziale) di sincronizzazione oggi molto diffusa: SyncML Principi Mobile Middleware - Sistemi Mobili M 10 SyncML Open Mobile Alliance (OMA) ha adottato Synchronization Markup Language (SyncML) come linguaggio di sincronizzazione per aumentare interoperabilità e contrastare numero crescente di protocolli proprietari SyncML non è soluzione di sincronizzazione completa: solo protocollo di sinc (propagazione update), nessuna specifica su detection modifiche o riconciliazione Basato su approccio a log (operazioni tracciate di inserimento, cancellazione, ecc. di oggetti che sono unità atomiche SyncML) Architettura centralizzata; scambio di messaggi Sincronizzazione avviata da cliente Server riceve modifiche, le applica alla sua copia principale, determina conflitti, restituisce a cliente altro file SyncML con ulteriori modifiche da applicare Uso di diversi protocolli (HTTP, OBEX, …) per trasferimento messaggi SyncML Principi Mobile Middleware - Sistemi Mobili M 11 SyncML Sync server deve conoscere tipicam. semantica applicazione (esterno a specifica SyncML) per riconciliazione; uso di numeri di versione Tecnologia già utilizzata da numerose applicazioni OMA include Ericsson, Nokia, IBM, Motorola, … Principi Mobile Middleware - Sistemi Mobili M 12 SyncML in Maggiore Dettaglio Progettato per essere efficiente su reti wireless: encoding di dati e comandi ottimizzato (WAP Binary XML - WBXML) in formato binario Robusto a caduta di connessione durante scambio di messaggi Diverse soluzioni per trasferimento messaggi: HTTP, Bluetooth OBEX, IrDA, SMTP, WAP Wireless Session Protocol Supporto a dati qualsiasi, da vCard a email, dati relazionali, documenti HTML/XML, dati binari La specifica standard definisce: SyncML representation protocol per formato messaggi SyncML synchronization protocol per azioni di sincroniz fra due entità (cliente e servitore in gergo SyncML) Principi Mobile Middleware - Sistemi Mobili M 13 SyncML Synchronization Protocol cliente e servitore devono mantenere log di modifiche (formato non standardizzato); se perso log, slow sync negoziazione iniziale capability dispositivi (formato dati supportati, …) utilizzo di sync anchor (stringhe) per identificare eventi sinc. Lato cliente, anchor chiamata last rappresenta ultimo evento prima di sinc con server; next quello corrente. Confronto lato server per verificare che guasti non abbiano fatto perdere synch anchor; nel caso slow sync identificatori unici per dati da tenere sincronizzati. Utilizzo di Locally Unique ID (LUID) lato cliente e GUID lato server; tabella di mapping lato server modalità per notificare cliente che conflitto è stato risolto (codici di stato per descrivere conflitto e come è stato risolto). Ad es. <Status> <MsgRef> 1 </MsgRef> <CmdRef> 2 </CmdRef> <SourceRef> 2121 </SourceRef> <Data> 208 </Data> <!– conflitto risolto con data merge --> </Status> Principi Mobile Middleware - Sistemi Mobili M 14 Esempio Messaggio SyncML: Cliente Invia Modifiche <SyncML> <SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target><LocURI>http://www.syncml.org/sync-server</LocURI> </Target> <Source><LocURI>IMEI:493005100592800</LocURI></Source> </SyncHdr> <SyncBody> <Status> <MsgRef>1</MsgRef><CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>IMEI:493005100592800</TargetRef> <SourceRef> http://www.syncml.org/sync-server </SourceRef> <Data>212</Data> <!--Statuscode = OK, autenticazione con successo per sessione--> </Status> Principi Mobile Middleware - Sistemi Mobili M 15 Esempio Messaggio SyncML: Cliente Invia Modifiche <Status> <MsgRef>1</MsgRef><CmdRef>1</CmdRef> <Cmd>Alert</Cmd> <TargetRef>./dev-contacts</TargetRef> <SourceRef>./contacts/james_bond</SourceRef> <Data>200</Data> <!--Statuscode per successo--> <Item> <Data> <Anchor xmlns='syncml:metinf'><Next>200005022T093223Z </Next></Anchor> </Data> </Item> </Status> <Sync> <CmdID>1</CmdID> <Target><LocURI>./contacts/james_bond</LocURI></Target> <Source><LocURI>./dev-contacts</LocURI></Source> <Meta> <Mem xmlns='syncml:metinf'> <FreeMem>8100</FreeMem> <!-- Memoria libera in calendar sul cliente --> Principi Mobile Middleware - Sistemi Mobili M 16 Esempio Messaggio SyncML: Cliente Invia Modifiche <FreeId>81</FreeId> <!--Numero record liberi in Calendar--> </Mem> </Meta> <Replace> <CmdID>2</CmdID> <Meta><Type xmlns='syncml:metinf'>text/x-vcard</Type> </Meta> <Item> <Source><LocURI>1012</LocURI></Source> <Data> dati per vCard vanno indicati qui </Data> </Item> </Replace> </Sync> </SyncBody> </SyncML> Principi Mobile Middleware - Sistemi Mobili M 17 Ulteriori Info e Link Utili Esistono server, anche open source, che implementano SyncML, ad esempio Sync4j e sua implementazione come modulo di estensione per application server J2EE (vedi Funambol community – http://www.forge.funambol.org/ ) Ulteriori informazioni e link utili: SyncML http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlinde x.html JSR230 Data Sync API http://www.jcp.org/en/jsr/detail?id=230 Elenco di dispositivi che supportano SyncML http://www.weblicon.de/html/mobile_devices.html Principi Mobile Middleware - Sistemi Mobili M 18