Mint azt már korábban említettem, a Sync Framework nem csak managelt kódból használható. A Microsoft a framework fejlesztése során szem előtt tartotta azt is, hogy ez egy olyan technológia, amit natív alkalmazásokat fejlesztő cégek számára is elérhetővé kell tenni. Sőt mi több, van rengeteg MS szoftver a listán, mint például a Windows Live programok, illetve Office programok, melyek szintén natív kódalapra épülnek és szükségük lehet hasonló technológiák alkalmazására. Éppen ezért a Sync Framework azon komponensei, melyek natív fejlesztők számára is értékesek, mint pl. provider framework, COM osztályokban vannak megvalósítva és managelt wrapper osztályok COM interopon keresztül kommunikálnak ezekkel. Persze léteznek a Sync Frameworknek olyan részei is, melyek csak managelt környezetben léteznek, mint pl. az ADO.NET adatforrások szinkronizálását megvalósító DbServerSyncProvider. Íme a fájl szinkronizációra egy natív Visual C++ példa. További rossz hír Delphi Win32, de még C++Builder fejlesztők számára is, hogy egyenlőre a .NET-es COM interop a legkézenfekvőbb megoldás a teljesen natív VC++-os COM könyvtárak helyett, mivel a típuskönyvtár importálás ezeknél a könyvtáraknál nem működik, a szükséges header fájlok átfordítása pedig még nem történt meg ezekre a nyelvekre.

Tehát ott tartunk, hogy provider modell hierarchia. Na vajon, hogyan is nézhet ki ez a provider model? Rettenetesen nagy PowerPoint szakértelmemet megkamatoztatva megpróbáltam vizuálisan is formába önteni ezt, tekintettel a három fő providerre, amit a Microsoft a jelenlegi CTP-ben kulcsra készen kínál:

 

Mégegyszer hangsúlyozom: managelt kód esetén ezek javarésze mind COM interopon keresztül kommunikál. Szó nincs arról, hogy az egész frameworkot megírták volna managelt kódban is. Ehelyett managelt osztályokba csomagolták a natív COM osztályokat és felületeket. Természetesen az eredmény így is milliószor egyszerűbb és áttekinthetőbb, mint a natív használat esetén (elég ha csak ránézünk a fentebb belinkelt C++ forráskódra).

Providerek szerepei

• SyncProvider
  Ez a közös őse az összes providernek. Ez az amivel nekünk soha nem kell foglalkoznuk. Bármilyen szinkronizációval kapcsolatos feladat megoldásán dolgozunk, eddig a szintig nem kell visszamennünk, hanem sokkal inkább ezen osztály közvetlen leszármazottaig.
  
  
• KnowledgeSyncProvider  : SyncProvider
  Ez az osztály reprezentál egy olyan providert, ami használ knowledge információkat a szinkronizáció megvalósításához. Amikor ezt az osztályt használjuk, a Sync Framework mindig ezen osztály BeginSession metódusát hívja meg először, ami csatlakoztat egy új, a paraméterben megadott SyncSessionContext típusként meghatározott session-t a SyncProviderPosition típusként meghatározott értéknek megfelelő módon (local, remote, unknown). Ugyan így van egy EndSession metódus, ami lezárja a paraméterben megadott session kontextust. Minden más ezen két metódus között kerül meghívásra:
  
  public abstract void BeginSession(
     SyncProviderPosition position, SyncSessionContext syncSessionContext)
  public abstract void EndSession(
     SyncSessionContext syncSessionContext)
  
  
• ClientSyncProvider : SyncProvider
  Ez az osztály reprezentálja egy kliens adatforrással kommunikálni képes provider absztrakcióját.
  
  
• ServerSyncProvider : SyncProvider
  Ez az osztály reprezentálja egy szerver adatforrással kommunikálni képes provider absztrakcióját.
  
  
• ServerSyncProviderProxy : ServerSyncProvider
  A ServerSyncProviderProxy osztály használt N-rétegű forgatókönyvek esetén. A proxy osztály használt a kliensen, a szerver szinkronizációs provider pedig a szerveren, vagy egy közbenső rétegen. A proxy kommunikál egy szolgáltatással a szerveren, vagy egy közbenső rétegen, és a szervíz felváltva kommunikál a szerver szinkronizációs providerrel. További részletek itt: How to: Configure N-Tier Synchronization
  
  
• SimpleSyncProvider : SyncProvider
  A v2.0-ban jelent meg, mint új szinkronizációs provider bázis osztály saját, inkább általános célú egyéni providerek implementációjának megkönnyítésére. A SimpleSyncProvider a fejlesztők kezébe adja az erejét és flexibilitását a mag API-knak viszonlag kevés tanulási görbével és kevesebb kód írással, különösen abban az esetben, ahol a replikák kevés, vagy egyáltalán nem rendelkeznek változás-követési támogatással.
  
  
• FullEnumerationSimpleSyncProvider : SimpleSyncProvider
  A SimpleSyncProvider egy megvalósítása. A lényege, mint a neve is mutatja, hogy felsoroljuk az összes tételt az adatforrásban és a változások detektálását rábízzuk a Simple Provider Framework-re.
  
  
• AnchorEnumerationSimpleSyncProvider : SimpleSyncProvider
  Mindössze annyiban különbözik a fentebbi FullEnumerationSimpleSyncProvider-től, hogy ahelyett, hogy felsorolnánk minden tételt az adatforrásban, inkább mi magunk követjük a változásokat az adatforrásban és csak ezeket a változásokat szolgáltatjuk azok detektálása közben. Pl. ha használunk egy timestamp értéket, ami tárolja az utolsó módosítás idejét, és mi csak azokat soroljuk fel és szinkronizáljuk amik a megadott timestamp óta elteltek.
  
  
