V minulých týdnech se hodně příspěvků na blozích a na hlavních stránkách zpravodajských event. vývojářských serverů točilo kolem jediného tématu. Uvolněné Visual Studio 2008 a nový .NET Framework 3.5. Lehce proto mohlo dojít k přehlédnutí jiné zajímavé novinky a sice Sync Frameworku (CTP1).
reklama
V minulých týdnech se hodně příspěvků na blozích a na hlavních stránkách zpravodajských event. vývojářských serverů točilo kolem jediného tématu. Uvolněné Visual Studio 2008 a nový .NET Framework 3.5. Lehce proto mohlo dojít k přehlédnutí jiné zajímavé novinky a sice Sync Frameworku (CTP1) [1], [3].
Microsoft Sync Framework není nic převratného. Jde o – zkráceně řečeno – sadu objektů pro synchronizaci různých zdrojů. K dispozici jsou nyní služby pro:
- ADO.NET zdroje (verze 2.0) = Sync Services for ADO.NET
- soubory a adresáře = Sync Services for File Systems
- „jednoduché“ zdroje (RSS, Atom, …) = Sync Services for SSE (Simple Sharing Extensions)
nicméně není problém napsat si vlastní „provider“ a synchronizovat cokoli co nás napadne (podobně jako je možné vytvářet providery pro ADO.NET).
Pokud jste se někdy synchronizací např. souborů zabývali, pravděpodobně víte, že základním postupem, je ukládat si něco informace o verzích jednotlivých položek a ty poté porovnávat a provádět požadované akce. Mnoho vývojářů do svých aplikací tyto rutiny psalo. Každý, kdo to ale zkusil, zjistil, že se nejedná o nic extrémně tvůrčího a spíše se více píše kód na již vymyšlené fungování. Proto vznikl Microsoft Sync Framework – sada objektů, které nám mohou ušetřit práci.
Abychom pochopili, jak to celé funguje [2], popíšeme si několik základních pojmů. Jejich pochopení není nutné, ale může pomoci pro hledání informací či při detailním zkoumání fungování. Základním prvkem je tzv. účastník (participant). Účastník je identifikován providerem a „obrazem“ (replica). Replica je vlastně úložiště informací resp. jeho identifikace, které budeme synchronizovat. Může se jednat o složku na flash disku, webovou službu či klidně jeden soubor. Účastníky rozdělujeme do tří kategorií, neboť ne všechna zařízení nebo zdroje mají stejné schopnosti:
- Úplný účastník (full participant) je zařízení, které dokáže ukládat přímo k sobě data a dovoluje spouštět aplikace (na sobě). Klasická ukázka je počítač, PDA atp.
- Částečný účastník (partial participant) naproti tomu, je zařízení, které dokáže pouze data ukládat. Musí však umět ukládat i metadata potřebná k synchronizaci. Může se tedy jednat o flash disk, MP3 přehraváč atp.
- Jednoduchý účastník (simple participant) je nejjednodušší forma. Dokáže pouze data poskytovat. Nejde na něj data ukládat (z pohledu aplikace). Typickou ukázkou je RSS feed či jednoduchá webová služba.
Jak jistě každý dobře domyslí, aby mohla synchronizace fungovat, musí být v procesu zapojen alespoň jeden úplný účastník. Zbylé možnosti kombinace synchronizací jsou plně v rukou vývojáře.
Již naznačil, je třeba pro synchronizaci ukládat metadata. Tyto informace jsou základním kamenem celé synchronizace a mohou být uloženy kdekoli – v souboru, v databázi atp. Aby vývojář nemusel ukládání řešit, poskytuje Sync Framework v základu implementaci využívající SQL Server Compact Edition. Je ale možné napsat si vlastní. Metadata obsahují tři důležité komponenty:
- Verze (version). Informace uložená o každé synchronizované položce. Ukládána je tzv. „creation version“ a „update version“. Každý tento element se skládá ze dvou částí: „tick count“ (logické hodiny) a „replica ID“ (identifikace obrazu). „creation version“ se nikdy nemění.
- Znalost (knowledge) je relativně úsporná informace o změnách v synchronizovaných položkách. Hlavní význam je ušetřit množství informací, které si vyměňují účastníci při synchronizaci a tím i zlepšit efektivitu.
- Náhrobky (tombstone) slouží k udržování informací o položkách, které byly odstraněny. Udržovány jsou jakoby kopie informací o položkách. Není jistě složité nahlédnout, že tyto informace stále rostou a proto je žádoucí je čas od času pročistit (i pro toto má Sync Framework nástroje).
Pokud jste někdy psali takovouto synchronizaci, již pravděpodobně chápete, jak to celé funguje a jaké jsou i limity.
Podívejme se, jak taková synchronizace vypadá. Zdroj zahájí relaci a ptá se cíle, na „knowledge“. Jakmile ji dostane, zjistí, jaké položky bude třeba přenášet a tuto informaci (!) pošle zpět. Cíl zjistí, jaké položky bude třeba poslat a také určí konflikty. (Pokud konflikty vznikly, jsou zde vyřešeny či odloženy.) Následuje požadavek na zdroj, aby poslal dané položky, a cíl je poté zanese lokálně.
Vzhledem k tomu, že konflikty mohou vznikat, je třeba je řešit „ručně“ nebo (polo)automaticky. Základní principy jsou „source wins“ resp. destination wins“ jejichž názvy jsou více než výmluvné. Další možností je prostě konflikt odložit (derefer) a případně zalogovat. A nakonec – ve speciálních případech – je možné použít sloučení (merge). Tento způsob ale přirozeně nejde použít vždy.
Popsali jsme si základní stavební bloky Microsoft Sync Frameworku a příště se podíváme na praktické ukázky synchronizace.
[1]
http://msdn.microsoft.com/sync
[2]
http://msdn2.microsoft.com/en-us/sync/bb821992.aspx
[3]
http://www.microsoft.com/downloads/details.aspx?familyid=35e8f16e-aaa4-4919-8b3c-1ce4ea1f6552&displaylang=en