012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Synchronizace dat webovych ´ aplikac´ı s mobiln´ımi zaˇr´ızen´ımi ´ D IPLOMOV A´ PR ACE

V´ıtˇezslav Homolka

Brno, podzim 2010

Prohlásˇ en´ı ˚ Prohlaˇsuji, zˇ e tato diplomová práce je mym ım autorskym ´ puvodn´ ´ d´ılem, které jsem vypracoval samostatnˇe. Vˇsechny zdroje, prameny a literaturu, které jsem pˇri vypracován´ı pouˇz´ıval nebo z nich cˇ erpal, v práci rˇ a´ dnˇe cituji ´ s uveden´ım upln´ eho odkazu na pˇr´ısluˇsny´ zdroj.

Vedouc´ı práce: Ing. Petr Adámek ii

Podˇekován´ı Dˇekuji vˇsem, a zejména své rodinˇe a Petru Adámkovi, za trpˇelivost.

iii

Shrnut´ı C´ılem této práce je prozkoumat problematiku synchronizace dat mobiln´ıch zaˇr´ızen´ı a analyzovat moˇznosti synchronizace tˇechto zaˇr´ızen´ı s webovymi ´ aplikacemi. Na základˇe z´ıskanych poznatku˚ je navrˇzen koncept aplikaˇc´ n´ıho rámce, ktery´ umoˇzn´ı implementaci synchronizace dat mobiln´ıch zaˇr´ızen´ı do webovych ´ aplikac´ı.

iv

Kl´ıcˇ ová slova mobiln´ı zaˇr´ızen´ı, OMA DS, SyncML, synchronizace, webové aplikace, Bluetooth, JABWT

v

Obsah 1 2

3

´ Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizace dat mobiln´ıch zaˇr´ızen´ı . . . . . . . . . . . . . 2.1 Problémy synchronizace dat mobiln´ıch zaˇr´ızen´ı . . . . 2.2 Pˇrehled synchronizaˇcn´ıch protokolu˚ . . . . . . . . . . . 2.2.1 IrMC . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 HotSync a Palm zaˇr´ızen´ı . . . . . . . . . . . . . . 2.2.3 ActiveSync, WMDC, Exchage ActiveSync . . . . 2.2.4 OMA DS (SyncML) . . . . . . . . . . . . . . . . . ˚ 2.3 Zpusoby pˇrenásˇ en´ı dat mobiln´ıch zaˇr´ızen´ı . . . . . . . 2.3.1 Sériovy´ port . . . . . . . . . . . . . . . . . . . . . 2.3.2 Infraˇcerveny´ port . . . . . . . . . . . . . . . . . . Popis nˇekterych ´ specifikac´ı . . . . . . . . . . . . 2.3.3 Mobiln´ı internet . . . . . . . . . . . . . . . . . . . 2.3.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . Architektura Bluetooth . . . . . . . . . . . . . . Popis nˇekterych ´ protokolu˚ [19] . . . . . . . . . . Bluetooth profily . . . . . . . . . . . . . . . . . . Ukázky standardn´ıch aplikaˇcn´ıch profilu˚ . . . . 2.3.5 USB rozhran´ı . . . . . . . . . . . . . . . . . . . . 2.3.6 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . ˇ arové kody ´ 2.3.7 C´ . . . . . . . . . . . . . . . . . . . . . OMA Data Synchronization . . . . . . . . . . . . . . . . . . 3.1 Základn´ı c´ıle návrhu OMA DS protokolu . . . . . . . . 3.1.1 Efektivita pˇrenosu dat . . . . . . . . . . . . . . . 3.1.2 Nezávislost na pˇrenosovém médiu a protokolu 3.1.3 Synchronizace libovolnych ´ dat . . . . . . . . . . 3.1.4 Nezávislost na programovac´ım jazyce . . . . . . 3.2 Hlavn´ı vlastnosti protokolu . . . . . . . . . . . . . . . . 3.2.1 Synchronizaˇcn´ı kotvy . . . . . . . . . . . . . . . 3.2.2 Mapován´ı na LUID a GUID . . . . . . . . . . . . ˇ sen´ı konfliktu˚ . . . . . . . . . . . . . . . . . . . 3.2.3 Reˇ 3.2.4 Logován´ı informac´ı . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 4 4 4 4 5 6 6 6 6 7 8 9 9 10 11 12 12 12 13 13 13 14 15 15 15 15 16 16 16 vi

3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.2.10 3.2.11 3.2.12 3.2.13 3.2.14 3.2.15 3.2.16 3.2.17 3.2.18 3.2.19

Obnova vˇsech dat . . . . . . . . . . . . . . . . . . . . . Mazán´ı dat . . . . . . . . . . . . . . . . . . . . . . . . Vymˇ ´ ena informac´ı o vlastnostech zaˇr´ızen´ı . . . . . . Adresa zdroje a c´ıle synchronizace . . . . . . . . . . . Správa pamˇeti zaˇr´ızen´ı . . . . . . . . . . . . . . . . . . Pˇrenos velkych ´ objemu˚ dat . . . . . . . . . . . . . . . Synchronizace hierarchickych ´ dat . . . . . . . . . . . Pˇreruˇsen´ı a obnova synchronizace . . . . . . . . . . . Signalizace pˇret´ızˇ en´ı serveru . . . . . . . . . . . . . . Typy synchronizac´ı . . . . . . . . . . . . . . . . . . . . Standardn´ı formáty dat . . . . . . . . . . . . . . . . . ˚ eh synchronizace . . . . . . . . . . . . . . . . . . Prubˇ Elementy zpráv synchronizace . . . . . . . . . . . . . WBXML a OMA DS . . . . . . . . . . . . . . . . . . . Protokol OMA DM . . . . . . . . . . . . . . . . . . . . Vyhody pro c´ılové skupiny uˇzivatelu˚ OMA DM . . . ´ 4 Integrace synchronizace dat do webovych ´ aplikac´ı . . . . . . . . 4.1 Neformáln´ı popis aplikace a poˇzadavky . . . . . . . . . . . . 4.1.1 Hlavn´ı funkˇcn´ı poˇzadavky . . . . . . . . . . . . . . . 4.1.2 Hlavn´ı nefunkˇcn´ı poˇzadavky . . . . . . . . . . . . . . 4.2 Analyza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 4.2.1 Data mobiln´ıch zaˇr´ızen´ı . . . . . . . . . . . . . . . . . 4.2.2 Volba protokolu . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Pˇrenos dat mezi mobiln´ım zaˇr´ızen´ım a webovou aplikac´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Podpora USB v Javˇe . . . . . . . . . . . . . . . . . . . 4.2.5 Podpora Bluetooth v Javˇe . . . . . . . . . . . . . . . . ´ 4.2.6 Spouˇstˇen´ı Java kodu pˇres webové rozhran´ı . . . . . . Java applety . . . . . . . . . . . . . . . . . . . . . . . Java Web Start . . . . . . . . . . . . . . . . . . . . . . 4.3 Návrh a implementace Bluetooth modulu . . . . . . . . . . . 4.3.1 Integrace Bluetooth modulu do webové stránky . . . 4.4 Návrh a implementace vzdáleného rozhran´ı . . . . . . . . . 4.5 Poznámky k implementaci . . . . . . . . . . . . . . . . . . . . 4.5.1 Pˇrevod binarn´ıho XML . . . . . . . . . . . . . . . . . . 4.5.2 Práce s datovymi proudy . . . . . . . . . . . . . . . . ´ 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 17 17 18 18 19 19 19 20 20 21 21 22 22 23 24 25 25 25 26 26 26 26 27 28 28 29 29 29 30 31 32 32 32 32 34 37

vii

Kapitola 1

´ Uvod ˇ Zijeme v dobˇe, kdy stále v´ıce spoléháme na chytrá“ zaˇr´ızen´ı, která nás ” ˚ ehu celého dne. Bˇehem podoprováz´ı pˇri kaˇzdodenn´ıch cˇ innostech v prubˇ sledn´ıch let je patrny´ vyrazn y´ pokrok v oblasti elektronické komunikace ´ ´ a správy dat. Mobiln´ı zaˇrızen´ı se rozv´ıj´ı neuvˇerˇ itelnou rychlost´ı podobnˇe ´ celovych jako jiné souvisej´ıc´ı oblasti. Z velkych ´ a jednouˇ ´ zaˇr´ızen´ı se stávaj´ı ˚ zeme nosit telekompaktn´ı, která integruj´ı stále v´ıce funkc´ı. V kapse tak muˇ fon s plnohodnotnym ym ´ operaˇcn´ım systémem, vykonn ´ ´ procesorem a dotykovym ´ displejem. Instalovat lze nepˇreberné mnoˇzstv´ı aplikac´ı, které rozsˇ iˇruj´ı moˇznosti, s jakymi daty lze i v malych ´ ´ zaˇr´ızen´ıch pracovat. Data, které dnes uchováváme v tˇechto mobiln´ıch zaˇr´ızen´ıch, existovala i v dobách pˇredelektronickych. Nen´ı tomu tak dávno, kdy byl hlavn´ım zdro´ ˚ ejˇs´ıch podobách. Vzpomenme ˇ jem dat pap´ır v nejruznˇ na seˇsit vedle tele˚ zitymi fonu se vˇsemi duleˇ cˇ ´ısly roztˇr´ıdˇenymi na stránkach podle abecedy, ´ ´ ´ na kapsy plné pap´ırku˚ s poznámkami nebo na tydenn´ ı kalendárˇ s ukoly. ´ ˚ At’ uˇz je to zpusobeno osobn´ımi zvyklostmi cˇ i nevˇedomost´ı, pro hodnˇe ˚ avá takové ukládán´ı dat stále nejefektivnˇejˇs´ı. Se zrychluj´ıc´ım se lid´ı zust´ ˚ zpusobem zˇ ivota vˇsak rostou poˇzadavky na vykonnost cˇ lovˇeka a s t´ım sou´ vis´ı i zmˇeny v nakládán´ı se z´ıskávanymi informacemi. ´ ´ Spravován´ı elektronickych ktery´ ´ dat pˇredstavuje relativnˇe sloˇzity´ ukol, nemus´ı byt ´ K zásadn´ım patˇr´ı rˇ eˇsen´ı problému˚ ´ na prvn´ı pohled zˇrejmy. bezpeˇcnosti a ztráty dat. Synchronizace dat pomáhá k tomu, aby uˇzivatel mohl lépe a jednoduˇseji vyuˇz´ıt potenciál mobiln´ıch zaˇr´ızen´ı a zárovenˇ doˇslo k omezen´ı nˇekterych ´ rizik spojenych ´ s jejich uˇz´ıván´ım. ˚ ych Synchronizace dovoluje udrˇzovat kopie dat na ruzn ´ m´ıstech. Tˇemi nejsou jen mobiln´ı zaˇr´ızen´ı a software poˇc´ıtaˇce, ale také online sluˇzby a informaˇcn´ı systémy. V souvislosti s rozvojem webu a webovych techno´ logi´ı se vyznamn´ a cˇ a´ st aplikac´ı pˇresunula právˇe do tohoto prostˇred´ı. To ´ zapˇr´ıcˇ inilo, zˇ e uˇzivatelé cˇ asto nedokázˇ ´ı rozliˇsit mezi nativn´ı a webovou aplikac´ı. Uˇzivatelé si na prostˇred´ı webu zvykli. Bylo by proto vyhodn´ e ´ nab´ıdnout jim moˇznosti synchronizace integrované právˇe do webovych ´ aplikac´ı. 1

Kapitola 2

Synchronizace dat mobiln´ıch zaˇr´ızen´ı Synchronizace je proces, ktery´ zajist´ı, zˇ e dvˇe sady dat budou vypadat identicky. K dosaˇzen´ı tohoto c´ıle mus´ı docházet ke zmˇenˇe dat na jedné stranˇe na základˇe zmˇeny dat na stranˇe druhé [3]. Synchronizace se provád´ı pomoc´ı synchronizaˇcn´ıho protokolu. Opaˇcnou filosofi´ı k tomu, jak nakládat ´ ziˇstˇe a pracuje se tak s daty, je cloud computing. Ten spoléhá na online uloˇ jen s jednou sadou dat. Tento smˇer zaˇz´ıvá v posledn´ıch letech silny´ rozvoj. Je vidˇet tˇreba na srovnán´ı vyraz u˚ cloud computing a synchronization v Go´ ogle Trends, ktery´ porovnává cˇ etnost jejich hledán´ı a dalˇs´ı statistiky1 . Stále ˚ má vˇsak vyznam zabyvat se synchronizac´ı dat. Mezi hlavn´ı duvody, proˇc ´ ´ se nevydat cestou cloud computingu, patˇr´ı tyto: •

nemoˇznost byt ´ poˇra´ d pˇripojeny´ k s´ıti;

•

pomalé pˇripojen´ı nebo pˇripojen´ı s vypadky; ´

•

cesty do zahraniˇc´ı;

•

neochota spoléhat se na neustálé pˇripojen´ı;

•

nativn´ı aplikace mobiln´ıho zaˇr´ızen´ı rychlejˇs´ı neˇz webové aplikace;

•

lokáln´ı aplikace se synchronizovanymi daty mohou byt ´ ´ efektivnˇejˇs´ı na práci neˇz s´ıt’ové aplikace.

2.1

Problémy synchronizace dat mobiln´ıch zaˇr´ızen´ı

Pˇri synchronizaci dat mobiln´ıch zaˇr´ızen´ı nastává spousta netriviáln´ıch ˇ ast se tyk´ ˚ které je potˇreba rˇ eˇsit. C´ problému, ´ a synchronizace dat obecnˇe a cˇ a´ st vzniká vlivem specifického prostˇred´ı mobiln´ıch zaˇr´ızen´ı. Pokus´ım se nast´ınit nˇekteré z nich. 1.

http://goo.gl/MQ18m

2

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ •

Pˇri souˇcasné editaci jednoho záznamu na dvou m´ıstech zárovenˇ ´ vzniká konflikt. Ukolem synchronizaˇcn´ıho serveru je v prvn´ı rˇ adˇe takovy´ konflikt detekovat. Pokud by se tak nestalo, mohly by se oba zmˇenˇené záznamy pˇrenést na druhou stranu jako aktualizace dat. To by vedlo k tomu, zˇ e by jeden záznam neobsahoval stejná data ˚ ych ve dvou ruzn ´ databáz´ıch. K tomu, aby bylo moˇzné detekce konfliktu˚ provádˇet, mus´ı kaˇzdy´ záznam obsahovat jednoznaˇcnou identifikaci.

•

´ esˇ né detekci konfliktu docház´ı k jeho rˇ eˇsen´ı. Server reaguje Po uspˇ ˚ podle zvolené strategie. Nejjednoduˇssˇ´ı zpusob, jak se s konfliktem vypoˇra´ dat, spoˇc´ıvá v duplikaci dat. Nedojde k zˇ a´ dné ztrátˇe a dovol´ı uˇzivateli dodateˇcnˇe rozhodnout, kterou verzi si ponechá. Server ˚ ze vybrat pouze jednu variantu záznamu. Podle poˇzadavku˚ také muˇ uˇzivatele vˇzdy záznam uloˇzeny´ na serveru, u klienta nebo ten, ktery´ ˚ byl aktualizován pozdˇeji. Tˇret´ım zpusobem, jak na konflikt zareagovat, je slouˇcen´ı dat dvou záznamu˚ do jednoho. V tomto pˇr´ıpadˇe mus´ı server znát strukturu a vlastnosti synchronizovanych ´ dat.

•

Aby mohl synchronizaˇcn´ı server správnˇe porovnávat strukturovaná data, mus´ı byt ´ jasnˇe dany´ formát, v jakém se data odes´ılaj´ı k synchro´ nizaci. Tyk´ s telefonn´ım cˇ ´ıslem, které lze zapsat ´ a se to tˇreba udaje ˚ nˇekolika zpusoby.

•

˚ ym Vzhledem k ruzn ´ vlastnostem zaˇr´ızen´ı zapojenych ´ do synchronizace je potˇreba rozliˇsovat, zda záznam obsahuje urˇcitá data proto, ˚ ˚ Situaci zˇ e doˇslo k jejich zmˇenˇe uˇzivatelem, nebo z jinych u. ´ duvod ilustruje stav, kdy záznam kontaktu na serveru obsahuje foto, ale u klienta ne. Pˇri synchronizaci mus´ı server rozhodnout, zda bylo foto uˇzivatelem odstranˇeno nebo zaˇr´ızen´ı nepodporuje jejich ukládán´ı ke ˚ kontaktum.

•

Do procesu synchronizace dat mohou byt ´ zapojeny mobiln´ı zaˇr´ızen´ı, které maj´ı k dispozici pouze omezené hardwarové prostˇredky. Tyk´ ´ a se to jak rychlosti procesoru, tak operaˇcn´ı pamˇeti a kapacity uloˇziˇstˇe dat. 3

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ

2.2

Pˇrehled synchronizaˇcn´ıch protokolu˚

2.2.1

IrMC

Protokol IrMC slouˇzil k vymˇ ´ enˇe informac´ı pˇres infraˇcervené rozhran´ı. De´ ´ finováno je pˇet urovn´ ı jak pˇrenásˇ et data [9]. Nejniˇzsˇ´ı urove nˇ obsahuje pouze logiku obyˇcejného pˇrenosu objektu˚ mezi dvˇema zaˇr´ızen´ımi. Nejvyˇssˇ´ı ´ urove nˇ pˇredstavuje synchronizaci zaloˇzenou na OMA DS, která byla do ´ specifikace pˇridána pozdˇeji. Urovnˇ e jedna aˇz cˇ tyˇri podporuj´ı práci pouze ´ s omezenym e pˇr´ıliˇs vhodné ´ rozsahem typu˚ dat. Také nejsou tyto urovnˇ pro pˇrenos dat pˇres velké s´ıtˇe a hod´ı se hlavnˇe na lokáln´ı synchronizaci s poˇc´ıtaˇcem. Pro komunikaci se vyuˇz´ıvá protokol IrOBEX.

2.2.2

HotSync a Palm zaˇr´ızen´ı

HotSync vedle dalˇs´ıch funkc´ı slouˇz´ı k synchronizaci dat zaˇr´ızen´ı s Palm OS (oznaˇcovanych ´ také jako Palm Classic) s daty v poˇc´ıtaˇci uˇzivatele [12]. Synchronizaci rˇ´ıd´ı klientsky´ proprietárn´ı software – HotSync Manager. Ten mohl byt ´ rozˇsirován o tzv. conduity, které otev´ıraly cestu jak libovolnˇe nakládat se synchronizovanymi daty. Existuje tedy napˇr. conduit pro MS Ex´ change, ktery´ data ukládá na centráln´ı server. U unixovych systému˚ se ´ k synchronizaci vyuˇz´ıvá knihovny pilot-link. S pˇr´ıchodem Palm zaˇr´ızen´ı postavenych ´ na novém operaˇcn´ım systému webOS se od uˇzit´ı HotSync Manageru upustilo [13]. Systém standardnˇe podporuje pouze synchronizaci s online sluˇzbami, napˇr. sociáln´ımi s´ıtˇemi. Synchronizaci s desktopem zajiˇst’uje software tˇret´ıch stran.

2.2.3

ActiveSync, WMDC, Exchage ActiveSync

ActiveSync a Windows Mobile Device Center je sada proprietárn´ıch technologi´ı a softwaru pro synchronizaci dat z mobiln´ıch zaˇr´ızen´ı od firmy Microsoft [14]. ActiveSync pracuje pod operaˇcn´ımi systémy do Windows XP, WMDC od Windows Vista dál. Po pˇrejmenován´ı klientského softwaru se pouˇz´ıvá oznaˇcen´ı ActiveSync jen ve spojitosti s protokolem a synchronizac´ı dat proti MS Exchange. Kromˇe mobiln´ıch Windows najdeme oficiáln´ı podporu protokolu Exchange ActiveSync také u dalˇs´ıch firem, které maj´ı tuto technologii licencovanou. 4

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ 2.2.4

OMA DS (SyncML)

OMA Data Synchronization, dˇr´ıve známy´ jako SyncML, zaˇcal vznikat v roce 2000 s c´ılem vytvoˇrit otevˇreny´ a jednotny´ synchronizaˇcn´ı protokol pro data mobiln´ıch zaˇr´ızen´ı [4]. Pod hlaviˇcnou The SyncML Initiative se od poˇca´ tku se na vyvoji pod´ıl´ı silné firmy jako IBM, Nokia nebo Motorola. ´ Od roku 2002 zastˇreˇsuje protokol Open Mobile Aliance a doˇslo tak i k jeho pˇrejmenován´ı. Doposud vznikly tˇri verze [6].

Hlavn´ı vlastnosti verze 1.0: • • • • • • • • •

˚ e typy synchronizac´ı; ruzn´ pouˇzit´ı kotev; jednoznaˇcné identifikátory objektu˚ na serveru a klientovi; ˚ rˇ eˇsen´ı konfliktu; autentizace; vymˇ ´ ena informac´ı o zaˇr´ızen´ı; správa pamˇeti zaˇr´ızen´ı; synchronizace bez pˇredchoz´ı inicializace; singnalizace pˇret´ızˇ en´ı serveru.

Hlavn´ı zmˇeny ve verzi 1.1: • • • • •

práce s velkymi objekty; ´ rozˇs´ırˇ en´ı autentizace; odes´ılán´ı informace o poˇctu zmˇen; oznaˇcen´ı signalizace pˇret´ızˇ en´ı jako nepovinné cˇ a´ sti; ˚ pˇrenásˇ en´ı velkych ´ objektu.

Hlavn´ı zmˇeny ve verzi 1.2: • • • • •

pˇreruˇsen´ı a obnova synchronizace; synchronizace zahájená serverem; synchonizace hierarchickych ´ dat; filtrován´ı u adresace dat; datové objekty pro sloˇzku, soubor a email. 5


2.3

Zpusoby ˚ pˇrenásˇ en´ı dat mobiln´ıch zaˇr´ızen´ı

2.3.1

Sériovy´ port

Jednou z prvn´ıch moˇznost´ı, jak pˇrenásˇ et data mobiln´ıch zaˇr´ızen´ı, bylo pˇripojen´ı kabelem pˇres sériovy´ port. Vyrobci mobiln´ıch zaˇr´ızen´ı obvykle po´ uˇz´ıvali kabely s vlastn´ımi nestandardn´ımi koncovkami a neexistoval tak jeden univerzáln´ı. Vedle origináln´ıch vyrobk u˚ se objevovalo také kompa´ ˇ tibiln´ı neorigináln´ı pˇr´ısluˇsenstv´ı, které vˇsak umoˇznovalo provést nˇekteré operace, napˇr. zmˇenu firmware. 2.3.2

Infraˇcerveny´ port

Pˇrenos pˇres infraˇcerveny´ port pˇredstavoval pro mobiln´ı zaˇr´ızen´ı prvn´ı ˚ Velká nevyhoda moˇznost, jak data pˇrenásˇ et bez kabelu. oproti dnes obvyk´ ˚ spoˇc´ıvá v nutnosti pˇr´ımé viditelnosti [11]. lejˇs´ım bezdrátovym ´ pˇrenosum Vzdálenost obou zaˇr´ızen´ı nesm´ı pˇresahovat jeden metr. U n´ızkoenergetickych zaˇr´ızen´ı typu mobiln´ı telefon se tato vzdálenost nav´ıc zkracuje na ´ ˚ Za kladné vlastnosti bych uvedl pouˇzitelnost nˇekolik des´ıtek centimetru. v prostˇred´ıch, kde nelze vyuˇz´ıt pˇrenos po rádiovych vlnách. Dále hard´ ware, ktery´ je levnˇejˇs´ı neˇz u Bluetooth. Odpadá také nutnost párován´ı zaˇr´ızen´ı (vyhoda napˇr. pro veˇrejné tiskárny). ´ Pˇrenos pomoc´ı infraˇcerveného svˇetla pouˇz´ıvany´ v mobiln´ıch zaˇr´ızen´ıch navrhuje organizace IrDA, zaloˇzená v roce 1993. Doposud pod jejich hlaviˇckou vzniklo pˇres 30 specifikac´ı[10], pracuj´ıc´ıch na vˇsech vrstvách s´ıt’ové komunikace. Aˇckoliv doba nejvˇetˇs´ı popularity pˇrenosu dat pˇres infraˇcerveny´ port pominula, stále vznikaj´ı nové specifikace. Nedá se vylouˇcit ani opˇetovny´ návrat popularity aktuáln´ıch technologi´ı od IrDA – hlavnˇe gigabitového pˇrenosu. Popis nˇekterych ´ specifikac´ı IrPHY Specifikace nejniˇzsˇ´ı komunikaˇcn´ı vrstvy – fyzické vrstvy. Definované jsou parametry jako délka a intenzita vlnového zárˇ en´ı nebo vzdálenosti a vzájemné natoˇcen´ı dvou zaˇr´ızen´ı. Pˇrenos vˇzdy prob´ıhá pouze v reˇzimu half-duplex. Full-duplex se simuluje rychlym ´ pˇrep´ınán´ım vys´ılaˇce a pˇrij´ımaˇce. Rychlost pˇrenosu se pohybuje od 9.6 kbps po 1 Gbps. ˚ zitˇejˇs´ı IrLAP Link access protocol pracuje na datové vrstvˇe. Mezi nejduleˇ funkce patˇr´ı vyhledáván´ı zaˇr´ızen´ı v okol´ı, navazován´ı spojen´ı a 6

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ rˇ´ızen´ı pˇr´ıstupu. Na této vrstvˇe se zaˇr´ızen´ı rozdˇeluj´ı na primárn´ı, která rˇ´ıd´ı ta sekundárn´ı. Data mohou byt ´ vyslána pouze smˇerem od sekundárn´ıho zaˇr´ızen´ı k primárn´ımu. ˚ IrLMP Link management protocol se stará o správu logickych kanálu, ´ poskytovanych sluˇzeb a pˇrep´ınán´ı primárn´ıho a sekundárn´ıho ´ zaˇr´ızen´ı. Tiny TP Tiny Transport protocol zajiˇst’uje hlavnˇe pˇrenos velkych ´ zpráv jejich rozdˇelen´ım na menˇs´ı a následnym ´ sloˇzen´ım. IrObex Zkratka vznikla se slov Object Exchange, název se vˇetˇsinou zkracuje jen na OBEX. Protokol se dá pˇrirovnat k HTTP. Na rozd´ıl od nˇej se vˇsak jedná o binárn´ı formát. Data se ukládaj´ı do hlaviˇcek, které nesou i informaci o velikosti dat. Takovy´ pˇr´ıstup pomáhá snazˇs´ımu parsován´ı a je tedy vhodnˇejˇs´ı pro málo vykonn´ a mobiln´ı zaˇr´ızen´ı. ´ OBEX odporuje sezen´ı a nen´ı tedy bezstavovy´ jako HTTP. V jednom spojen´ı lze tedy provést nˇekolik nezávislych ´ operac´ı. Protokol se stal obl´ıbenym ´ i v dalˇs´ıch oblastech komunikace a tak je OBEX implementovany´ napˇr. pro Bluetooth. ´ u. ˚ Ve IrMC Protokol na vymˇ udaj ´ enu vizitek, kontaktu˚ a podobnych ´ ´ vyvoji se d´ a le nepokraˇ c uje. M´ ı sto IrMC se pouˇ z ı v´ a k synchronizaci ´ SyncML. Giga-IR Standardizace pˇrenosu rychlost´ı 1 Gbps byla dokonˇcena v dubnu 2009. Pro dosaˇzen´ı této rychlosti se upustilo od LED a vyuˇz´ıvá se ˚ laserovych ´ paprsku. 2.3.3

Mobiln´ı internet