• UnmanagedSyncProviderWrapper : KnowledgeSyncProvider
  Ez az osztály reprezentál egy managelt wrapper osztályt egy nem managelt szinkronizációs provider körül. Ilyen pl. a FileSyncProvider, mely ezáltal tisztán natív kódból is elérhető .NET nélkül is.
  
  
• FileSyncProvider : UnmanagedSyncProviderWrapper
  Ez egy komplett szinkron módon működni képes szikronizációs provider fájlok, mappák, illetve almappák szinkronizálásához NTFS, FAT, vagy SMB fájlrendszereken. Ez a provider, mint látszik is, direktbe natív kódból is elérhető (FileSyncProvider.dll). A FileSyncProvider használata során alapértelmezésben a szinkronizációs metaadatok egy ún. Metadata Storage Service adatbázis fájlban tárolódnak közvetlenül a replika gyökérkönyvtárában. Természetesen ez is módosítható. Azt, hogy mely fájlok vagy fájltípusok (pl. csak .mpg, .avi), illetve mappák kerüljenek szinkronizálásra egy FileSyncScopeFilter objektum segítségével szabályozhatjuk, vagy ha jobban tetszik, szűrhetjük. Sőt mi több, egy FileSyncOptions típusú tulajdonság segítségével akár azt is szabályozhatjuk, hogy a törölt fájlok kerüljenek bele a lomtárba, vagy maradandóan törlődjenek.
  
  
• DbSyncProvider : KnowledgeSyncProvider
  Ez az osztály reprezentálja egy egyenrangú adatbázissal kommunikálni képes szinkronizációs provider absztrakcióját. ADO.NET-hez van kitalálva, így csak managelt kódban létezik és nem CLS megfelelő ez az osztály. További részletek: How to: Configure Change Tracking and Synchronize Peers
  
  
• FeedSyncProvider : KnowledgeSyncProvider
  Ez az osztály reprezentálja egy RSS/ATOM feed alapú adatforrással kommunikálni képes szinkronizációs provider absztrakcióját. Technológiai alapja a Live Meshnek és a közeljövőben megjelenő ADO.NET Data Services (Project Codename “Astoria Offline”) és SQL Server Data Services + Sync technológiáknak. Az Astoria Offline előnyei például az automatikus létrehozása a compact tárolónak és .NET osztályoknak a szervíz metaadatok alapján, illetve a Sync szolgáltatja a varázst a kliensen és a szervíz végeken, és teszi mindezt egy nyílt, dokumentált formátum keretei között.

Szerintem ebből a rövid kis áttekintésből le is szűrhetjük azt a tanulságot, hogy egy végletekig kidolgozott általános szinkronizálást megvalósító platform szintű megoldásról van szó. Átvéve az egészet a gyakorlatba sem túl ördöngős a dolog, maximum amikor egyedi providereket, illetve saját megvalósítású metaadattárolást akarunk készíteni képes némileg megbonyolódni a dolog.

Behozok ide egy kis üzletpolitikát is, ha nem sértelek meg vele titeket:
Microsoft Sync Framework != Google Gears

Láttam, hogy már itthon is azzal próbálnak pedálozni egyesek, hogy a Microsoft monopóliumi helyzetét kihasználva megcsinálta a Silverlightot, hogy a Flash-t kiszorítsa a piacról, most pedig ugyanez a helyzet a Sync Frameworkkel. A probléma ezzel a dologgal csupán csak annyi, hogy megint teljesen felesleges összehasonlítgatni a kettőt, mivel ég és föld a különbség közöttük, de még céljukat tekintve is. Először is, a Google Gears nem más, mint egy sima böngésző plugin, míg a Sync Framework egy platform, ami lehetőséget ad bármilyen adatforrás bármilyen adatának bármilyen hálózaton keresztül történő szinkronizálására. Már ha ennyit mondok is elég lenne, de folytatom tovább. A Sync Framework egy általános célú eszköz nemcsak a lokális és cloud-ba történő adatszikronizáció megvalósításához, hanem az offline képes alkalmazások megvalósításához is, és nemcsak alkalmazások közötti adatszinkronizációra való, hanem szolgáltatások és eszközök között is képes működni. Továbbá alapból szolgáltat providereket ADO.NET, fájl/mappa szinkronizáció és RSS/ATOM feed alapú szinkronizáció megvalósításához, mely providerek bővíthetőek egyénileg is. Innentől kezdve szerintem értelmetlen is bármilyen hasonló jellegű vitába belefolyni.

Megmondom őszintén, első látásra (a tűz hevében), nem tudtam jobban kifejezni átütő erejét ennek a technológiának, mint két példa bemutatásával. De természetesen azt is illik szemügyre venni, hogy az egész mögött mi húzódik meg, így hát megróbálok most egy tömör és jól érthető osszefoglalót adni arról, hogyan is akar ez működni. Mellesleg megjegyzem, hogy a korábbi fájl szinkronizációs példám megoldására a Microsoft kiadott egy SyncToy 2.0 nevű alkalmazást, ami lehetőséget ad fájlok szinkronizálására mappák, illetve számítógépek között. Természetesen ez is a Sync Framework Team alkotása és szorosan kapcsolódik is ahhoz.

Tehát, mint mondottam korábban, a Sync Framework egy átfogó vagy inkább átütő erejű platform az összes szinkronizációval kapcsolatos probléma kiküszöbölésére, legyen szó bármilyen adatforrásról, bármilyen adattípusról, bármilyen hálózatról. Használva ezt a technológiát, képesek vagyunk olyan web képes offline alkalmazások készítésére, melyek hálózat nélkül is tökéletesen képesek üzemelni. Ennyi volt a reklám, most nézzük a koncepcionális megvalósítást:

Mint korábban is említettem, a kulcs aspektusa a Sync Frameworknek az, hogy képesek vagyunk saját szinkronizációs providerek írására => a Microsoft Sync Framework egy provider alapú modellre épül.

