SyncML
SyncML je synchronizační standard založený na technologii XML. Za vznikem standardu stojí sdružení SyncML Initiative. Verze 1.0 standardu vznikla v roce 2000, následovala verze 1.0.1 v roce 2001 a dále verze 1.1 roku 2002. Ve stejném roce bylo SyncML Initiative včleněno do společnosti Open Mobile Alliance (OMA). Po akvizici, již pod vedením OMA, vznikla verze 1.2. Členové Open Mobile Alliance jsou například Siemens, Nokia, Motorola, Vodafone, IBM, Microsoft a další.
Standard SyncML je nezávislý na jakémkoliv zařízení, operačním systému nebo použitém přenosovém protokolu. Jeho specifikace udává pouze formát přenášených dat. Protože byl standard SyncML navrhován především pro mobilní zařízení, jsou při přenosu dat používány algoritmy pro optimalizaci množství přenášených dat na minimum. Specifikace se skládá ze dvou částí: protokolu pro správu zařízení, který se zabývá vzdálenou správou, ovládáním a konfigurací zařízení, a protokolu pro synchronizaci dat, která je popsána dále.
Synchronizace
Při synchronizaci mezi sebou zařízení komunikují pomocí SyncML zpráv. SyncML zpráva je XML soubor s kořenovým elementem <SyncML>, v DTD je definován jako <!ELEMENT SyncML (SyncHdr, SyncBody)>. Jak je naznačeno výše, zpráva se musí skládat z hlavičky a těla. Hlavička obsahuje informace o průběhu a stavu komunikace. V hlavičce se definuje verze dokumentu (DTD), identifikátor session, identifikátor zprávy, identifikátor příjemce, identifikátor odesílatele, URI pro zaslání odpovědi, autorizace (jméno a heslo) a další meta-informace. Tělo zprávy může obsahovat jednotlivé příkazy a element <Final>, který identifikuje poslední zprávu balíku. Například příkazy Alert pro inicializaci, příkaz Get pro zaslání dat, příkaz Put zaslání dat, příkaz Sync slouží jako obálka pro synchronizační příkazy Add, Replace nebo Delete. Jedné synchronizaci nebo pokusu o ni odpovídá synchronizační session. V průběhu této session dojde k inicializaci nebo přesunu dat.
Směr přenosu synchronizace při výměně dat může probíhat obousměrně, ve směru klient-server nebo server-klient. Přenášeny mohou být všechny položky nebo pouze položky, u kterých byla zaznamenána změna, a v neposlední řadě přenos může být iniciován klientem nebo serverem. Kombinace všech těchto vlastností představují režimy synchronizace dat, které jsou v tabulce.
| Název | Směr | Obsah | Iniciátor |
|---|---|---|---|
| two-way sync | obousměrný | pouze změny | klient |
| slow two-way sync | obousměrný | vše | klient |
| one-way sync from client only | klient to server | pouze změny | klient |
| refresh sync from client only | klient to server | vše | klient |
| one-way sync from server only | server to klient | pouze změny | klient |
| refresh sync from server only | server to klient | vše | klient |
| server alerted sync | kterýkoliv | obě možnosti | server |
Pro synchronizaci se používají tzv. kotvy, které jsou reprezentovány jako datum a čas nebo sekvenční číslo. Rozlišujeme poslední kotvu (Last Anchor), která představuje poslední proces úspěšné synchronizace a následující kotvu (Next Anchor), znázorňující nově započatou synchronizaci.
V průběhu inicializace synchronizační session si klient a server navzájem pošlou svoje poslední kotvy a navržené následující kotvy. Server porovná přijatou poslední kotvu klienta s poslední kotvou klienta, kterou má u sebe uloženou. Pokud mezi nimi dojde ke shodě, je možné započít synchronizaci. V případě že ne, nastala chyba nebo se jedná o první synchronizaci a je potřeba provést pomalou synchronizaci.
Synchronizace probíhá v několika fázích. Již při inicializaci synchronizační session klient zasílá příkazy, které se nachází v elementu Sync. Dále mohou nastat dva případy synchronizace. Pomalá, kdy se do elementu Sync vloží pro každou položku na straně klienta jeden příkaz Add, nebo se může jednat o rychlou synchronizaci, při které se posílají pouze položky, u kterých byly provedeny změny. Nově přidané položky generují zasílaný příkaz Add, změněné Replace a odstraněné Delete.
Po přijetí příkazů provede server analýzu, což představuje kontrolu duplicit a řešení konfliktů. Konflikt může nastat, pokud jsou nad jedním prvkem provedeny změny na straně serveru i na straně klienta a není jednoznačné, která aktualizace se má zachovat (propagovat na druhou stranu aktualizace). Konflikty se většinou řeší na straně serveru, i když protokol nezakazuje ani řešení na straně klienta. Po skončení analýzy server odpovídá zprávou o provedených změnách s příkazy Add, Replace a Delete.
Pro každý přijatý příkaz Add od serveru vygeneruje klient položku MapItem. Souhrn vytvořených položek zašle klient jako následující zprávu serveru, a ten odešle potvrzení pro ukončení synchronizace.
Literatura
- KUČERA, Ondřej. Implementace time-management aplikace pro OS Android. Zlín: Univerzita Tomáše Bati ve Zlíně, 2011. S. 72. bakalářská práce