Poˇca´ tky rozvoje mobiln´ıho internetu spadaj´ı do konce devadesátych ´ let a obdob´ı 2G s´ıt´ı GSM. Pˇr´ıstup k internetu se poprvé objevil v komunikátoru Nokia 9000 v roce 1996 [15]. V´ıce se vˇsak mobiln´ı internet zaˇcal rozˇsiˇrovat aˇz o pár let pozdˇeji. Dalˇs´ı miln´ıky pˇriˇsly v roce 1999, kdy poprvé pˇriˇsel na trh telefon s prohl´ızˇ eˇcem wapu (jednalo se o Nokii 7110, která dalˇs´ıho prvenstv´ı dosáhla také integrován´ım infra portu). ˇ v souˇcasné dobˇe cˇ tyˇri operátoˇri, z nichˇz jeMobiln´ı internet nab´ız´ı v CR ´ den se orientuje pˇrevázˇ nˇe na datové sluˇzby. Na vˇetˇsinˇe uzem´ ı je dostupné pˇripojen´ı pˇres GPRS a EDGE. To samo o sobˇe dostaˇcuje pro synchronizaci nevelkych ´ textovych ´ informac´ı (napˇr. seznamu kontaktu˚ nebo kalendárˇ e). ´ Na velké cˇ a´ sti uzem´ ı také celkem spolehlivˇe funguje CDMA pˇripojen´ı, které 7


ˇ Obrázek 2.1: Mapa pokryt´ı Cesk´ e republiky mobiln´ı s´ıt´ı tˇret´ı generace. Zdroj: http://client0.cellmaps.com/viewer.html

dovol´ı sychnronizaci vˇetˇs´ıho objemu dat. Stále v´ıce velkych mˇest je také ´ pokryto s´ıt´ı tˇret´ı generace, jejichˇz pˇrenosové rychlosti uˇz nebrán´ı synchroˇ nizaci i opravdu velkého mnoˇzstv´ı dat. Pokud se na mobiln´ı internet v CR ˚ tak základn´ı datovy´ tarif má obvykle popod´ıváme z hlediska nákladu, dobu GPRS pˇripojen´ı s placen´ım za pˇrenesená data. Platby se pohybuj´ı v rˇ a´ du halérˇ u˚ za jeden kilobyte, takˇze cena synchronizace textovych dat ´ pˇres mobiln´ı internet je vcelku pˇrijatelná. Rozvoj 3G s´ıtˇe vˇsak za okoln´ımi státy dost zaostává, jak je vidˇet na obrázku 2.1.

2.3.4

Bluetooth

Technologie Bluetooth pˇrinesla velky´ posun ve sférˇ e bezdrátového pˇrenosu u PAN (Personal Area Network). Odpadávaj´ı hlavn´ı nedostatky IrDA – zaˇr´ızen´ı mohou byt ´ od sebe vzdálena aˇz nˇekolik des´ıtek metru˚ bez nutnosti pˇr´ımé viditelnosti. Pˇrenos prob´ıhá po rádiovych ´ vlnách na volném (nelicencovaném) kmitoˇctu 2.4 Ghz a pˇrekonává tak i pevné pˇrekázˇ ky v cestˇe. Mezi hlavn´ı pˇrednosti této technologie patˇr´ı otevˇrená specifikace vˇcetnˇe volného vyuˇzit´ı a moˇznost pˇrenosu dat i hlasu, pˇriˇcemˇz si zachovává n´ızkou energetickou nároˇcnost. Proto Bluetooth najdeme nejen v mobiln´ıch zaˇr´ızen´ıch, ale také u bezdrátovych ´ klávesnic, myˇs´ı, sluchátek, hands-free sad a dalˇs´ıch. Specifikace pˇripravuje sdruˇzen´ı firem nazvané Bluetooth SIG (Special Interest Group), které bylo zaloˇzeno v roce 1998 [17]. V souˇcasné ˚ dobˇe má Bluetooth SIG tis´ıce cˇ lenu. Verze 1.0 vznikla v roce 1999. Rozˇs´ırˇ ila se vˇsak aˇz verze 1.1, která opra8

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ vila spoustu problému˚ nalezenych ´ v pˇredchoz´ıch verz´ıch [16]. Zlepˇsila se ˚ ejˇs´ıch zaˇr´ızen´ı. S verz´ı 1.2 pak hlavnˇe oblast vzájemné spolupráce nejruznˇ pˇriˇsly i nové vlastnosti, ale dbalo se na zpˇetnou kompatibilitu s pˇredchoz´ı specifikac´ı. Nejvyˇssˇ´ı pˇrenosové rychlosti u prvn´ıch variant dosahovaly 1Mbps. U druhé rˇ ady doˇslo zejména ke zvyˇ ´ sen´ı pˇrenosové rychlosti na 3Mbps. Specifikace byla vydána v roce 2004. V zaˇr´ızen´ıch se zaˇcala podpora této verze objevovat o rok pozdˇeji. Opˇet byla dodrˇzena zpˇetná kompatibilita. Kromˇe pˇrenosové rychlosti byla optimalizována spotˇreba energie, pˇribyla podpora komunikace s v´ıce zaˇr´ızen´ımi najednou a také broadcast a multicast. Verze 3.0 nese podtitul High Speed. Kromˇe podpory starˇs´ıch verz´ı Bluetooth obsahuje také vysokorychlostn´ı pˇrenosy s rychlost´ı aˇz 24Mbps. Toho se dosahuje vyuˇzit´ım WiFi technologi´ı z rodiny standardu 802.11 spravovanych ´ organizac´ı IEEE. Verze 4.0 se objevila pˇribliˇznˇe rok po verzi 3.0. Zamˇerˇ uje se vˇsak na ˇ ıc´ı technologie. Hlavn´ı jiné vyuˇzit´ı a jedná se tak o vzájemnˇe se doplnuj´ pˇrednost´ı této verze je n´ızká spotˇreba energie. V tiskové zprávˇe se uvád´ı schopnost nˇekolikaletého provozu na knofl´ıkovou baterii a tedy zlomek energie oproti dnes rozˇs´ırˇ ené verzi Bluetooth. Pˇrenosové rychlosti se vrát´ı ´ na urove nˇ prvn´ıch verz´ı. Zlepˇsit by se vˇsak mˇela bezpeˇcnost pomoc´ı AES sˇ ifrován´ı. Podporován by mˇel byt ´ také vˇetˇs´ı dosah a sn´ızˇ ená latence. Architektura Bluetooth Architektura Bluetooth uvedená na obrázku 2.2 se vyuˇz´ıvá u osobn´ıch poˇc´ıtaˇcu˚ a podobnych ´ zaˇr´ızen´ı. Objevuje se zde oddˇeleny´ hardware s firmwarem a ovladaˇce zvané Bluetooth stack. Ty byvaj´ ´ ı souˇca´ st´ı operaˇcn´ıho systému nebo nainstalované jako bˇezˇ ny´ software (lze je tedy v pˇr´ıpadˇe potˇreby vymˇenit za jiné). Takovy´ software se snaˇz´ı byt ´ co nejv´ıce uni´ celovych verzáln´ı. Naproti tomu stoj´ı pouˇzit´ı v jednouˇ zaˇr´ızen´ıch, napˇr. ´ klávesnici nebo hands-free. U nich cˇ asto chyb´ı HCI rozhran´ı a hardware i software tvoˇr´ı jeden celek. V takovych ´ pˇr´ıpadech samozˇrejmˇe podporuje software jen kokrétn´ı Bluetooth profil, ktery´ potˇrebuje ke svému provozu. Popis nˇekterych ´ protokolu˚ [19] SDP Protokol pouˇz´ıvany´ k vyhledáván´ı zaˇr´ızen´ı a podporovanych ´ sluˇzeb. ˚ Je pˇrevzaty´ ze speciOBEX Protokol slouˇz´ıc´ı k vymˇ ´ enˇe datovych ´ objektu. fikace IrOBEX. 9


Obrázek 2.2: Bluetooth stack s hlavn´ımi protokoly [18]

RFCOMM RFCOMM je protokol, ktery´ emuluje pˇrenos dat pˇres seriovy´ port (RS-232). Podporuje aˇz 60 spolehlivych ´ komunikaˇcn´ıch kanálu˚ mezi dvˇema zaˇr´ızen´ımi. ˚ L2CAP Multiplexovac´ı vrstva, která dovoluje protokolum na vyˇssˇ´ıch vrstvách pˇrenásˇ et data pˇres Bluetooth. L2CAP komunikuje pomoc´ı HCI s basebandem na stranˇe hardwaru. Stará se také o rozdˇelován´ı a skládán´ı packetu˚ nebo zajiˇst’ován´ı kvality sluˇzeb. HCI HCI poskytuje jednotné rozhran´ı komunikace s Bluetooth hardwarem. Skládá se ze tˇr´ı cˇ a´ st´ı: HCI firmwaru, ktery´ je souˇca´ st´ı Bluetooth hardwaru, HCI ovladaˇc, ktery´ pocház´ı ze softwaru Bluetooth zaˇr´ızen´ı a transportn´ı vrstvu, která propojuje tento firmware a software. LMP Pouˇz´ıvá se k rˇ´ızen´ı a provádˇen´ı vˇsech operac´ı, které se tykaj´ ´ ı spojen´ı dvou zaˇr´ızen´ı vˇcetnˇe autentizace, vyhledáván´ı jinych ´ LM, párován´ı a dalˇs´ıch. TCP Protokol, ktery´ nastavuje a rˇ´ıd´ı hovory mezi dvˇema zaˇr´ızen´ımi. Bluetooth profily ˚ zitou souˇca´ st´ı Bluetooth specifikace jsou profily. Ty pˇredstavuj´ı Dalˇs´ı duleˇ ˚ standardn´ı zpusob, jak vyuˇz´ıvat vybrané sluˇzby. Definovány jsou cˇ tyˇri 10

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ základn´ı profily. Ty se nazyvaj´ ´ ı pˇrenosové profily [1]. Generic access profile Základn´ı profil, na kterém stav´ı vˇsechny ostatn´ı. GAP definuje funkcionalitu nutnou pro navazován´ı a správu spojen´ı, vyhledáván´ı dalˇs´ıch zaˇr´ızen´ı a oˇsetˇren´ı bezpeˇcnosti. Service discovery application profile SDAP popisuje operace a postupy nutné k vyhledán´ı sluˇzeb na vzdáleném zaˇr´ızen´ı. Serial port profile SPP emuluje pˇripojen´ı pˇres seriovy´ port pomoc´ı RFCOMM protokolu. Zastaralé aplikace tak mohou transparentnˇe vyuˇz´ıvat pˇrenos pˇres Bluetooth m´ısto seriového kabelu. Generic object exchange profile Jedná se o abstraktn´ı profil, ktery´ je základem dalˇs´ıch profilu˚ vyuˇz´ıvaj´ıc´ıch OBEX. Profil obsahuje vˇsechnu logiku práce s objekty pˇres OBEX, nutnou napˇr. pro pˇrenos souboru˚ nebo synchronizaci. Dále existuje rˇ ada aplikaˇcn´ıch profilu˚ [8]. Pokud dvˇe zaˇr´ızen´ı chtˇej´ı mezi sebou napˇr. pˇrenásˇ et soubory, mus´ı obˇe obsahovat pˇr´ısluˇsny´ profil, ktery´ tuto funkcionalitu implementuje. Ukázky standardn´ıch aplikaˇcn´ıch profilu˚ A2DP Advanced Audio Distribution Profile. Pˇrenos stereo zvuku. BIP Basic Imaging Profile. Definuje, jak pracovat na dálku s grafickymi ´ soubory, jak je tisknout nebo pˇrenásˇ et. CTP Cordless Telephone Profile. Popisuje, jak mohou byt ´ bezdrátové telefony implementovány pˇres Bluetooth rozhran´ı. ˇ DUN Dial-Up Network Profile. Zpˇr´ıstupnuje mobiln´ı pˇripojen´ı k internetu jinym ´ zaˇr´ızen´ım. FTP File Transfer Profile. Definuje, jak mohou byt ´ procházeny adresárˇ e a soubory. HID Human Interface Profile. Implementuje protokol a vlastnosti pˇr´ıstupu k zaˇr´ızen´ım jako klávesnice a myˇsi. PAN Personal Area Network. Popisuje, jak vytvárˇ et ad-hoc s´ıtˇe mezi zaˇr´ızen´ımi. Pouˇz´ıvá se také pro zpˇr´ıstupnˇen´ı pˇripojen´ı k internetu. 11

2. S YNCHRONIZACE DAT MOBILNÍ CH ZA Rˇ Í ZENÍ 2.3.5

USB rozhran´ı

Univerzáln´ı seriové rozhran´ı postupnˇe vytlaˇcilo kabely s proprietárn´ımi konektory. Malá mobiln´ı zaˇr´ızen´ı obsahuj´ı nejˇcastˇeji variantu mini USB konektoru. Rozhran´ı cˇ asto slouˇz´ı i k nab´ıjen´ı nebo funkci Mass Storage. Pˇrenosové rychlosti dovoluj´ı snadné zaplnˇen´ı pamˇeti zaˇr´ızen´ı vˇcetnˇe gigabytovych ´ pˇr´ıdavnych ´ karet. 2.3.6

WiFi

WiFi se objevuje stále cˇ astˇeji i u malych ´ mobiln´ıch zaˇr´ızen´ı. Ty se pak mohou snadno pˇripojit do m´ıstn´ı s´ıtˇe a provést tˇreba pˇrenosy velkych ´ objemu˚ dat. Rychlost pˇrenosu a dalˇs´ı aspekty této technologie vˇsak pˇrinásˇ i i negativa. C´ılovou platformou WiFi nejsou malá zaˇr´ızen´ı napájená z baterie, ˚ ze rychle spotˇrebovat takˇze i samotné vyhledáván´ı pˇr´ıstupovych ´ bodu˚ muˇ dostupnou energii. ˇ arové kody 2.3.7 C´ ´ ˚ Pomˇernˇe novy´ zpusob, jak pˇrenásˇ et data do mobiln´ıch zaˇr´ızen´ı vyba´ u. ˚ Ty se jednoduˇse venych ´ fotoaparátem, spoˇc´ıvá ve vyuˇzit´ı cˇ a´ rovych ´ kod ´ vyfot´ı a pomoc´ı specializovaného softwaru rozkoduj´ ı. Nelze takto pˇrenásˇ et ´ echem se této metody uˇz´ıvá napˇr. pro velká mnoˇzstv´ı dat, ale s uspˇ pˇrenos webové adresy nebo vizitky. C´ıl´ı se hlavnˇe na zaˇr´ızen´ı bez klasické klávesnice. Uˇzivatel tak nemus´ı zdlouhavˇe zadávat data ruˇcnˇe.

