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