Mit nevezünk jelen esetben szinkronizációs providernek?

Egy szinkronizációs provider nem más, mint egy sima szoftver komponens, ami reprezentál egy replikát a szinkronizáció megvalósításához. Egy replika pedig nem más, mint egy részleges raktára az információknak, amik felhasználtak a szinkronizáció során. Először is a lokális (local) provider felsorolja (enumerálja) az összes változást az adatforrás replikájából. Ezt követően a távoli (remote) provider alkalmazza a változásokat a távoli adatforrás replikájára. Amennyiben olyan helyzet áll elő, hogy az adat a forrás és célnál különbözik típusban vagy sémában, minden provider teljesíti a szükséges feltérképezési és transzformációs műveleteket.

Provider modell

A Microsoft Sync Framework tartalmaz számos providert ami támogatja a közös adatforrásokat. Bár mi magunk is képesek vagyunk írni saját providereket ezekhez az adatforrásokhoz, a Microsoft mégis ajánlja, hogy ha lehetséges, használjuk az általuk készítetteket. Elvileg így rengeteg időt spórolatunk meg magunknak, más részről pedig újrahasználhatóvá válik a már létező kód. Mint korábban említettem, jelenleg három provider áll a fejlesztők rendelkezésére a CTP-ben:

• Sync Services for ADO.NET
  Szinkroniáció ADO.NET adat forrásokhoz.
  
  
• Sync Services for File Systems
  Szinkronizáció fájlokhoz és mappákhoz.
  
  
• Sync Services for FeedSync
  Szinkronizáció RSS és ATOM feed-ekhez. + Live Mesh

Ez a lista természetesen mint korábban mondottam, ízlés szerint bővíthető. A provider alapú megközelítés egyik lényeges előnye, hogy lehetőségünk nyílik különböző típusú providerek között is szinkronizálni, persze megkötések azért vannak ebben az esetben. A technológia megértésének érdekében első körben tisztáznunk kell néhány alapvező Sync Framework fogalmat:

Szinkronizációs résztvevők (Participants)

A Sync Framework megkülönböztet típus szerint különböző résztvevőket. Egy résztvevő nem más, mint kombinációja egy providernek és a hozzá társított replikának.

Résztvevők típusai (Participant types)

Három típusát különböztetjük meg a résztvevőknek: full, partial, simple. Ez a megkülönböztetés lényeges, mivel ez árulja el nekünk azt is például, hogy ők képesek lesznek-e tárolni állapot információkat, amik a szinkronizáció megvalósításához szükségesek, illetve hogy mi képesek vagyunk-e futtatni a providert direktbe az eszközről. Természetesen a fentről lefele elv érvényes, így egy full participant lehet partial és simple is.

• Full participants
  Beletartozik az összes olyan eszköz, ami engedi a fejlesztőknek, hogy létrehozzanak új alkalmazásokat és új adattárolókat direktbe az eszközön. Ilyen eszköz pl. a laptop, smartphone, mivel ezek mindegyike lehetővé teszi a fentebb említetteket.
  
  
• Partial Participants
  Beletarozik az összes olyan eszköz, ami engedi adatok tárolását, viszont nincs meg az önálló képessége arra, hogy futtassunk alkalmazásokat rajta. A legfontosabb ezzel kapcsolatban, hogy mivel tárolni képesek adatot, ezért a metaadatokat is képesek tárolni, amik szükségesek a szinkronizáció kivitelezéséhez => lehetőség van szinkronizálni bármilyen full participant résztvevővel. Ilyen eszköz pl. egy thumb drive. Ezek az eszközök tipikusan szolgáltatnak felületeket (intefaceket), amin keresztül el lehet érni őket, mint pl. egy fényképezőgép vagy egy walkman is.
  
  
• Simple Participants
  Az utolsó és egyben legkorlátozottabb résztvevő. Tipikusan csak adatot szolgáltatni képesek. Adattárolásra nincs lehetőség, se adatmanipulációra, illetve nincs lehetőség új alkalmazások létrehozására sem. Egy simple participant rábízza egy full participant-re, hogy tárolja ő a metaadatait, így a szinkronizáció is csak egyirányú. Jó példa erre az RSS feed és azon web szolgáltatások, melyek csak adatot szolgáltatnak, de újabb adatok felvételére/módosítására nem adnak lehetőséget.

Sync Framework mag komponensek

Adatforrás (Data Source)

Ez az, ami tárolja az adatokat, mely lehet egy relációs adatbázis, egy fájlrendszer, egy webszolgáltatás, vagy akár egy saját egyéni adatforrás is.

Meta adatok (Metadata)

A metaadatok tartalmaznak információkat az adattárolóról és az objektumokról, illetve a velük kapcsolatos állapot információkról. Az egész provider alapú megközelítésnek ez az alap építőköve. Természetesen nincs korlátozva, hogy a metaadatokat hol szeretnénk tárolni, így az lehet akár egy fájl, egy adatbázis, vagy a létező replika adattároló is. A Microsoft itt is előre gondolkodott és alapból ajánl nekünk egy teljes metaadat tároló implementációt, amit használva nem kell gondolkoznunk a metaadatok tárolási módjának megvalósításán.

A metaadat tároló három részre böntható szét:

1. Versions
   Ez egy kisebb mennyiségű információ, ami tárolt minden tételhez, ami a szinkronizálásban részt vesz. Magyarul verzió követés. Ez az információ rögzíti, hogy hol és mikor változott meg egy tétel. Adatbázisok esetében pl. egy tételnek minősül egy teljes rekord egy táblában, de lehetne akár egy tábla egy rekordjának egy oszlopa is. Amikor egy tétel megváltozik, tárolásra kerül a létrehozási- és frissítési verziószám (creation version, update version). Ezek a verzók két fő alkotóelemből tevődnek össze: tick count + replica ID. A tick count egy logikai idő érték, a replica ID pedig azonosítja azt az adattárolót, amelyben bekövetkezett a változás. A creation version és update version természetesen egy új tétel létrehozásakor megegyezik, a későbbi módosítások pedig már csak az update version-t fogják érinteni.
   
   Minden változás-követés be kell következzen legalább a tételek szintjén. Más szavakkal élve, minden tételnek rendelkeznie kell egy független verzióval. Sőt, van néhány forgatókönyv, ahol még ez is kevés az adatkonfliktusok elkerülése érdekében. Ilyen például amikor két felhasználó frissíti ugyanazt a tételt különböző replikákon. Az árnyoldala ennek a dolognak az, hogy ez növelni fogja a mennyiségét a tárolni kívánt változás-követési információknak is.
   
   Két fő irány létezik implementálni verziózást (egyáltalán nem új dolgokról van szó):
   
   (1) Inline tracking
   Arról szól, hogy a változás-követési információ azonnal frissítésre kerül a változást bekövetkezően. Ez azt jelenti egy adatbázis esetében, hogy pl. egy trigger egy rekord változását követően azonnal frissíti a változás-követő tábla információkat.
   
   (2) Asynchronous Tracking
   Amikor van egy külső folyamat ami fut és az folyamatosan scanneli a változásokat. Amikor talál valami frissítést, akkor hozzáadja a verzióinformációkhoz. Ezt a megoldást általában akkor használjuk, ha nincs mód belsőleg automatikusan frissíteni a verzió információkat amikor a tételek frissültek, magyarul nincs út injektálni logikát az update pipeline-ba. Ez esetben létezik egy közös forgatókönyv a változások ellenőrzéséhez, ami mindig működőképes, mégpedig, hogy tároljuk az állapotinformációit a tételeknek, majd összehasonlítjuk őket az aktuális állapotukkal. Ilyen pl. egy fájl utolsó írási idejének, vagy a fájl méretének változása az utolsó szinkronizálás óta.
   
   
2. Knowledge
   Tömör reprezentációja az adatváltozásoknak, melynek célja a hatékonyság-növelés azáltal, hogy csökkenti a replikák között szállítandó információ mennyiségét. Két fő irányelve a változások felsorolása és a konfliktusok detektálása.
   
   
3. Tombstones
   Minden replika kell fenntartson tombstone (sírkő) információkat minden tételről, ami törölt. Ha a törlés, mint művelet nem követett, akkor nincs mód megmondani, hogy egy tétel (pl. egy fájl) letörlődött. Ezzel csak az a probléma, hogy ilyenkor ennek híre nem jut el a többi providerhez sem, így mit sem fognak sejteni az egészről. Épp ezért, hogy ez ne így legyen, a tombstone-nak kell rendelkeznie a következő információkkal:
   
   (1) Global ID
   A Replica ID és tick count használt egyedien azonosítani a tombstone tételt az összes replikán keresztül.
   
   (2) Deletion version 
   Frissítési verzió, mely összekapcsolt a tombstone tétellel.
   
   (3) Creation version
   A Replica ID és a tick count kapcsolata azzal a verzióval, amikor a tétel eredetileg létrejött.
   
   Egy apró dolog van ezzel a tombstone megoldással, mégpedig az, hogy ez a log egy idő után eléggé megnőhet, így időigényessé is válhat ennek a használata, mellesleg nyilván a tárolási kapacitás mértéke is nőni fog. Pontosan ezért bölcs megoldás lehet létrehozni egy folyamatot, ami időközönként kitakarítja a szemetet a log-ból. A Sync Framework ad közvetlen támogatást a tombstone adatok manageléséhez is.

Szinkronizálási folyamat

 

Amit a fentebbi ábrán láthatunk egy szinkronizációt megvalósító folyamat leírása. Ugyanez a folyamat kétszer folyik végbe, ha a szinkronizáció kétirányú (bi-directional), egyszer a forráson, egyszer pedig a célon. Röviden arról, hogy mi micsoda:

Sync Session Initiated with Destination
Ez alatt a fázis alatt egy úgynevezett Sync Session megalapul, ami létrehoz egy linket a forrásból a providerbe.

Destination Prepares and Sends Knowledge
Mint korábban említettem, minden replika tárolja a saját knowledge információit, ezáltal csökkenthető a szállítani kívánt adatmennyiség. A knownledge tárolt a célban és továbbított a forrásnak.

Destination Knowledge used to Determine Changes to be sent
Megérkeztek a knowledge információk a forrásba. Következő lépésbe össze kell őket hasonlítani a lokális tétel verziókkal, hogy eldöntsük melyek azok a tételek, amelyekről még a másik fél nem tud.

Change Versions and Source Knowledge sent to Destination
A forrás elkészíti egyszer a listáját a változási verzióknak és ők transzportálódnak a célba.

Local Version Retrieved for Change Items and Compared against Source Version and Knowledge
A cél felhasználja ezeket verziókat, hogy elkészítse a listáját azoknak a tételeknek, amiket a forrásnak szükséges lesz majd elküldenie. Továbbá arra is használja ezeket az információkat, hogy detektálja a megszorításokból adodó konfliktusokat. A megszorítási konfliktusok azok a konfliktusok, amik áthágnak megszorításokat, amelyek a tételeken vannak elhelyezve/megfogalmazva, mint pl. relációi a mappáknak vagy a helye az azonos módon elnevezett adatoknak a fájl rendszerben.

Conflicts are Detected and Resolved or Deferred
Konfilktus akkor következhet be, amikor a változásokat ugyanazon a tételen két replika között szinkronizáljuk. A Sync Framework-ben egy konfliktus akkor detektált, amikor a változási verzió egy replikában nem tartalmazza a knowledge információit a másik replika változásának. A replikák szabadon választhatnak az ajánlott konfliktus-kezelési módszerek közül:

• Source wins
  Mindig a forrás győz, ha egy konfliktus lép fel a szikronizáció során.
  
  
• Destination wins
  Mindig a cél győz, ha egy konfliktus lép fel a szonkronizáció során.
  
  
• Merge
  Egyesíti a két változást együtt. Ahelyett, hogy választani kellene két érték közül, inkább példaképp összeadjuk őket. Jó példa lehet erre különböző pénzügyi elszámolások, leltározás, stb.
  
  
• Log conflict
  Naplózza vagy halogatja a konfliktus kezelését.

Destination Requests Item Data from Source
Ebben a fázisban a cél meghatározta azokat a tételeket, amelyekre szüksége van a forrásból és vissza kommikálja ezt a kérelmét a forrásba.

Source Prepares and Sends Item Data
A forrás megkapja a tétel adat kérelmet és előkészíti az aktuális adatok átvitelét a célba. Amennyiben ez egy rekord egy adatbázis egy táblájában, akkor az egész rekord, amennyiben egy fájl egy mappában, akkor a fájl lesz elküldve.

Items are applied at Destination
Utolsó lépésben a célba megérkezett adatok alkalmazásra kerülnek. Bármilyen hiba lép fel az alkalmazási folyamat során (pl. hálózati), a sikertelenül szinkronizált tételek megjelelölésre kerülnek mint kivételek, és a következő szinkronizáció során automatikusan javításra kerülnek. A forrásból fogadott knowledge információ hozzáadott a cél knowledge információhoz.

Összegezve minden szépet, elmondhatjuk, hogy a Microsoft Sync Framework megteremti mindazt az eco szisztémát, ami ahhoz szükséges, hogy offline képes alkalmazáokat készítsünk most és a közeljövőben. Használhatjuk a beépített providereket, vagy írhatunk saját providereket, és a legfőbb, hogy az egész Sync Frameworkot extrém mértékű beágyazhatóság és skálázhatóság jellemez. Továbbá nem elhanyagolandó tény az sem, hogy ezt Win32 fejlesztők is használhatják natív COM könyvtárakon keresztül.

A bemutató videók alapján ADO.NET DS felett például extra könnyedséggel használható lesz az egész. Ahogy elnéztem két metódus hívásában kimerül a fel/le szinkronizáció megvalósítása. De erre most nem tennék lovat, csak az egyik videóban láttam a múltkor.

Most egy érdekes témát hozok a színre, méghozzá nem is haszontalan dologról lesz szó. Mennyiszer volt már baj azzal, hogy nincs univerzális megoldás a különböző forrásból származó adatok szinkronizálásához? Elmondhatjuk, hogy állandóan. Én pl. másból se állok ki, mint saját szinkronizációs algoritmusok megalkotásából a heterogén adatforrásból és különböző helyekről származó adatokhoz. Nagy szó lesz amit most fogok mondani, de mindez a múlt! A Microsoft Sync Framework egy univerzális megoldást biztosít a korrekt szinkronizáció megvalósítására, legyen szó bármilyen típusú adatforrásról, bármilyen típusú adatról, és bármilyen típusú hálózatról. Elérkezett a web képes offline desktop alkalmazások ideje!

De még mielőtt tovább mennénk, sokan felteszik azt a kérdést, hogy minek ide Sync Framework, amikor ott a Live Mesh, melybe szintén lehetőségünk van nemcsak fájlok, hanem bármilyen .NET-es objektum szinkronizálására (lsd. Live SDK MeshObject). Nézzük akkor meg, hogy miért mégsem ugyanaz a kettő:

Először is a Microsoft Sync Framework egy átfogó szinkronizációs platform, mely független mind az adatforrástól, mind az adat típusától, mind a protokol és a felette lévő hálózattól. Egy provider alapú modellre épül, amely rugalmasan egyedi providerekkel bővíthető. Alapértelmezésben a Microsoft három fajta provider-t bíztosít a jelenlegi CTP-ben:

• Sync Services for ADO.NET
  Szinkronizáció megvalósítása ADO.NET adatforássokhoz.
  
• Sync Services for File Systems
  Szinkronizáció megvalósítása fájlok és mappák között NTFS/FAT/SMB fájlrendszereken.
  
• Sync Services for FeedSync
  Szinkronizáció megvalósítása RSS és ATOM feedeken keresztül. A Live Mesh is ez utóbbi megközelítést használja.

Tehát, míg a Live Mesh a FeedSync technológiát használja, hogy szinkronizálja adatainkat/fájlainkat a mesh és az eszközök között, addig a Sync Framework egy platform, ami lehetőséget ad arra, hogy bármilyen providert írva, bármilyen közegen keresztül szinkronizálhassunk úgy, hogy közben a szinkronizáció összes nyűgje/baja lekerül a vállunkról (mint pl. törölt objektumok figyelése, biztonság, stabilitás, offline képes működés, stb.). Ez utóbbi állítás természetesen él a Mesh esetében is.

De akkor mégis, mikor melyik lehet a jobb választás?

Ha pl. nincs valamilyen adattárolónk (mint pl. SQL Server) és direktben szeretnénk fájlokat/objektumokat elhelyezni a mesh-ben, akkor jó megoldás lehet a live mesh választása.

Ha pl. van egy adattárolónk, akkor lehetőségünk van akár egyéni providerek segítségével szinkronizálni az abban lévő adatokat/fájlokat más eszközök között, egyszerre akár többel is, sőt, akár a mesh-el is!

Mégis, ami mindkettőben közös, az a FeedSync. Mivel a FeedSync RSS / ATOM alapú szinkronizáció, semmi akadálya nincs, hogy működjön ADO.NET Data Services (Astoria) felett is. Ehhez a VS kap külön designtime támogatást is.