12

Kapitola 3

OMA Data Synchronization 3.1

Základn´ı c´ıle návrhu OMA DS protokolu

Pˇri návrhu protokolu bylo potˇreba vyˇreˇsit problémy vztahuj´ıc´ı se jak ˚ synchronizace, tak k ruzn ˚ ym k poˇzadovanym ´ vlastnostem a c´ılum ´ ome˚ ˚ ´ castnˇenych zen´ım zpusoben ym ı zuˇ zaˇr´ızen´ı ´ pˇrenosem dat a ruznorodost´ ´ [3]. V následuj´ıc´ı cˇ a´ sti se nacház´ı popis nˇekterych ´ vlastnost´ı SyncML protokolu. 3.1.1

Efektivita pˇrenosu dat

˚ ze pˇri synchronizaci slouˇzit bezdrátová s´ıt’, jej´ızˇ Jako pˇrenosové médium muˇ ˚ ych ´ parametry byvaj´ se tud´ızˇ ´ ı znaˇcnˇe odliˇsné u ruzn ´ technologi´ı. V uvahu mus´ı vz´ıt malá pˇrenosová rychlost, vysoká doba odezvy, n´ızká spolehlivost a také cena za pˇrenesená data. S malou pˇrenosovou rychlost´ı se návrh vyrovnává snahou o co nejmenˇs´ı objem dat komunikace klienta a serveru. OMA DS protokol je zaloˇzeny´ na ´ XML, které vˇsak nebyv´ e. Proto existuje moˇznost pouˇz´ıt pro ´ a pˇr´ıliˇs usporn´ pˇrenos zpráv binárn´ı verzi XML – WBXML. To bylo navrˇzeno organizac´ı ˚ Wap Forum puvodnˇ e pro potˇreby pˇrenosu dat pˇres WAP. WBXML sniˇzuje ˚ Hodnoty tagu˚ a atributu˚ se velikost nahrazen´ım rˇ etˇezcu˚ jednotlivych ´ tagu. pˇrenásˇ´ı beze zmˇeny. Podrobnˇeji je rozebráno mapován´ı SyncML na binárn´ı XML v cˇ a´ sti XY. ˚ Dalˇs´ı zpusob, jak sn´ızˇ it velikost pˇrenásˇ enych ´ dat, spoˇc´ıvá v pˇrenosu jen novˇe pˇridanych ´ a zmˇenˇenych ´ poloˇzek, pokud to stav synchronizace dovo˚ luje. Tento zpusob vyˇzaduje vˇetˇs´ı nároky na implementovanou logiku, coˇz ˇ ovlivnuje hlavnˇe stranu klienta. U serveru obvykle nepotˇrebujeme sˇ etˇrit do´ stupnymi zdroji. Tato metoda se realizuje tak, zˇ e se uchovávaj´ı udaje o datu ´ posledn´ı editace. Synchronizuj´ı se jen ty, u kterych ´ doˇslo k nˇejaké zmˇenˇe od data posledn´ı synchronizace. Vˇsechny poloˇzky se pˇrenásˇ´ı jen pˇri prvn´ı synchronizaci nebo nestandardn´ı situaci, jako napˇr. chybné nebo pˇreruˇsené synchronizaci. Synchronizace vˇsech poloˇzek se nazyv´ ´ a pomalá synchroni13

3. OMA D ATA S YNCHRONIZATION zace. Problém s vysokou dobou odezvy lze obecnˇe rˇ eˇsit sdruˇzován´ım komunikace do bal´ıku˚ odes´ılanych ´ najednou. Proto SyncML podporuje pˇrenos ˚ vˇetˇs´ıho mnoˇzstv´ı dat a operac´ı v jedné zprávˇe. Tento zpusob pˇrenosu vˇsak narázˇ ´ı na dalˇs´ı nepˇr´ıjemnou vlastnost – n´ızkou spolehlivost s´ıtˇe. Menˇs´ı pˇrenásˇ ená zpráva má vˇetˇs´ı pravdˇepodobnost doruˇcen´ı k c´ıli neˇz zpráva vˇetˇs´ı. Nav´ıc nˇekteré pˇrenosové protokoly mohou omezovat maximáln´ı velikost pˇrenásˇ ené zprávy. SyncML obsahuje také logiku rozdˇelován´ı velkych ´ logickych které se pˇrenásˇ´ı samostatnˇe. Klient ´ celku˚ do menˇs´ıch fyzickych, ´ a server proto mus´ı zvládat logiku rozdˇelován´ı a sdruˇzován´ı zpráv. Tato vlastnost pˇribyla ve verzi 1.1.

3.1.2

Nezávislost na pˇrenosovém médiu a protokolu

˚ stejnˇe jako velké mnoˇzstv´ı Existuje velké mnoˇzstv´ı pˇrenosovych ´ protokolu, pˇrenosovych ´ médi´ı. Dvˇema synchronizovanym ´ zaˇr´ızen´ım vˇsak nezáleˇz´ı na tom, kudy a jak se data pˇrenásˇ´ı. Oni jen chtˇej´ı znát, jaká data se nacház´ı ˚ e scénárˇ e pˇrenosu na druhé stranˇe. Proto se pˇri návrhu uvaˇzovaly ruzn´ SyncML zpráv: Persistentn´ı spojen´ı Dvˇe strany udrˇzuj´ı spojen´ı po celou dobu komunikace bˇehem synchronizace. Tento typ spojen´ı dovoluje efektivn´ı vymˇ ´ enu dat. Jedná se napˇr. o OBEX protokol. Synchronn´ı klient/server komunikace Komunikaci obvykle zahajuje klient, ktery´ odes´ılá poˇzadavek na server. Ten ihned reaguje a vrac´ı odpovˇed’. Typickym ´ pˇr´ıkladem je HTTP protokol. Spadá sem také WSP, ktery´ oproti HTTP podporuje také komunikaci zahájenou serverem. ˚ ze dostat pokyn pro zahájen´ı synchronizace. Klient tak muˇ Asynchronn´ı klient/server komunikace Odpovˇed’ serveru nen´ı odes´ılána v reakci na poˇzadavek klienta, ale aˇz po pˇredem neurˇcité dobˇe. Do této kategorie spadá napˇr. SMTP protokol. ˚ SyncML je navrˇzeno tak, zˇ e podporuje vˇsechny tˇri zpusoby komunikace, ale standardizováno je pouze mapován´ı na tˇri nejbˇezˇ nˇejˇs´ı pˇrenosové protokoly — HTTP, OBEX (napˇr. pˇrenos pˇres Bluetooth, IrDA a USB) a WSP (WAP). 14

3. OMA D ATA S YNCHRONIZATION 3.1.3

Synchronizace libovolnych ´ dat

OMA DS slouˇz´ı k popisu odes´ılanych ´ a z´ıskávanych ´ dat, jejich zmˇen a aktualizac´ı. Popisuje tedy jak s daty nakládat. Nezaj´ımá se vˇsak o data samotná. Nejbˇezˇ nˇeji se pˇrenásˇ´ı osobn´ı data, pro která obsahuje specifikace doporuˇcené formáty a jejich podpora je povinná. Pracovat vˇsak lze s libo´ volnymi e vlastn´ımi. ´ daty – jak s tˇemi s konkrétn´ım MIME typem, tak s uplnˇ ´ Protokol se tedy v zˇ a´ dném pˇr´ıpadˇe neomezuje jen na osobn´ı udaje, resp. ´ PIM udaje, ale lze jej vyuˇz´ıt pro vyvoj libovolného softwaru, ktery´ vyˇzaduje ´ synchronizaci. Standardn´ı formáty pˇrenásˇ enych ´ dat popsanych ´ v SyncML specifikaci rozeb´ırám v cˇ a´ sti XY. 3.1.4

Nezávislost na programovac´ım jazyce

Nezávislost na programovac´ım jazyce vycház´ı z pouˇzit´ı XML a WBXML pro formát zpráv.

3.2

Hlavn´ı vlastnosti protokolu

3.2.1

Synchronizaˇcn´ı kotvy

Synchronizaˇcn´ı kotva je rˇ etˇezec reprezentuj´ıc´ı synchronizaˇcn´ı událost. Nejˇcastˇeji se jedná o datum a cˇ as formátovany´ podle ISO 8601 (napˇr. XXX). ˚ Duvod zaveden´ı tohoto mechanismu spoˇc´ıvá v nutnosti kontroly konzistence dat obou stran – zejména u typu˚ synchronizace, kdy chceme pˇrenést jen cˇ a´ sti dat. Pokud pˇri posledn´ı synchronizaci nebo i kdykoli pozdˇeji doˇslo k chybˇe, zjist´ı se tato skuteˇcnost bˇehem inicializace. Jedna nebo druhá ˚ ze na situaci zareagovat, napˇr. pouˇzit´ım pomalé synchronistrana tak muˇ zace – porovnaj´ı se vˇsechna data obou stran. V SyncML se pouˇz´ıvaj´ı dvˇe synchronizaˇcn´ı kotvy pojmenované Last a Next. Kotva Last se vztahuje k posledn´ı synchonizaci, zat´ımco kotva Next reprezentuje aktuáln´ı syn´ chronizaci. Oba udaje se vztahuj´ı k zaˇr´ızen´ı, které data odes´ılá. Server i klient tedy odes´ılaj´ı jejich vlastn´ı kotvy. Pˇrijatou kotvu Next ukládá zaˇr´ızen´ı do doby neˇz nastane dalˇs´ı synchronizace. Pro server je tato vlastnost povinná. Pokud má zaˇr´ızen´ı pˇri inicializaci k dispozici kotvu Next z posledn´ı synchronizace, porovnává jej´ı hodnotu s kotvou Last. Pˇredpokládá se, zˇ e v pˇr´ıpadˇe shody nedoˇslo od posledn´ı synchronizace k zˇ a´ dné chybˇe. Specifikace dále uvád´ı, zˇ e se kotvy mus´ı ukládat aˇz po zdárném dokonˇcen´ı celé synchronizace. V dobˇe, kdy synchronizace probˇehla v poˇra´ dku, uˇz se tedy nemaj´ı pˇrenásˇ et dalˇs´ı zprávy a komunikaˇcn´ı kanál je korektnˇe uzavˇren. 15

3. OMA D ATA S YNCHRONIZATION 3.2.2

Mapován´ı na LUID a GUID

SyncML nevyˇzaduje, aby databáze dvou synchronizovanych stran byly ´ identické. Liˇsit se mohou v podporovanych ´ vlastnostech, formátován´ı dat a také svoj´ı jednoznaˇcnou identifikac´ı v databázi serveru a klienta (tedy primárn´ım kl´ıcˇ em v databázové terminologii). V takovém pˇr´ıpadˇe je vˇsak nutné uchovávat informace o mapován´ı serverovych ´ dat na data klientská. Mluv´ı se o globáln´ıch identifikátorech dat (GUID), které udrˇzuje server a lokáln´ıch indentifikátorech dat (LUID), které udrˇzuje klient. Pˇri z´ıskáván´ı novych ´ dat vrac´ı klient serveru záznamy o tom, jaké LUID pˇriˇradil k GUID zaslaného serverem. Server tuto informaci uchovává a páruje podle toho záznamy pˇri dalˇs´ıch synchronizac´ıch. GUID byv´ ´ a hodnota s vˇetˇs´ım rozsahem neˇz LUID. Mus´ı to byt ´ jednoznaˇcny´ identifikátor ve vˇsech databáz´ıch klientskych dat na serveru. LUID mus´ı byt ´ ´ jednoznaˇcné jen pro jednoho ˚ konkrétn´ıho klienta. Pokud server odes´ılá klientovi identifikaci záznamu, které byly na jeho stranˇe od posledn´ı synchronizace zmˇenˇeny, mus´ı byt ´ pouˇzity hodnoty LUID. Server také nesm´ı klientovi odes´ılat pˇri zˇ a´ dné operaci své GUID, pokud by bylo vˇetˇs´ı neˇz to, s kterym ´ by dokázal pracovat. ˇ V takovém pˇr´ıpadˇe pouˇzije server doˇcasné GUID. Spefifikace dále zminuje cachován´ı mapovac´ıch operac´ıch jako nepovinné vlastnosti klienta. ˇ sen´ı konfliktu˚ 3.2.3 Reˇ Konflikt nastává, pokud dojde ke zmˇenˇe alesponˇ jednoho stejného záznamu v databáz´ıch obou zaˇr´ızen´ı, které maj´ı byt ´ synchronizovány. O rˇ eˇsen´ı takovych ´ konfliktu˚ se obvykle stará server. Klient dostává pouze ˚ e oznámen´ı, zˇ e ke konfliktu doˇslo a jak je vyˇreˇseny. ´ SyncML podporuje ruzn´ ˚ ˚ ym ´ zpusoby rˇ eˇsen´ı konfliktu˚ rozliˇsenych ruzn Existuje ´ ´ stavovym ´ kodem. vˇsak moˇznost, jak informovat server o tom, zˇ e si klient pˇreje, aby konflikty rˇ esil sám. V takovém pˇr´ıpadˇe server vrac´ı pouze informaci o existuj´ıc´ım konfliktu. 3.2.4

Logován´ı informac´ı

Klient i server uchovávaj´ı informace o zmˇenách ve svych databáz´ıch od ´ posledn´ı synchronizace. Tato vlastnost je povinná. Zmˇenou se rozum´ı napˇr. pˇridán´ı, odstranˇen´ı nebo nahrazen´ı záznamu. Informace o zmˇenách se vyuˇz´ıvaj´ı pˇri urˇcitych ´ typech synchronizace, kdy nedocház´ı k vymˇ ´ enˇe vˇsech dat. Druh zmˇeny se pˇri odes´ılán´ı dat druhé stranˇe popisuje pomoc´ı dané operace (Add, Replace, Delete,. . . ). Pokud docház´ı k synchronizaci 16