A további száraz, első mély vízbeugrás helyett inkább nézzünk meg két példát, amit így kutyafuttában összeütöttem, csak hogy megjöjjön a kedvünk a használatához. Először is szükségünk lesz a következőkre:

Microsoft Sync Framework v2.0 CTP1
Live Framework SDK April 2009 CTP
Live Framework Tools for Microsoft Visual Studio April 2009 CTP

Azt előre jelzem, hogy v2.0 CTP1 nem fér meg a korábbi verzióval, így azt előbb el kell távolítani. Továbbá interoperabilitás nulla még a CTP-ben a korábbi verzióval, így az arra épülő alkalmazások totál nem fognak működni. Az RTM-re igérik a lefele kompatibilitást.

Feladatok:

1. Csináljunk egy egyszerű fájl szinkronizációs alkalmazást, amely a Sync Frameworkot használva szinkronizál két mappa között. Ehhez első körben hozzunk létre egy új konzol alkalmazást, majd adjunk referenciát a következő assembykre:

C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\x86\Microsoft.Synchronization.dll

C:\Program Files (x86)\Microsoft SDKs\Microsoft Sync Framework\v1.0\Runtime\x86\Microsoft.Synchronization.Files.dll

Következő körben hozzunk létre két mappát, amin tesztelhetünk, mint pl.:

C:\Temp\Sync\Source
C:\Temp\Sync\Dest

Ha ezzel is megvagyunk, akkor a source mappába helyezzünk el egy fájlt, majd illesszük be a következő kódrészletet a projektünkbe és futtassuk:

using System;
using Microsoft.Synchronization;
using Microsoft.Synchronization.Files;

class Program
{
    const string srcFolder = @"C:\Temp\Sync\Source\";
    const string dstFolder = @"C:\Temp\Sync\Dest\";

    static Guid srcId = new Guid("{C380876C-9039-4c14-9AE6-3C2E95538B23}");
    static Guid dstId = new Guid("{07EDF4C5-2A21-47e9-A0D7-88523480C9AD}");

    static void Main(string[] args)
    {
        var filter = new FileSyncScopeFilter();

        // létrehozzuk a forrás és cél providereket
        var srcProvider = new FileSyncProvider(srcId, srcFolder, filter,
            FileSyncOptions.ExplicitDetectChanges);
        var dstProvider = new FileSyncProvider(dstId, dstFolder, filter,
            FileSyncOptions.ExplicitDetectChanges);

        // hozzáadjuk a követéshez szükséges eseménykezelőket
        srcProvider.AppliedChange += OnAppliedChange;
        dstProvider.AppliedChange += OnAppliedChange;

        // beállítjuk a szinkronizálás módját a forrás és a cél között
        var orchestrator = new SyncOrchestrator();
        orchestrator.LocalProvider = srcProvider;
        orchestrator.RemoteProvider = dstProvider;
        orchestrator.Direction = SyncDirectionOrder.UploadAndDownload;
        orchestrator.StateChanged += OnOrchestratorStateChanged;

        // teszteljük a szinkronizálást az exit beírásáig
        var input = string.Empty;
        while (input != "exit")
        {
            srcProvider.DetectChanges();
            dstProvider.DetectChanges();
            orchestrator.Synchronize();

            input = Console.ReadLine();
        }
    }

    /// <summary>
    /// A szinkronizációs állapotok követése
    /// </summary>
    static void OnOrchestratorStateChanged(object sender,
        SyncOrchestratorStateChangedEventArgs e)
    {
        Console.WriteLine("OnOrchestratorStateChanged: {0} => {1}",
            e.OldState, e.NewState);
    }

    /// <summary>
    /// A forrás/célon bekövetkezett változások követése
    /// </summary>
    static void OnAppliedChange(object sender, AppliedChangeEventArgs state)
    {
        switch (state.ChangeType)
        {
            case ChangeType.Create:
                Console.WriteLine("CREATE: {0}", state.NewFilePath);
                break;
            case ChangeType.Update:
                Console.WriteLine("UPDATE: {0}", state.NewFilePath);
                break;
            case ChangeType.Delete:
                Console.WriteLine("DELETE: {0}", state.OldFilePath);
                break;
            case ChangeType.Rename:
                Console.WriteLine("RENAME: {0}", state.NewFilePath);
                break;
        }
    }
}

Ha mindent jól csináltunk, akkor a source mappába helyezett fájl átszinkronizálódik a dest mappába automatikusan. Ezt követően nevezzük át ezt a fájlt a célmappában, majd szinkronizáljunk, és észrevehetjük, hogy a forrás mappában is át fog neveződni a fájl. Harmadik lépésként pedig töröljük le a célmappából ezt a fájlt, szinkronizáljunk, és észrevehetjük, hogy a forrás mappából is törlődni fog a fájl:

COOL! Mint látható, ez a kis pl. elég szemléletesen mutatja, hogy milyen egyszerű pl. a FileSyncProvider használata. A dolog igazán akkor kezd eldurvulni, amikor saját providereket írunk, de majd erre is nézünk egy-két példát.

2. Nézzünk akkor most egy mesh példát is. Példának okáért, bizonyítsuk, hogy a mesh nem csak fájlok szinkronizálására való, de még előtte nézzük meg, hogyan kérhetjük le pl. a kontakt információkat a live framework segítségével. Először is, úgyszint hozzunk létre egy konzol alkalmazást, majd adjuk hozzá a következő referenciákat a projekthez:

C:\Program Files (x86)\Microsoft SDKs\Live Framework\v0.91\API Toolkits\.Net Library\Microsoft.LiveFX.Client.dll

C:\Program Files (x86)\Microsoft SDKs\Live Framework\v0.91\API Toolkits\.Net Library\Microsoft.LiveFX.ResourceModel.dll