3. OMA D ATA S YNCHRONIZATION s v´ıce neˇz jedn´ım zaˇr´ızen´ım, mus´ı byt ´ moˇzné vrátit pouze zmˇeny, které maj´ı byt ´ vztaˇzeny ke kaˇzdému zaˇr´ızen´ı jednotlivˇe. 3.2.5

Obnova vˇsech dat

Obnova vˇsech dat nepatˇr´ı mezi typické operace pˇri synchronizaci, pˇresto ale byv´ ´ a nˇekdy potˇreba pˇrenést celou databázi z jedné strany na druhou. Stává se tak typicky po havári´ıch hardwaru nebo ztrátˇe dat. SyncML tuto vlastnost podporuje skrze refresh Alert pˇr´ıkaz. 3.2.6

Mazán´ı dat

Mazán´ı dat se v SyncML provád´ı pˇr´ıkazem delete. Pˇri bˇezˇ ném uˇzit´ı docház´ı ke smazán´ı dat z databáze pˇr´ıjemce a zárovenˇ by mˇelo doj´ıt ke zruˇsen´ı vazby na data odes´ılatele (napˇr. pˇri pˇresunu vymazanych ´ dat do jiné da˚ tabáze). Tento zpusob se oznaˇcuje jako hard delete“. K nˇemu tedy exis” ˇ tuje jeˇstˇe soft delete“, ktery´ umoˇznuje smazat data z klientské cˇ a´ sti s t´ım, ” ˚ zˇ e stále zustanou dostupná v serverové cˇ a´ sti. Návrh této vlastnosti je motivován mobiln´ımi zaˇr´ızen´ımi s malou kapacitou pamˇeti, kdy existuje ˚ zitˇejˇs´ı data. Zaˇr´ızen´ı s dostateˇcnou kapamoˇznost uvolnit pamˇet’ pro duleˇ ˚ citou pamˇeti vˇsak maj´ı pˇr´ıstup ke vˇsem datum, protoˇze nedoˇslo k jejich smazán´ı ze serveru. Pokud klient vyvolá soft delete na datech, které uˇz jsou vˇsak v té dobˇe hard deleted na serveru, dojde k vyvolán´ı Soft-Delete konfliktu. Specifikace pˇr´ımo neurˇcuje, jak v takové situaci pokraˇcovat a záleˇz´ı tedy na synchronizaˇcn´ım softwaru, zda a jak tento problém vyˇreˇs´ı. Pˇr´ıkaz ˚ ze obsahovat pokyn k archivaci dat pˇred samotnym delete muˇ ´ odstranˇen´ım dat. Tato vlastnost vˇsak nen´ı povinná. 3.2.7

Vymˇ ´ ena informac´ı o vlastnostech zaˇr´ızen´ı

SyncML je navrhován jako univerzáln´ı jazyk pro synchronizace dat. ˚ ze prob´ıhat mezi nejruznˇ ˚ ejˇs´ımi zaˇr´ızen´ımi. JeVzájemná synchronizace muˇ ˇ jich podporované vlastnosti se mohou velmi vyraznˇ e liˇsit a ovlivnovat ´ ˚ eh synchronizace. Proto docház´ı mezi zaˇr´ızen´ımi k vymˇ prubˇ ´ enˇe informac´ı ˚ o jejich vlastnostech. To nab´ız´ı zaˇr´ızen´ım moˇznost pˇrizpusobit se vlastnos´ esˇ né dokonˇcen´ı synchronitem druhé strany. T´ım se zvyˇsuj´ı sˇ ance na uspˇ zace. ´ Informace zas´ılá klient povinnˇe pˇri uplnˇ e prvn´ı synchronizaci s danym ´ serverem, pˇri zmˇenˇe tˇechto informac´ı nebo na poˇza´ dán´ı. Klient vˇsak nemus´ı podporovat pˇr´ıjem takovych ´ informac´ı ze serveru. Pokud klient indi17

3. OMA D ATA S YNCHRONIZATION kuje, zˇ e tˇemto informac´ım rozum´ı, mus´ı se jimi rˇ´ıdit. Dále se doporuˇcuje zvázˇ it, kdy je nutné informace o vlastnostech zaˇr´ızen´ı odes´ılat, protoˇze tak docház´ı k pˇrenosu vyznamn´ eho mnoˇzstv´ı dat. Zaˇr´ızen´ı by napˇr. nemˇelo ´ vyˇzadovat informace o druhé stranˇe pˇri kaˇzdé synchronizaci. Nemˇelo by také docházet k odes´ılán´ı informac´ı, u kterych ´ je známo, zˇ e je druhá strana nezpracuje nebo nevyuˇzije (nemá vyznam odes´ılat podrobnosti o vlastnos´ tech, kterym ´ v daném formátu server rozum´ı, pokud klient tento formát ˚ nepodporuje vubec). 3.2.8

Adresa zdroje a c´ıle synchronizace

Vˇetˇsina/kaˇzdá zpráva bˇehem synchronizace obsahuje adresu zdroje a c´ıle dat – tedy adresu klienta a serveru. Nejˇcastˇeji se zde objevuje URI objektu ve tvaru absolutn´ı nebo relativn´ı adresy. V pˇr´ıkladu XY to je adresa webového serveru, ktery´ provád´ı sychronizaci a unikátn´ı identifikace telefonu. http://localhost:8080/sync <Source> IMEI:1234567890

ˇ ıc´ı informace. AdTyto poloˇzky vˇsak mohou obsahovat i dalˇs´ı upˇresnuj´ ˚ ze pˇr´ımo odkazovat na konkrétn´ı databázi dat nebo pˇr´ımo na resa se muˇ jednu poloˇzku v databázi. Adresa kontaktu cˇ ´ıslo 1234 v databázi urˇcitého telefonu. <Source> IMEI:1234567890/contacts/1234

V nˇekterych ´ pˇr´ıpadech byv´ ´ a uˇziteˇcné adresovat jen cˇ a´ st databáze dat. ´ celu slouˇz´ı filtrován´ı dat identifikovanych K tomu uˇ ´ tˇemito adresami. Spe˚ ych ˚ cifikace obsahuje popis, jak z´ıskat data podle ruzn ´ hodnot atributu. 3.2.9

Správa pamˇeti zaˇr´ızen´ı

Nˇekterá zaˇr´ızen´ı disponuj´ı omezenou pamˇet´ı pro ukládán´ı dat a proto byla zavedena vymˇ ´ ena informac´ı o jej´ı volné kapacitˇe. Pˇredcház´ı se tak ´ esˇ nym ˚ neuspˇ synchronizac´ım z duvodu malé kapacity pamˇeti. Velikost ´ volného m´ısta se pˇrenásˇ´ı pˇri inicializaci. Pˇrenásˇ´ı se jak velikost volného ˚ m´ısta v bytech, tak volny´ poˇcet záznamu. 18

3. OMA D ATA S YNCHRONIZATION <Sync> 1 \ldots <Meta> <Mem xmlns=’syncml:metinf’> 8100 81 \ldots

3.2.10 Pˇrenos velkych ´ objemu˚ dat ´ Pˇri pˇrenosech velkého objemu dat mus´ı zdrojové zaˇr´ızen´ı respektovat udaj o maximáln´ı velikosti zprávy a obsaˇzenych ´ datech. Tyto informace mohou byt ´ odeslané bˇehem inicializace v elementech MaxMsgSize a MaxObjSize. Pokud objemy dat pˇresahuj´ı tyto hodnoty, mus´ı doj´ıt k rozdˇelen´ı do v´ıce ´ SyncML zpráv. Prvn´ı pˇrenásˇ eny´ d´ıl dat obsahuje udaj o zbyvaj´ ´ ıc´ı velikosti a pˇr´ıkaz MoreData, podle kterého c´ılové zaˇr´ızen´ı pozná, zˇ e budou následovat dalˇs´ı cˇ a´ sti. Po pˇrijet´ı posledn´ı cˇ a´ sti dat c´ılové zaˇr´ızen´ı spoj´ı vˇsechny do˚ ze hromady a pracuje s nimi jako by je pˇrijal najednou. V jednu chv´ıli muˇ ˚ byt rozdˇeleny. ´ pˇrenásˇ en pouze jeden objekt t´ımto zpusobem ´ Také mus´ı byt ´ ˇ pˇreneseny vˇsechny cˇ a´ sti za sebou. Zádné dalˇs´ı zprávy, které by nesouvisely ´ s pˇrenosem cˇ a´ st´ı dat, nesm´ı byt o zbyvaj´ ´ odes´ılány. Udaj ´ ıc´ı velikosti slouˇz´ı také k zamezen´ı pˇrenose vˇsech dat pˇr´ı pˇreruˇsen´ı synchronizace. 3.2.11 Synchronizace hierarchickych ´ dat Od verze 1.2 podporuje protokol synchronizaci hierarchickych dat. Rea´ lizuje se pomoc´ı elementu˚ SourceParent a TargetParent. Klient v pˇr´ıpadˇe existence rodiˇcovského záznamu odes´ılá jeho LUID vˇzdy v SourceParent. Server pouˇz´ıvá tento element v situaci, kdy rodiˇcovsky´ záznam jeˇstˇe u klienta neexistuje a odes´ılá doˇcasné GUID. TargetParent slouˇz´ı v opaˇcnych ´ situac´ıch – pak server odes´ılá LUID klientské databáze. 3.2.12 Pˇreruˇsen´ı a obnova synchronizace Klient a server mohou podporovat pˇreruˇsen´ı a obnoven´ı dˇr´ıvˇejˇs´ı synchronizace. K pˇreruˇsen´ı synchronizace docház´ı bud’ c´ılenˇe na základˇe poˇzadavku ˚ ˚ ze uˇzivatele nebo v dusledku nˇejaké chyby, napˇr. pˇreruˇsen´ı spojen´ı. Muˇ k nˇemu doj´ıt bˇehem kterékoliv fáze. Zámˇerem této vlastnosti protokolu je zamezit odes´ılán´ı dat, které uˇz byly jednou pˇreneseny bˇehem pˇredchoz´ı synchronizace. Pˇri poˇzadavku na c´ılen´ı pˇreruˇsen´ı by mˇel klient odeslat 19

3. OMA D ATA S YNCHRONIZATION zárovenˇ potvrzen´ı o vˇsech uspˇesˇ nˇe dokonˇcenych ´ operac´ıch, aby se pˇredeˇslo jejich opakován´ı pˇri obnovˇe synchronizace. Pˇri tomto pˇreruˇsen´ı nedocház´ı k aktualizaci kotvy Last. Klient i server si také mus´ı pamatovat, zˇ e byla synchronizace pˇreruˇsena. Obnova zapoˇcaté synchronizace prob´ıhá stejnˇe pro oba druhy pˇreruˇsen´ı i pro vˇsechny typy sychronizac´ı. Provedeny jsou znovu vˇsechny operace, které se nepodaˇrilo dˇr´ıve dokonˇcit. Klient vˇsak mus´ı o obnoven´ı zapoˇcaté synchronizace poˇza´ dat, pˇriˇcemˇz server ˚ ze obnoven´ı odm´ıtnout. Po pˇreruˇsené synchronizaci, která se neobnov´ı, muˇ následuje pomalá synchronizace.

3.2.13 Signalizace pˇret´ızˇ en´ı serveru ˚ ze nastat situace, kdy server pˇrij´ımá data od kliBˇehem synchronizace muˇ enta, ale nezvládá odpovˇedˇet v rozumném intervalu. V takovych ´ pˇr´ıpadech by mˇel server o tomto stavu informovat klienta – odpovˇedˇet se zprávou ´ ˚ ze s pˇr´ısluˇsnym bez vlastn´ıho obsahu, na ktery´ klient cˇ eká. Ten si muˇ ´ kodem ’ vybrat, jestli pozdˇeji poˇza´ dá server o odpovˇed na starˇs´ı zprávu nebo zaháj´ı ˚ ze odpov´ıdat signalizac´ı zaneprázdnˇeného novou synchronizaci. Server muˇ stavu v´ıcekrát za sebou.

3.2.14 Typy synchronizac´ı Dvousmˇerná synchronizace Klient a server si vymˇen´ı zmˇenˇená data od posledn´ı synchronizace mezi tˇemito zaˇr´ızen´ımi. Jednosmˇerná synchronizace Data zmˇenˇená od posledn´ı synchronizace se odes´ılaj´ı jen jedn´ım smˇerem od klienta nebo serveru. Jednosmˇerny´ export/import dat Vˇsechna data jsou odeslána právˇe jen jedn´ım smˇerem od klienta nebo serveru. Pomalá synchronizace Typ obousmˇerné synchronizace, kdy docház´ı k porovnán´ı vˇsech dat mezi serverem a klientem. Pouˇz´ıvá se pˇri prvn´ı synchronizaci nebo ´ esˇ né synchronizaci. po neuspˇ 20

3. OMA D ATA S YNCHRONIZATION 3.2.15 Standardn´ı formáty dat ˇ K tomu, aby zaˇr´ızen´ı splnovalo specifikaci OMA DS, mus´ı podporovat pˇredepsané formáty ze specifikace vObject Minimum Interoperability Proˇ ˚ zda je jejich podpora file [7]. Specifikace zminuje u konkrétn´ıch atributu, nutná nebo vhodná. Jedná se o tyto objekty: vCard 2.1 BEGIN:VCARD VERSION:2.1 FNKE MCGRATH N:MCGRATH, MIKE TEL;WORK;VOICE:+1-919-555-3456 END:VCARD vCalendar 1.0 BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST BEGIN:VEVENT UID:12345-19991015T133000Z SEQUENCE:1 DTSTART:19991026T110000Z DTEND:19991026T190000Z SUMMARY:Technical Committee Meeting CATEGORIES:Appointment ORGANIZER:[email protected] ATTENDEES:[email protected] END:VEVENT END:VCALENDAR vBookmark 1.0 3.2.16 Prubˇ ˚ eh synchronizace Synchronizaˇcn´ı protokol definuje, jak spolu komunikuj´ı klient a server s c´ılem synchronizovat data [6]. Vyuˇz´ıvá se pˇritom ve velké m´ırˇ e funkcionality ostatn´ıch komponent SyncML protokolu. Komunikace mezi klientem a serverem se dˇel´ı na tyto fáze: Inicializace synchronizace •

autentizace mezi klientem a serverem 21

3. OMA D ATA S YNCHRONIZATION • • •

vymˇ ´ ena informac´ı o schopnostech zaˇr´ızen´ı a poskytovanych ´ sluˇzbách popis typu˚ synchronizovaného obsahu ´ esˇ né synchrovymˇ ´ ena a odsouhlasen´ı informace o posledn´ı uspˇ nizaci

Vymˇ ´ ena dat •

ˇ ı samotná vymˇ ´ ena dat. Podle typu synchronizace se vymˇenuj´ vˇsechna nebo jen upravená data.

Ukonˇcen´ı sezen´ı • • •

klient informuje server o vysledku zpracován´ı zmˇen ode´ slanych ´ serverem klient odeˇsle zpˇet serveru informace o mapován´ı pˇridanych ´ poloˇzek server informuje klienta o dokonˇcen´ı sezen´ı

3.2.17 Elementy zpráv synchronizace Reprezentaˇcn´ı protokol obsahuje sadu elementu˚ XML zpráv, ke kterym ´ definuje oblast pouˇzit´ı, formát a vyˇ ´ cet moˇznych ´ odpovˇed´ı. Elementy se dˇel´ı do tˇechto základn´ıch skupin: • • • • •

obálka; rˇ´ıd´ıc´ı elementy; pˇr´ıkazy; obecné elementy; popis dat.

3.2.18 WBXML a OMA DS ´ XML formát sám o sobˇe nepatˇr´ı mezi pˇr´ıliˇs usporn´ e z hlediska objemu dat. Proto organizace WapForum vytvoˇrila specifikaci binárn´ı formy XML jako vhodnˇejˇs´ı varianty pro pˇrenos pˇres linky s omezenou sˇ´ırˇ kou pásma. ˚ Puvodnˇ e byl tento formát navrˇzeny´ pro WAP. Pozdˇeji se vˇsak objevila binárn´ı varianta i dalˇs´ıch protokolu˚ zaloˇzenych ´ na XML vˇcetnˇe SyncML. Tato binárn´ı forma XML je navrˇzena tak, aby zachovávala strukturu a sémantiku dokumentu [3]. Pˇrevod se provád´ı nahrazen´ım názvu˚ tagu˚ a atributu˚ binárn´ımi hodnotami. Pokud chceme dany´ XML soubor pˇrevést 22

3. OMA D ATA S YNCHRONIZATION do binárn´ı podoby, mus´ıme m´ıt k dispozici mapován´ı tˇechto jmen na ˚ ych binárn´ı hodnoty. Mapován´ı lze rozdˇelit do v´ıce cˇ a´ st´ı – mluv´ı se o ruzn ´ ´ kodovac´ ıch stránkách. Tato vlastnost je nutná pro pˇrevod dokumentu˚ ˚ vˇetˇs´ım poˇctem názvu˚ a hod´ı se pro rozdˇelen´ı hodnot do logickych ´ celku. Meta informace jako napˇr. definice typu dokumentu nebo znaková sada se také pˇrekládaj´ı do binárn´ı podoby. Samotny´ obsah atributu˚ a tagu˚ tak ˚ avá jako jediny´ nezmˇenˇeny. zust´ ´ 3.2.19 Protokol OMA DM ´ Protokol OMA Device Management je uzce spojen s protokolem OMA DS. Ve svych ´ poˇca´ tc´ıch byly oba vyv´ıjeny spoleˇcnˇe pod názvem SyncML. Teprve s pˇrechodem SyncML pod organizaci Open Mobile Aliance doˇslo k rozdˇelen´ı na dva nezávislé protokoly. Pˇr´ıbuznost k OMA DS lze ˚ které se od dob SyncML nezmˇenily vidˇet tˇreba na názvech XML tagu, ˚ avaj´ı u obou protokolu˚ stále (pouze pˇribyly nové). Nˇekteré moduly zust´ stejné, napˇr. autentizace. Naproti tomu nejvˇetˇs´ı rozd´ıly spoˇc´ıvaj´ı v jiném pˇrenosu informac´ı o zaˇr´ızen´ı, vˇetˇs´ıch poˇzadavc´ıch na bezpeˇcnost a vlastn´ım ˚ zpusobu pˇrenosu dat. Posledn´ı verze s cˇ ´ıslem 1.2.1 pocház´ı z roku 2008. Pracuje se na verzi 1.3 a také na 2.0. ´ cel protokolu spoˇc´ıvá ve správˇe mobiln´ıch zaˇr´ızen´ı na dálku. Hlavn´ı uˇ Rozdˇelen´ı je moˇzné do tˇrech logickych ´ komponent: [3] •

Bootstrapping – inicializaˇcn´ı fáze nutná pro zahájen´ı správy zaˇr´ızen´ı.

•

Device management protocol – vlastn´ı pˇrenos operac´ı pro správu.

•

˚ které lze spraDevice description framework – popis vˇsech objektu, vovat. Hlavn´ı vlastnosti protokolu se neliˇs´ı od správy bˇezˇ ného PC:

•

Zmˇena parametru˚ (napˇr. nastaven´ı data a cˇ asu, konfigurace Wi-Fi ˚ nebo VPN, pˇridáván´ı a mazán´ı dostupnych ´ certifikátu).

•

Diagnostika zaˇr´ızen´ı (napˇr. rˇ eˇsen´ı problému, monitoring vykonnosti ´ s´ıtˇe).

•

Správa softwaru (napˇr. instalace aplikac´ı, aktualizace firmwaru zaˇr´ızen´ı). 23

3. OMA D ATA S YNCHRONIZATION Vyhody pro c´ılové skupiny uˇzivatelu˚ OMA DM ´ Koncovy´ uˇzivatel Pro koncového uˇzivatele se vyraznˇ e zvyˇsuje pohodl´ı ´ pˇri pouˇz´ıván´ı zaˇr´ızen´ı, kdyˇz nutné zmˇeny nastaven´ı, aktualizace a jiné operace prob´ıhaj´ı automaticky nebo po jednoduchém odsou˚ ze pomoct pˇri rˇ eˇsen´ı hlasen´ı na dálku. Také monitoring zaˇr´ızen´ı muˇ problému bez nutnosti návˇstˇevy technického oddˇelen´ı. Mobiln´ı operátoˇri a podnikové prostˇred´ı Mobiln´ı operátoˇri spravuj´ı rozsáhlé s´ıtˇe, podniky zase velké mnoˇzstv´ı zaˇr´ızen´ı, které vyuˇz´ıvaj´ı zamˇestnanci. Implementace správy pˇres OMA DM nab´ız´ı jednotny´ ˚ ˚ ejˇs´ıch cˇ a´ st´ı s´ıtˇe i zaˇr´ızen´ı. a efektivn´ı zpusob obsluhy nejruznˇ Poskytovatelé sluˇzeb Pro poskytovatele sluˇzeb vˇcetnˇe tˇech internetovych, ´ softwarovych ´ i podnikovych ´ existuje rˇ eˇsen´ı, jak zajistit, aby zaˇr´ızen´ı zákazn´ıka vˇzdy obsahovalo správnou verzi softwaru, resp. firmwaru a jeho konfiguraci. Vyrobci zaˇr´ızen´ı Pro uˇzivatele se stává zaˇr´ızen´ı s implementac´ı protokolu ´ ˚ ze asociovat správy atraktivnˇejˇs´ı a jednoduˇssˇ´ı a tuto skuteˇcnost si muˇ s dalˇs´ımi vyrobky. Nav´ıc OMA DM pˇredstavuje jednotny´ protokol ´ pro vˇsechny zm´ınˇené skupiny a tedy nen´ı potˇreba jich implemento˚ ze m´ıt pozitivn´ı vliv na velikost kodu. ´ vat v´ıce, coˇz muˇ

24

Kapitola 4

Integrace synchronizace dat do webovych ´ aplikac´ı V následuj´ıc´ı cˇ a´ sti práce se budu vˇenovat analyze, návrhu a implemen´ taci prototypu rámce, ktery´ umoˇzn´ı integraci synchronizace dat mobiln´ıch ˇ sit tedy budu, jak zpˇr´ıstupnit data z mozaˇr´ızen´ı do webovych ´ aplikac´ı. Reˇ biln´ıho zaˇr´ızen´ı pˇres webové rozhran´ı, ne vˇsak cely´ proces sychnronizace. Zjednoduˇsenˇe se dá rámec oznaˇcit za prostˇredn´ıka mezi mobiln´ım zaˇr´ızen´ım a synchronizaˇcn´ım modulem.

4.1

Neformáln´ı popis aplikace a poˇzadavky

ˇ ast zadán´ı, tykaj´ C´ eho rámce, nebyla stanovena ´ ıc´ı se podoby vysledn´ ´ ´ konkrétnˇe. Ukolem tedy bylo zamyslet se nad moˇznostmi pˇri vytvárˇ en´ı rámce a nad vlastnostmi, které bude moˇzné implementovat. Stanoven byl programovac´ı jazyk, ve kterém bude aplikace napsána — Java. Webové ´ prohl´ızˇ eˇce podporuj´ı spouˇstˇen´ı javového kodu rˇ adu let a oˇcekávali jsme ˚ emu hardwaru. Nav´ıc by mˇel byt moˇzny´ pˇr´ıstup k ruzn´ ´ rámec navrˇzen tak, aby mohl byt ´ zaˇclenˇen v budoucnu do prostˇred´ı firemn´ıho portálu psaného v Javˇe. 4.1.1

Hlavn´ı funkˇcn´ı poˇzadavky

•

Mus´ı umoˇznit synchronizaci bˇezˇ nych ´ dat mobiln´ıch zaˇr´ızen´ı s webovou aplikac´ı.

•

Mus´ı podporovat synchronizaci vzdálenˇe pˇres mobiln´ı/bezdrátovy´ internet.

•

Mus´ı podporovat synchronizaci lokálnˇe pˇres poˇc´ıtaˇc pˇripojeny´ v s´ıti.

•

Mus´ı byt syn´ rozˇsiˇritelny´ o podporu pˇredem nespecifikovanych ´ ˚ chronizaˇcn´ıch serveru˚ a modulu. 25

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ 4.1.2

Hlavn´ı nefunkˇcn´ı poˇzadavky

•

Pouˇzit´ı programovac´ıho jazyka Java.

•

Mus´ı podporat co nejˇsirˇs´ı poˇcet zaˇr´ızen´ı z hlediska pˇrenosového média.

•

Mus´ı podporat co nejˇsirˇs´ı poˇcet zaˇr´ızen´ı z hlediska synchronizaˇcn´ıho protokolu.

•

˚ e platformy na stranˇe uˇzivatele. Mus´ı podporovat ruzn´

4.2

Analyza ´

Bˇehem základn´ı analyzy ´ bylo potˇreba naj´ıt odpovˇedi na tyto otázky: •

Jaká data mobiln´ıch zaˇr´ızen´ı uˇzivatelé standardnˇe uchovávaj´ı a potˇrebuj´ı synchronizovat?

•

Jakym ´ protokolem pˇrenásˇ et data?

•

Jak pˇrenásˇ et data z mobiln´ıch zaˇz´ızen´ı k webové aplikaci?

4.2.1

Data mobiln´ıch zaˇr´ızen´ı

Spousta dat uchovávanych v mobiln´ım zaˇr´ızen´ıch spadaj´ı do kategorie ´ PIM (Personal Information Management). Jedná se zejména o kontakty, ka´ lendárˇ s ukoly, poznámky, ale také tˇreba záloˇzky prohl´ızˇ eˇce webu nebo wapu. Dále to mohou byt ´ záznamy komunikace pˇres SMS, email nebo chat. U zaˇr´ızen´ı, která mohou slouˇzit ve vˇetˇs´ı m´ırˇ e k vytvárˇ en´ı obsahu, také soubory s dokumenty. Pˇri testován´ı prototypu vytvárˇ eného rámce se zamˇerˇ´ım ˚ kalendárˇ e a poznámek. hlavnˇe na synchronizaci osobn´ıch dat – kontaktu, Vˇetˇsina mobiln´ıch zaˇr´ızen´ı s nimi pracuje a cˇ asto je um´ı i synchronizovat. 4.2.2

Volba protokolu

Volba vlastn´ıho rˇ eˇsen´ı synchronizace by byla opodstatnˇená pouze ˚ Pro uˇ ´ cel v pˇr´ıpadˇe nevyhovuj´ıc´ıch vlastnost´ı jinych ´ dostupnych ´ protokolu. tohoto rámce vˇsak potˇrebuji sp´ısˇ e rozˇs´ırˇ eny´ protokol pro synchronizaci bˇezˇ nych ´ dat bez speciáln´ıch poˇzadavku˚ na chován´ı. Návrh vlastn´ıho protokolu by vydal na samostatnou práci. Hledal jsem proto existuj´ıc´ı protokol. V souˇcasné dobˇe existuje jediny´ rozˇs´ırˇ eny´ a otevˇreny´ synchronizaˇcn´ı protokol pro data mobiln´ıch zaˇr´ızen´ı – je j´ım OMA DS. Mezi vyhody patˇr´ı ´ 26

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ relativnˇe velká podpora v podobˇe nativn´ıch klientskych aplikac´ı v mo´ biln´ıch zaˇr´ızen´ıch a serverovy´ synchronizaˇcn´ı software a sluˇzby. (TODO: Kolik zarizeni/sluzeb). Nav´ıc by bylo moˇzné v pˇr´ıpadˇe nutnosti synchronizace speciáln´ıch typu˚ dat napsat vlastn´ı klientsky´ a serverovy´ software nebo pˇridat podporu do existuj´ıc´ıch. OMA DS neomezuje v tom, jaká data se synchronizuj´ı. 4.2.3