C:\Program Files (x86)\Microsoft SDKs\Live Framework\v0.91\API Toolkits\.Net Library\Microsoft.Web.dll

Ezt követően kérdezzük le a kontakt információkat a következő kis kódrészlet segítségével:

using System;
using System.Net;
using Microsoft.LiveFX.Client;

class Program
{
    static void Main(string[] args)
    {
        var loe = new LiveOperatingEnvironment();
        loe.Connect(new NetworkCredential("email@msn.com", "*****"), null);
        foreach (var contact in loe.Contacts.Entries)
            Console.WriteLine(contact);
    }
}

Ez jelen esetben nálam pl. a következő eredményt produkálta:

Tehát láthatjuk, hogy a Live SDK segítségével az összes kontakt információhoz, belértve a profil információkat is könnyedén hozzájuthatunk. Később mutathatok ettől extrémebb példákat is, de most nem volt se kedvem, se időm UI-al szórakozni. De térjünk vissza a mesh-re! Először is, szinkronizáljunk egy szimpla szöveget a mesh-be. Mivel említettem, hogy ez RSS/ATOM feed alapú (hivatalos nevén FeedSync), ezért egy kicsivel más megközelítést igényel:

using System;
using System.Net;
using System.Linq;
using Microsoft.LiveFX.Client;

class Program
{
    static void Main(string[] args)
    {
        // kapcsolódás a cloud-hoz
        var loe = new LiveOperatingEnvironment();
        loe.Connect(new NetworkCredential("email@msn.com", "*****",
            "https://user-ctp.windows.net"), new LiveItemAccessOptions(true));

        // ellenőrizzük, hogy sikerült-e a kapcsolódás
        if (!loe.IsRunning())
        {
            Console.WriteLine("Nem sikerült kapcsolódni.");
            return;
        }

        // létrehozunk egy új mesh objektumot
        var meshObject = new MeshObject("MyMeshObject");        
        var dataFeed = new DataFeed("MyDataFeed");        
        var dataEntry = new DataEntry("MyDataEntry");

        // beállítjuk a saját adatunkat
        dataEntry.Resource.SetUserData<string>("Egy sima karakterlánc.");

        // hozzáadjuk a mesh-hez
        loe.Mesh.MeshObjects.Add(ref meshObject);
        meshObject.DataFeeds.Add(ref dataFeed);
        dataFeed.DataEntries.Add(ref dataEntry);        

        // szinkronizálunk
        meshObject.Update();
                
        // megjelenítjük az eddigi összes saját mesh objektumot
        foreach (var mo in loe.Mesh.MeshObjects.Entries.Where(
            mobj => mobj.Resource.Title == "MyMeshObject"))
        {
            Console.WriteLine(mo);

            foreach (var df in mo.DataFeeds.Entries)
            {
                Console.WriteLine("\t{0}", df);

                foreach (var de in df.DataEntries.Entries)
                {
                    Console.WriteLine("\t\t{0}", de);
                    Console.WriteLine("\t\t\t{0}", de.Resource.GetUserData<string>());
                }
            }
        }
    }
}

A mesh-be szinkronizált tartalom:

Ugyanilyen könnyedséggel tudunk egyébként fájlokat szinkronizálni a mesh-be. A következőkben fogok mutatni erre is példát, de kedvcsinálónak szerintem mára ennyi is elég volt. Jó szórakozást hozzá!

Most sokan megfognak kövezni biztos, hogy behozom a politikát ide, de ezt nem tudtam kihagyni. A fidesz most beletrafált a közepébe: Új választás a megoldás (Navracsics Tibor). Őszintén, ha az én fejemhez ezeket a vádakat vágnák hozzá (most teljesen mindegy, hogy jobb, vagy bal, itt konkrét tényekről, méghozzá jól bizonyítható tényekről beszélünk), a bőr lesülne a képemről, nemhogy még ott üljek és egy egész ország sorsát én döntsem el. Remélem mindenki tisztában van vele, hogy június 7.-én európai parlamenti választás lesz és kire kell voksolni. Nem csodákat kell várni a fidesztől sem, csak egy jobb irányadást. A megszorító politika csak egyre mélyebbre fogja vinni az országot, a középréteg is elszegényedik, kialakul az a helyzet, amikor lesz egy nagony gazdag és egy nagyon szegény réteg. A fizetések értéküket vesztik, ez már most is tapasztalható közvetlenül cégen belül is, melynek természetesen vannak más jellegű következményei is, mint pl. az alkalmazottak egyre kevésbé látják el feladatukat (most élő példákról van szó konkrétan), az ügyfél egyre elégedtlenebb és persze mindenki több pénzt követel, hiszen mindez a többi ágazatra is kihat. Ahogy a fidesz mondja, válságot kezelni, megszorításokat bevezetni nem lehet gazdaság élénkítő csomag nélkül. Mi ez? Pl. adó csökkentés. Hiszen ha csökkentjük az adó-t, “kifehérítjük” a gazdaságot, és egyre több adozó lesz az országban, mert nem a csillagos eget veszik el az embertől adó címén, akkor sokkal több bevételre lehet szert tenni, mint a megszorításokkal, amik mint kiderültek, még csak töredékét sem képesek az egész költségvetési hiánynak fedezni => egyre több megszorítást kell majd bevezetni, a végén pedig már a csillagos ég sem lesz elég. De ezen kívül ezernyi érvet felsorolhatnék még a fidesz programja mellett, innentől már a döntés a kedves olvasón áll, de annyi biztos, az a bizonyos Bajnai csomag jobban fog fájni az átlag embereknek, mint azt most el tudnák képzelni (csak néhány dolog: 13. bér/nyugdíj kiiktatva, szociális támogatás /lakás hitel, stb./ kiiktatva, családi pótlék 2 évre befagyasztva, de még sorolhatnám tovább, mert ez csak a kezdet, ahogy tisztelt új miniszterelnökünk is fogalmazott). Jobban fog ez fájni, mint el tudnátok képzelni! Persze azzal is tisztában vagyok, hogy vannak emberek, akik tesznek az egészre, havonta zsebre vágnak pár százezret, sőt milliókat, de azért megkérném őket is, hogy képzeljék bele magukat egy szegény, sőt most már egy közép rétegű ember életébe is. Megmondom őszintén kerek-perec, hogy az a baj ezzel a világgal, hogy minden ember önző. A saját érdekét nézi, s mindaddig amíg maga át nem éli azt, amit a másik, nem képes mégcsak fel se fogni, mit jelent az. Itt most nemcsak az elszegényedésről beszélek, hanem bármiről ebben a világban, még akár az én fogyási problémám is. Mikor tudja/tudta valaha is elképzelni egy olyan ember, aki soha életében nem volt túlsúlyos, hogy milyen is az, milyen hátrányai vannak, stb… Soha! Értitek, soha! Ha a bőrödön tapasztalod, akkor igen.