Pˇrenos dat mezi mobiln´ım zaˇr´ızen´ım a webovou aplikac´ı

Existuj´ı dvˇe základn´ı moˇznosti jak z mobiln´ıho zaˇr´ızen´ı pˇristupovat ´ celem synchronizace dat. Prvn´ı spoˇc´ıvá v pˇr´ımém k webové aplikaci za uˇ spojen´ı pˇres internet. Nezáleˇzelo by na tom, zda se jedná o WiFi, pˇrenos dat ˚ pˇres mobiln´ı s´ıt’ nebo jiny´ zpusob. Zaˇr´ızen´ı by pˇr´ımo pˇristupovalo k synchronizaˇcn´ı sluˇzbˇe pomoc´ı pˇr´ısluˇsného protokolu a klientské aplikace. Nejednalo by se tedy o pˇr´ıstup k webové aplikaci pˇres webovy´ prohl´ızˇ eˇc. V druhém pˇr´ıpadˇe se vyuˇz´ıvá dalˇs´ıho zaˇr´ızen´ı, napˇr. poˇc´ıtaˇce, jako ˚ zitou roli rozhran´ı webové aplikace, meziˇclánku. Na nˇem uˇz hraje duleˇ které se pˇri zobrazen´ı stává rozhran´ım k synchronizaˇcn´ımu serveru. Mobiln´ı zaˇr´ızen´ı se pak pˇripojuje lokálnˇe k tomuto rozhran´ı, které poˇzadavky zpracovává – napˇr. pˇrepos´ılá synchronizaˇcn´ımu serveru. Pˇr´ıstupu pˇres vzdálené rozhran´ı lze jednoduˇse naimplementovat jako servlet, ktery´ pracuje podle specifikace s popisem mapován´ı SyncML zpráv na HTTP poˇzadavky. Pˇrijaté zprávy se pˇredávaj´ı synchronizaˇcn´ımu modulu ke zpracován´ı a a odpovˇedi se vrac´ı mobiln´ımu zaˇr´ızen´ı. Lokáln´ı pˇr´ıstup nab´ız´ı v´ıce variant zpracován´ı. C´ılem by se mˇelo byt, ´ ´ ktery´ aby uˇzivatel pˇri otevˇren´ı webového rozhran´ı lokálnˇe spustil kod, bude pracovat jako brána k synchronizaˇcn´ımu modulu webové aplikace. ´ mus´ı byt Kod ´ spuˇstˇen lokálnˇe, protoˇze je potˇreba pˇristupovat k hard´ z webového rozwaru poˇc´ıtaˇce. Ve svˇetˇe Javy lze lokálnˇe spouˇstˇet kod hran´ı pˇres applety a protokol JNLP (Java Network Launching Protocol). ˚ ze teoreticky Proces pˇripojen´ı uˇzivatele k bránˇe a zahájen´ı komunikace muˇ inicializovat jak klient, tak server. Po pˇripojen´ı brána pˇrepos´ılá SyncML zprávy obˇema smˇery. Pro odes´ılán´ı zpráv z lokáln´ıho rozhran´ı synchronizaˇcn´ımu modulu se pouˇz´ıvá servlet urˇceny´ pro vzdáleny´ pˇr´ıstup. Nejrozˇs´ırˇ enˇejˇs´ımi rozhran´ımi pro komunikaci mobiln´ıho zaˇr´ızen´ı a poˇc´ıtaˇce jsou v souˇcasnosti Bluetooth a USB. Vzdálené rozhran´ı pro synchronizaci pˇr´ıstupné pˇres HTTP protokol ˚ avˇsak pˇr´ıstup pˇres byv´ ´ a standardn´ı souˇca´ st´ı synchronizaˇcn´ıch serveru, ´ esˇ ná implementace lokáln´ı rozhran´ı a Bluetooth nebo USB bˇezˇ ny´ nen´ı. Uspˇ takového modulu pro lokáln´ı pˇr´ıstup by pˇrinesla následuj´ıc´ı vyhody: ´ 27

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ •

Pˇr´ıstup pˇres Bluetooth nebo USB i k synchronizaˇcn´ım sluˇzbám, které toto rozhran´ı nativnˇe nepodporuj´ı.

•

´ ˚ Pro nˇekteré uˇzivatele by mohla byt Uspora prostˇredku. ´ brána ´ ´ ´ lokáln´ıho rozhran´ı vyhodnˇ e jˇ s ı , protoˇ z e vyuˇ z ı v´ a poˇ c ı taˇ c pˇ ripojeny´ ´ pˇres bˇezˇ ny´ internet, ktery´ je stále mnohem levnˇejˇs´ı neˇz ten mobiln´ı.

•

Webové rozhran´ı pouˇzité k otev´ırán´ı modulu lokáln´ıho rozhran´ı by mohlo slouˇzit také k rˇ eˇsen´ı událost´ı, které vyˇzaduj´ı zásah uˇzivatele (napˇr. rˇ eˇsen´ı konfliktu˚ pˇri souˇcasné editaci dat na obou stranách synchronizace).

4.2.4

Podpora USB v Javˇe

˚ Vedle nˇekolika komerˇcn´ıch proprietárn´ıch zpusob u˚ pˇr´ıstupu k USB existuje standard JSR-80. Toto API poskytuje pˇr´ımy´ pˇr´ıstup k celkové topologii USB ´ ˇ e API, které kop´ıruje a pˇripojenym nov´ ´ zaˇr´ızen´ım. Jedná se tedy o n´ızkourov topologii USB [21]. Tˇr´ıdy se nacházej´ı v bal´ıku javax.usb. Aˇckoliv specifikace v koneˇcné verzi vznikla v roce 1995, nenaˇsel jsem jej´ı volnˇe pˇr´ıstupnou multiplatformn´ı implementaci. Referenˇcn´ı implementace tohoto API podporuje pouze Linux. ´ Vzhledem k této ne uplnˇ e vyhovuj´ıc´ı podpoˇre USB v Javˇe se dále zamˇerˇ´ım pouze na Bluetooth rozhran´ı. Rámec se vˇsak budu snaˇzit navrhnout tak, aby bylo moˇzné pˇridat podporu USB a jinych ´ technologi´ı pozdˇeji. 4.2.5

Podpora Bluetooth v Javˇe

Specifikace podpory Bluetooth se skryv´ ´ a pod JSR-82. Jej´ı cely´ název zn´ı Java ˇ API for Bluetooth Wireless Technology. Poskytované API umoˇznuje aplikac´ım pracovat s touto technologi´ı jak v malych ´ mobiln´ıch zaˇr´ızen´ıch s Javou ME, tak na desktopu s Javou SE. Primárnˇe se vˇsak za c´ılovou skupinu ˇ povaˇzovala mobiln´ı Java. Návrh API proto zohlednuje malá zaˇz´ızen´ı s omeˇ zenym a dostupnou energi´ı. JABWT zpˇr´ıstupnuje ´ vypoˇ ´ cetn´ım vykonem ´ API jen k nˇekterym ´ technologi´ım celého Bluetooth stacku. Jsou to jmenovitˇe L2CAP, RFCOMM, SDP a OBEX. Podporován tak nen´ı napˇr. pˇrenos hlasu. ´ cely této práce se z JABWT vyuˇzuj´ı tyto cˇ a´ sti API: Pro uˇ • • •

vyhledáván´ı dostupnych ´ zaˇr´ızen´ı; vyhledáván´ı sluˇzeb zaˇr´ızen´ı; komunikace pˇres OBEX. 28

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ Pro pˇr´ıstup k Bluetooth pˇres JABWT API jsem zvolil knihovnu BlueCove 1 distribuovanou pod Apache Licence 2.0. Podporuje Bluetooth stacky v systémech Windows, Linux i MacOS. Pod Linuxem je potˇreba pouˇz´ıt ˚ nekompatibilitˇe licence se stackem nav´ıc knihovnu bluecove-gpl.jar kvuli BlueZ. 4.2.6

Spouˇstˇen´ı Java kodu ´ pˇres webové rozhran´ı

Java applety Java aplety doprováz´ı Javu od jej´ı prvn´ı verze. V dobˇe, kdy neexistoval ˚ ˚ Flash a jiné RIA technologie, pˇredstavovaly applety jeden z mála zpusob u, ´ jak vˇclenit do webu sloˇzitˇejˇs´ı cˇ a´ st kodu, která neˇsla psát v Javascriptu. O tuto pozici vˇsak vlivem nˇekolika faktoru˚ applety pˇriˇsly a s rozvojem RIA byly vytlaˇceny na okraj zájmu. V souˇcasné dobˇe se objevuj´ı jen zˇr´ıdka. ´ Applety mohou byt Nepodepsané se ´ spouˇstˇeny ve dvou modech. ˚ z bezpeˇcnostn´ıch duvod u˚ spouˇst´ı bez moˇznosti pˇr´ıstupu k poˇc´ıtaˇci. Pokud tato situace nevyhovuje, mus´ı doj´ıt k jejich podepsán´ı certifikaˇcn´ı autoritou. Pˇri vyvoji a podobnych ´ ´ situac´ıch existuje také moˇznost podepisovat applet svépomoc´ı bez certifikaˇcn´ı autority. Java Web Start ˇ Jedná se o framework, ktery´ umoˇznuje pˇr´ımé spouˇstˇen´ı Java aplikac´ı z webového prohl´ızˇ eˇce, aniˇz by se uˇzivatel musel starat o jejich stahován´ı a instalaci. Tento proces prob´ıhá transparentnˇe. Automaticky lze také stahovat bˇehové prostˇred´ı Javy, pokud nen´ı k dispozici nebo neodpov´ıdá poˇzadované verzi. Technologie se stala souˇca´ st´ı J2SE verze 1.4 pro 32bitové operaˇcn´ı systémy, u 64bitovych systému aˇz od verze 1.6. Vedle této ´ standardn´ı implementace od Sunu existuje nˇekolik dalˇs´ıch nezávislych. ´ Samotné spouˇstˇen´ı aplikace se popisuje pomoc´ı JNLP souboru. Jedná se o XML soubor s popisem um´ıstˇen´ı jar archivu, hlavn´ı spouˇstˇec´ı tˇr´ıdy, verze ˚ má spouˇstˇen´ı pˇres JNLP dvˇe hlavn´ı a dalˇs´ıch informac´ı. Oproti appletum vyhody: nepotˇrebujeme Java plugin do webového prohl´ızˇ eˇce a spouˇstˇet lze ´ ´ bˇezˇ nou aplikac´ı bez speciáln´ıch uprav. Nepodepsaná aplikace se chová podobnˇe jako applety – spust´ı se s omezenymi právy. I nepodepsaná vˇsak ´ ˚ ze m´ıt cˇ a´ steˇcny´ pˇr´ıstup k poˇc´ıtaˇci pomoc´ı API, které JNLP vystavuje. muˇ ˚ muˇ ˚ ze byt Jednou malou nevyhodou oproti appletum ´ ´ to, zˇ e se nespust´ı v oknˇe prohl´ızˇ eˇce, ale samostatnˇe. 1.

http://bluecove.org/index.html

29

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ

4.3

Návrh a implementace Bluetooth modulu

Pˇri otevˇren´ı stránky webové aplikace mus´ı doj´ıt ke spuˇstˇen´ı brány, která bude komunikovat s mobiln´ım zaˇr´ızen´ım. Ke komunikaci se pouˇz´ıvá protokol OBEX. Pomoc´ı pˇr´ısluˇsného API se nejprve vytvoˇr´ı SessionNotifier, ktery´ pˇredává události ke zpracován´ı instanci objektu ServerRequestHanˇ ezec, ktery´ se pouˇz´ıvá k popisu tohoto serveru má tvar bˇezˇ ného dler. Retˇ URI. V pˇr´ıpadˇe tohoto rámce se skládá z následuj´ıc´ıch cˇ a´ st´ı: •

Jméno pˇrenosového protokolu. Pro OBEX pˇrenásˇ eny´ po Bluetooth se pouˇz´ıvá zkratky btgoep (Bluetooth Generic Object Exchange Protocol).

•

Jméno stroje, na kterém server vzniká. V naˇsem pˇr´ıpadˇe se jedná o násˇ vlastn´ı poˇc´ıtaˇc, tedy localhost.

•

Identifikaˇcn´ı oznaˇcen´ı sluˇzby. Pro OMA DS je tato hodnota standardizována v dokumentu, ktery´ popisuje jeho mapován´ı na OBEX protokol.

Bluetooth synchronizaˇcn´ı brána se spouˇst´ı na adrese btgoep://localhost:000000010000100080000002EE000002. Obsluha událost´ı je implementována ve tˇr´ıdˇe SyncMLObexRequestHandler. V prototypu rámce jsem implementoval metody pro obsluhu tˇechto událost´ı: onPut Zpracován´ı dat odeslanych uˇzivatelem. Z objektu pˇredaného ob´ jektu Operation se nejprve z´ıskaj´ı hlaviˇcky zprávy a poté samotny´ obsah zprávy ze vstupn´ıho datového proudu. Data se odes´ılaj´ı dále pˇres HTTP synchornizaˇcn´ımu serveru a vysledek se ukládá pro situ´ aci, kdy uˇzivatel poˇzaduje odpovˇed’. Pˇr´ımo se vrac´ı pouze stavovy´ ´ V pˇr´ıpadˇe chyby hodnota OBEX HTTP BAD REQUEST, jinak kod. OBEX HTTP OK. onGet Obsluha události, kdy uˇzivatel poˇzaduje odpovˇed’ na zprávu zaslanou pˇres PUT operaci. Vytvárˇ ej´ı se nejprve hlaviˇcky odpovˇedi. ´ esˇ ného odeslán´ı se pˇres vystupn´ V pˇr´ıpadˇe jejich uspˇ ı proud vrac´ı i ´ ’ odpovˇed synchronizaˇcn´ıho modulu. Pokud tato odpovˇed’ nen´ı do´ se nastavuje na OBEX HTTP NO CONTENT, stupná, stavovy´ kod jinak OBEX HTTP OK. 30

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ onDelete Nezjistil jsem proˇc, ala nativn´ı synchronizaˇcn´ı klient v operaˇcn´ım systému Symbian Series 60 odes´ılal data i touto cestou. V této metodˇe se nepracuje s datovymi proudy a tak se ´ SyncML zpráva objevuje v jedné OBEX hlaviˇcce s nestandardn´ı identifikac´ı. Se zprávou vˇsak pracuji stejnˇe jako u PUT operace. Pˇredá se synchronizaˇcn´ımu modulu a odpovˇed’ se uloˇz´ı pro pozdˇejˇs´ı odeslán´ı klientovi pˇres GET poˇzadavek.