Így a végére azért még belinkelnék néhány dolgot, csak hogy kielégítsem azokat is, akik úgy vélik/vélték, hogy a fidesznek nincs programja. Dehogy nincs! Csak hülyék lennének megmondani az ellenzéknek. Ez olyan lenne, mintha a google adna szakmai tanácsokat az ms-nek, hogy srácok, így kell webes keresőmotort fejleszteni. LOL Kész vicc ez a MSZP-SZDSZ koalíció! De nem is fecsérlem erre a szót tovább, a tények magukért beszélnek:

Mit kell tudni?

Az adócsökkentésről
A gazdasági válságról
A kisebbségi kormányzásról
A fogyasztói jogainkról
A magyar EU-elnökségről

Nagyon szépen kérek mindenkit, hogy menjen el szavazni, és végre olyan vezesse ezt az országot, aki ért is hozzá. Ez a kormány/koalíció már megmutatta mire képes, itt az ideje, hogy az ígéretek és a sok hazugság helyébe tényleg életképes megoldások lépjenek! De, hogy egy elfogultságok nélküli cikket is belinkeljek ide: “Gyurcsányt egy kamikaze váltotta fel”. Na most őszintén, ki van olyan elvetemült, aki ezt a koalíciót és programjukat támogatni akarja a jövőben is? Megmondom én, a kommunisták, akik abból a rendszerből itt maradtak (szerencsére fogyóban vannak). Ennél többet már nem is tudok hozzátenni:

Utat a jövőnek!

Így már minden tekintetben szebb a Silverlight. Demonstráció itt.

Már ilyen is van? :)

Na, ez az ami hiányzott már. Végre a designer is támogat mindent, beleértve a komplex típusokat is, illetve lehet a modellből adatbázist generálni.

Most már nagyon felidegesített, úgyhogy muszály leszek leírni. Előre mondom, nálam semmi toolbar, meg hókuszpókusz nincs feltelepítve a silverlighton és flashen kívül, és így is az IE “néha” bizonyos oldalaktól, különösen a live space-s oldalaktól csontra fagy. Na most semmi közös pont nincs a dologba, mert nemcsak az én, hanem mások oldalaitól is, amin se flash, se silverlight nincs. De a poén, hogy ezt nem mindig csinálja ezekkel az oldalakkal sem, csak amikor éppen rájön. Qva idegesítő.

Másik: Chikk örömére, megnéztem az Opera-t is. Az mindig is jobban tetszett a FireFox-ban és az Opera-ban is, hogy az oldal villogás mentesen képes frissülni. Az IE-ben ezen még mindig nem változtattak, pedig szerintem nem lenne olyan nagy dolog megcsinálni. Arról nem beszélve, hogy az Opera tényleg sokkal gyorsabbnak tűnik, mint a másik kettő. Egy szépséghibája van, nincs benne Silverlight Media Player. De esküszöm, ha ez így folytatódik én is átpártolok. Az IE8 rosszabb lett, mint a 7 volt user experience szempontjából (számomra). Az leglább nem fagyott, de lehet másnál az is csinált ilyet. Elsőre persze én is úgy voltam ezzel, hogy megesik, de az, hogy napi 20x lefagy egy tab benne, ja és ilyenkor csak a lelövés segít az egészen, totál kiábrándító. Ebben Mező Gabi barátomnak igaza van, sokkal jobb az Opera és gyorsabb is (most, hogy megnéztem).

Maga a Silverlight 2.0 is megy már, csak a Silverlight Media Player nem. Mellesleg megértem most már a tab problémát is. Az Opera tényleg atomgyorsan nyit egy új tab-ot. Arról nem beszélve, hogy sokkal kényelmesebb, még a görgetés is kifinomultabb benne, mint a többi böngészőben. Na meg élő miniatűr képek ha a tab felé megyek, stb. Ahogy Bandi mondaná, a szoftver ergonómia is sokat számít, és ez az Opera-ban sokkal jobban teljesül, mint a többi “hokkendáréban”.

Sajnos akár tetszik, akár nem, ez a véleményem az IE8-ról a tapasztaltak alapján. Ugyanezt az IE7-ről nem mondtam volna el (kivéve a villogást). Én kedveltem mindig is az IE-t, de ez így már nekem is sok. Ilyet azért a többi böngésző még sose csinált nekem, bármi is lett volna feltelepítve rá. B. megoldás lehet az lesz, hogy hozzáadok minden oldalt a kompatibilitási nézethez, hátha úgy nem fagynak ki a tabok amikor úgy tartja kedvük.

U.i.:

Nagy nehezen megszültük a megoldást Zsoltival, és hogy ki volt a ludas mindezért:

Hála az égnek a Cooliris-t megtarthatom.