Testován´ı Bluetooth modulu Pro klientskou cˇ a´ st testován´ı Bluetooth modulu jsem pouˇzil, jak jsem zm´ınil v odstavci vyˇ ´ se, synchronizaˇcn´ıho klienta v operaˇcn´ım systemu Symbian Series 60. Ten je standardn´ı souˇca´ st´ı vybavy ´ telefonu a nen´ı nutné ho instalovat dodateˇcnˇe. Bˇezˇ nˇe se pouˇz´ıvá ke komuˇ nikaci se softwarovym data a ´ bal´ıkem Nokia PC Suite, ktery´ zpˇr´ıstupnuje obsluhu telefonu z poˇc´ıtaˇce. S daty telefonu se tedy nativnˇe pracuje pomoc´ı synchronizaˇcn´ıho protokolu OMA DS.

4.3.1

Integrace Bluetooth modulu do webové stránky

Pro zaˇclenˇen´ı Bluetooth modulu do webové stránky jsem pouˇzil Deployment Toolkit Script [22]. Je to Javascriptová knihovna k dospozici na oficiáln´ıch stránkach Javy pro spolehlivˇejˇs´ı práci s applety a JNLP pˇri ´ vkládán´ı do HTML kodu. Pouˇzit´ı vypadá následovnˇe: <script src="http://www.java.com/js/deployJava.js"> <script> var attributes = {codebase:’http://localhost/thesis’, code:’cz.muni.fi.xhomolka.sync.gui.swing.SyncGatewayApplet.class’, archive:’thesis-ui-swing.jar’, width:710, height:540} ; var parameters = {fontSize:16} ; var version = ’1.6’ ; deployJava.runApplet(attributes, parameters, ’1.6’); var url = "http://localhost/thesis/launch.jnlp"; deployJava.createWebStartLaunchButton(url, ’1.6.0’);

´ vloˇz´ı do webové stránky pˇr´ısluˇsny´ applet. Dále vytvoˇr´ı Tento kod tlaˇc´ıtko pro spouˇstˇec´ı aplikace pˇres Java Web Start. 31

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ

4.4

Návrh a implementace vzdáleného rozhran´ı

Vzdálené rozhran´ı je implementováno jako servlet v tˇr´ıdˇe SyncServlet, ktery´ pˇrij´ımá zprávy odeslané metou POST. Jako vystupn´ ı bod navrho´ vaného rámce slouˇz´ı i pro lokáln´ıho rozhran´ı tento servlet vzdáleného rozhran´ı. Pˇrenos zpráv do synchronizaˇcn´ıho serveru zajiˇst’uje samostatny´ modul. Ten se implementuje jako rozˇs´ırˇ en´ı vzdáleného rozhran´ı. Pro potˇreby této práce jsem vytvoˇrit napojen´ı synchronizaˇcn´ıho serveru Funambol. Na opaˇcnou stranu synchronizace jsem um´ıstil synchronizaˇcn´ı server Funambol. Stoj´ı za n´ım stejnojmenná firma, která je perfektn´ı ukázkou toho, ´ esˇ né muˇ ˚ ze byt jak uspˇ ´ podnikán´ı zaloˇzené na open-source modelu. Ko´ cely, munitn´ı verze jejich softwaru je volnˇe k dispozici i pro komerˇcn´ı uˇ pokud se jedná také o svobodny´ software. Jinak nab´ız´ı komerˇcn´ı verzi s rozˇs´ırˇ enymi funkcemi a podporou, která je vhodná i pro nasazen´ı do ´ prostˇred´ı s velkym ´ zat´ızˇ en´ım.

4.5

Poznámky k implementaci

4.5.1

Pˇrevod binarn´ıho XML

´ Pˇrevod z binárn´ıho na cˇ isté XML a zpˇet se jev´ı jako ideáln´ı ukol pro malou a ovˇerˇ enou knihovnu. Situace vˇsak tak ideáln´ı nen´ı. Existuje knihovna wbxml4j s posledn´ı verz´ı z roku 1991 a kXML2 naposledy aktualizovaná v roce 2005. Vyzkouˇsel jsem aˇz tu druhou jmenovanou. Jedná se o parser zaloˇzeny´ na XML Pull API 2 navrˇzeny´ hlavnˇe pro prostˇred´ı s omezenymi zdroji (napˇr. prostˇred´ı J2ME nebo applety). Práce s WBXML zde ´ pˇredstavuje bonusovou vlastnost nav´ıc a pˇri testován´ı jsem narazil na ˚ SyncML zprávy, které se nepodaˇrilo pˇrevést bez chyby nebo i vubec. Jak jsem zjistil pozdˇeji, open source synchronizaˇcn´ı server Funambol pouˇz´ıvá knihovnu kXML prvn´ı rˇ ady m´ısto této z rˇ ady druhé, avˇsak s cˇ etnymi ´ vlastn´ımi zmˇenami. Jejich verze uˇz fungovala dobˇre, ale vystup ve srovnán´ı ´ s nativn´ı knihovnou libwbxml neobsahoval deklarace typu SyncML. Do ´ ˚ kodu jsem tedy zaˇclenil pˇrevod obˇema zpusoby. Jako vychoz´ ı pouˇz´ıvám ´ pˇrevod nativn´ı knihovnou – volán´ım programu˚ wbxml2xml a xml2wbxml. 4.5.2

Práce s datovymi proudy ´

Na vˇetˇs´ım poˇctu m´ıst tohoto rámce se pracuje s datovymi proudy. Proto ´ jsem se rozhodl vyuˇz´ıt knihovnu Commons IO z rodiny Apache Com2.

http://xmlpull.org/

32

´ 4. I NTEGRACE SYNCHRONIZACE DAT DO WEBOV YCH APLIKACÍ ´ pro naˇc´ıtán´ı a zapisován´ı dat proudu˚ se zkracuje na nˇekolik mons. Kod ˚ nejnutnˇejˇs´ıch rˇ a´ dku: InputStream in = new URL("http://localhost").openStream(); try { InputStreamReader inR = new InputStreamReader(in); BufferedReader buf = new BufferedReader(inR); String line; while (( line = buf.readLine()) != null ) { System.out.println(line); } } finally { in.close(); }

´ s pouˇzit´ım tˇr´ıdy IOUtils. Stejny´ kod InputStream in = new URL("http://localhost").openStream(); try { System.out.println(IOUtils.toString(in)); } finally { IOUtils.closeQuietly(in); }

33

Kapitola 5

Závˇer C´ılem této práce bylo prozkoumat moˇznosti pˇrenosu dat mezi mobiln´ımi zaˇr´ızen´ımi a webovou aplikac´ı a následnˇe implementovat prototyp rámce, ktery´ by tento pˇrenos dat realizoval. V prvn´ı cˇ a´ sti jsem proto rozebral tuto problematiku obecnˇe. Nejprve jsem se vˇenoval vyhod´ am a nevyhod´ am, ´ ´ ˚ ych které pˇrinásˇ´ı synchronizace pro udrˇzován´ı v´ıce kopi´ı dat v ruzn ´ zaˇr´ızen´ıch, sluˇzbách a systémech. Dále jsem se zaj´ımal o moˇznosti pˇrenosu dat, kterymi dneˇsn´ı mobiln´ı zaˇr´ızen´ı disponuj´ı a mohly by pˇrispˇet k dosaˇzen´ı ´ c´ıle této práce. V prostˇredn´ı cˇ a´ sti se vˇenuji pˇredstaven´ı synchronizaˇcn´ıho protokolu OMA DS. Za dobu své existence se stal mezi otevˇrenymi protokoly de facto ´ standardem. Svou perspektivu dokazuje i d´ıky zastˇreˇsuj´ıc´ı organizaci Open Mobile Alliance, která se svymi v´ıce neˇz 150 cˇ leny zabezpeˇc´ı rozvoj a pod´ ˚ avá, jakym poru i do budoucna. Otázkou vˇsak zust´ ´ smˇerem se bude práce s daty ub´ırat. Rozmach cloud computingu se v nejbliˇzsˇ´ı dobˇe nezastav´ı. ˚ vyznam. ˚ ze I tak ale bude m´ıt synchronizace dat svuj Jej´ı podoba se vˇsak muˇ ´ zmˇenit. OMA DS je robustn´ı protokol pˇripraveny´ na velké mnoˇzstv´ı situac´ı. V posledn´ı cˇ a´ sti se zabyv´ návrhem a implementac´ı proto´ am analyzou, ´ typu rámce, ktery´ by umoˇznil integraci synchronizace dat mobiln´ıch zaˇr´ızen´ı do webové aplikace. Tento prototyp se mi podaˇrilo vytvoˇrit a pouˇz´ıt k synchronizaci dat telefonu, a to jak pˇres lokáln´ı Bluetooth rozhran´ı, tak pˇres vzdálené rozhran´ı realizované jako HTTP servlet. Rámec je pˇr´ıpraveny´ k rozˇsiˇrován´ı o dalˇs´ı synchronizaˇcn´ı moduly a nen´ı vázany´ pouze na aktuálnˇe pouˇzity´ server Funambol. Pokud by se uvaˇzovalo o rozvoji tohoto rámce a jeho moˇzném nasazen´ı, muselo by tomu pˇredcházet rozsáhlejˇs´ı tes˚ ymi ˚ V pˇr´ıpadˇe dalˇs´ıho vyvoje tován´ı s ruzn typy synchronizaˇcn´ıch klientu. ´ ´ mˇe napadaj´ı dvˇe vlastnosti, které by vyznamnˇ e pˇrispˇely k pouˇzitelnosti ´ rámce. Tou prvn´ı je implementace synchronizace zahájené serverem (Server Alerted Notification). Ta by pak mohla probˇehnout, aniˇz by uˇzivatel spouˇstˇel jakékoli akce na mobiln´ım zaˇr´ızen´ı. Druhou vlastnost´ı je sofistikovanˇejˇs´ı integrace do webové aplikace vhodná pro koncové uˇzivatele.

34

Literatura [1] Thompson, Timothy J. - Kumar, C Bala - Kline, Paul J.: Bluetooth Application Programming with the Java APIs. Morgan Kaufmann, 2008. 304 s. ISBN 978-0-12-374342-8 [2] Joshua Bloch: Effective Java 2nd ed. Upper Saddle River, N.J.: AddisonWesley, 2008. xxi, 346 s. ISBN 978-0-321-35668 [3] Hansmann, Uwe - Mettälä, Riku - Purakayastha, Apratim - Peter, R Synchronizing and Managing Thompson - Phillipe, Kahn: SyncML : Your Mobile Data. 1st edition. Pearson Education, 2002. 320 s. ISBN 978-0-13-009369-1 [4] SyncML White Paper http://www.openmobilealliance.org/ tech/affiliates/syncml/syncml_whitepaper.html [5] Specifikace OMA DS 1.1.2 http://www.openmobilealliance. org/Technical/release_program/ds_v112.aspx [6] Specifikace OMA DS 1.2.2 http://www.openmobilealliance. org/Technical/release_program/ds_v1_2_2.aspx [7] OMA vObject Minimum Interoperability Profile http://www. openmobilealliance.org/Technical/release_program/ vObject_v1_0.aspx [8] Bluetooth Wireless Technology Profiles http://www.bluetooth. com/English/Technology/Works/Pages/Profiles_ Overview.aspx [9] IrMC http://www.traud.de/gsm/IrMC.htm [10] IrDA Library of Specifications and Technical Papershttp://www. irda.org/displaycommon.cfm?an=1\&subarticlenbr=7 [11] Wikipedia – Infrared Data Association http://en.wikipedia. org/wiki/Infrared_Data_Association 35

´ Eˇ R 5. Z AV [12] HotSync tajemstv´ı zbaveny, ´ d´ıl I. a II. http://www.svethardware. cz/art_doc-718AE99E77D4B080C12573C50031E014.html [13] Palm WebOS Sync software/sync.html

http://www.palm.com/us/products/

[14] Exchange ActiveSync Protocol http://www.microsoft.com/ about/legal/en/us/IntellectualProperty/IPLicensing/ Programs/ExchangeActiveSyncProtocol.aspx [15] Mobile Web http://en.wikipedia.org/wiki/Mobile_Web [16] Wikipedia Bluetooth

–

Bluetooth

http://en.wikipedia.org/wiki/

[17] BlueTomorrow – Bluetooth Versions http://www. bluetomorrow.com/about-bluetooth-technology/ general-bluetooth-information/bluetooth-versions. html [18] The Internet Protocol Journal, Volume 11, No. 4 – Wi-Fi, Bluetooth and WiMAX http://www.cisco.com/web/about/ac123/ ac147/archived_issues/ipj_11-4/114_wifi.html [19] Wikipedia – Bluetooth Protocols http://en.wikipedia.org/ wiki/Bluetooth_protocols [20] Wikipedia – Java Web Start http://en.wikipedia.org/wiki/ Java_web_start [21] JSR80 API Specification http://javax-usb.org/jsr80.pdf [22] Java Rich Internet Applications Deployment Advice http: //download.oracle.com/javase/6/docs/technotes/ guides/jweb/deployment_advice.html

36

Dodatek A

Obsah CD Obsah pˇriloˇzeného CD: •

´ zdrojové kody rámce;

•

specifikace protokolu˚ OMA DS 1.1.2 a 1.2.2;

•

záznam zpráv synchronizace kontaktu˚ pˇres lokáln´ı Bluetooth rozhran´ı;

•

text diplomové práce.

37

012345

Recommend Documents