PUSH TECHNOLÓGIA AKO PROSTRIEDOK NOTIFIKÁCIE A SYNCHRONIZÁCIE MOBILNÝCH KLIENTOV V REÁLNOM ČASE

Transcription

1 Slovenská technická univerzita v Bratislave Fakulta informatiky a informačných technológií FIIT Bc. Slavomír Žiak PUSH TECHNOLÓGIA AKO PROSTRIEDOK NOTIFIKÁCIE A SYNCHRONIZÁCIE MOBILNÝCH KLIENTOV V REÁLNOM ČASE Diplomová práca Študijný program: Počítačové a komunikačné systémy a siete Študijný odbor: Počítačové inžinierstvo Miesto vypracovania: Ústav počítačových systémov a sietí, FIIT STU Bratislava Vedúci práce: Ing. Peter Vilhan máj 2011

2 I. ANOTÁCIA Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: Počítačové a komunikačné systémy a siete Autor: Bc. Slavomír Žiak Diplomový projekt: Push technológia ako prostriedok notifikácie a synchronizácie mobilných klientov v reálnom čase Vedenie diplomového projektu: Ing. Peter Vilhan máj, 2011 V tejto práci sa venujeme problematike ako môžu byť mobilné zariadenia lepšie využité v náš prospech a ako môžu naše životy spraviť efektívnejšími. Model PUSH ako spôsob prístupu k dátam sa v súvislosti s mobilnými zariadeniami používa už dlhú dobu a vzniklo pomerne veľké množstvo rôznych technológií ako tento model implementovať. Vybrali a popísali sme tri protokoly WAP, SyncML a ActiveSync a tri formáty v akých sa dáta prenášajú XML, JSON a WBXML.. Ďalej opisujeme implementácie protokolu ActiveSync na báze OpenSource Z-Push spoločnosti Zarafa a O-Push spoločnosti OBM a predstavujeme návrh rozšírenia systému O-Push. V práci pokračujeme jeho implementovaním a testovaním vplyvu push technológie na výdrž batérie a objem prenesených dát mobilných zariadení. II

3 II. ANNOTATION Slovak University of Technology Bratislava FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES Degree Course: COMPUTER AND COMMUNICATION SYSTEMS AND NETWORKS Author: Bc. Slavomír Žiak Diploma project: Push technology as means of real-time notification and synchronization of mobile clients Supervisor: Ing. Peter Vilhan May, 2010 In this paper we address the issue of how can mobile devices be better used for our needs and how can they make our lives more efficient. PUSH model as a means of accessing the data is in conjunction with mobile devices used a long time and there is a fairly big amount of different technologies that implements this model. We chose and described three protocols WAP, SyncML and ActiveSync and three formats for transmitting the data XML, JSON a WBXML. Next, we describe implementations of the ActiveSync protocol based on opened source - Z-Push of Zarafa company and O-Push of OBM company and present extension of the O-Push. We conclude the work on with its implementation and testing the impact of push technology on mobile devices battery life and amount of data needed to transfer messages. III

4 III. Obsah I. ANOTÁCIA... II II. III. IV. ANNOTATION... III Obsah... IV Slovník cudzích slov... VII V. Zoznam skratiek... VIII VI. VII. Zoznam obrázkov... IX Zoznam tabuliek... X 1 Úvod Porovnanie PUSH a PULL modelov Aplikácie PUSH modelu v mobilných zariadeniach Ciele Cieľová skupina používateľov Cieľová množina prenášaných dát Push - technická realizácia Protokol Http [14] HTTP PULL Http streaming Service streaming AJAX Formáty prenášaných dát XML[22] JavaScript Object Notation [7] WBXML - WAP binárne XML Push protokoly WAP - Wireless Application Protocol IV

5 5.1.1 WAP Push[19] WAP SyncML ActiveSync Súčasti protokolu Transportný formát WBXML ActiveSync príkazy a dáta Parameter SyncKey AutoDiscover FolderCreate FolderDelete FolderSync FolderUpdate GetAttachment GetItemEstimate ItemOperations MeetingResponse MoveItems Ping Provision ResolveRecipients Search SendMail Settings SmartForward SmartReplay Sync V

6 ValidateCert ActiveSync klientske aplikácie Aplikácia ActiveSync [30] Windows Mobile Device Center [31] Bezpečnosť Implementácie ActiveSync protokolu Komerčné implementácie ExchangeServer Scalix OpenSource implementácie Zarafa Z-Push Inštalácia a konfigurácia systému O-Push Návrh riešenia - rozšírenie projektu OPush Postup návrhu rozšírenia Oboznámenie sa s protokolom ActiveSync Oboznámenie so systémom OPush Architektúra Databáza a dátový model Hlavné triedy a rozhrania IBackend ISyncStorage Rozšíriteľnosť a modulárnosť Model správania Navrhované zmeny v projekte OPush Implementácia rozšírenia systému OPush Implementácia MultiBackend-u VI

7 8.2 Zmeny v databázovom modeli Implementácia riešenia na strane klienta Webová aplikácia RegisterAccount Testovanie riešenia Príprava testovania Nastavenie klienta Testovanie Test pripojenia na OPush server Test synchronizácie dát Test odoslania, preposlania a odpovedania na z mobilného zariadenia Test push notifikácie na mobilné zariadenie Test presunutia správy v rámci konta a medzi kontami Prínos riešenia a jeho overenie Porovnanie PUSH a PULL v reálnom nasadení Záver Ďalšia práca Referencie Príloha A: Fyzický dátový model OPush Príloha B: Používateľská príručka aplikácie RegisterAccount Príloha C: Nastavenie mobilného klienta TouchDown Príloha D: Obsah elektronického média IV. Slovník cudzích slov Cudzí výraz web Preklad a vysvetlenie kontextu k tejto práci sieť, alebo skrátený výraz pre počítačovú sieť Internet VII

8 namespace backend tag framework peer-to-peer , electronic mail groupware, collaboration software OpenSource plugin priestor názvov, používa sa na vyčlenenie domény v ktorej sa používajú isté názvy, mená pre objekty synonymum pre databázu značka Súbor znalostí, knižníc a nástrojov na vývoj softvéru v určitej oblasti. Architektúra, kde sú všetci účastníci (počítače) rovnocenné. elektronická pošta, výraz referuje na prenášanie správ počítačovou sieťou, ktorým sa hovorí analogicky k papierovej pošte Spoločné pomenovanie počítačových programov, ktoré majú za úlohu sprostredkovať spoluprácu medzi ľuďmi, väčšinou elektronickou poštou, správami, zadávaním úloh a priestorom na dohodnutie si stretnutí Pojem referuje počítačové programy a systémy s voľne šíriteľnými zdrojovými kódmi, ktoré je možné slobodne a bezplatne modifikovať a rozširovať. Zásuvný modul počítačového programu V. Zoznam skratiek Skratka XHR DTD WAP HTTP REST AJAX Význam Xml http Request Document type definition Wireless Application protocol Hyper-text transfer protocol Representational state transfer Asynchronous JavaScript and XML VIII

9 API AS Application programming interface ActiveSync VI. Zoznam obrázkov Obrázok 1 Znázornenie PUSH a PULL modelu, * Obrázok 2 Základná architektúra webu, * Obrázok 3 WAP Push, * Obrázok 4 SyncML architektúra, * Obrázok 5 Priebeh vyhľadávania v protokole ActiveSync [32] Obrázok 6 Spracovanie synchronizácie na klientskej strane [32] Obrázok 7 Z-Push architektúra, * Obrázok 8 Znázornenie rozšírenia systému OPush Obrázok 9 Architektúra OPush systému Obrázok 10 Dátový model OPush Obrázok 11 Spracovanie požiadavky ActiveSync Obrázok 12 Spracovanie operácie metódou processactivesyncmethod Obrázok 13 Class diagram najdôležitejších tried OPush Obrázok 14 Ukážka aplikácie RegisterAccount Obrázok 15 Klient RoadSync ( 48 Obrázok 16 Klient TouchDown ( 48 Obrázok 17 Záznam odchytenej komunikácie OPush servera a mobilného zariadenia Obrázok 18 Ukážka komunikácie pri synchronizácií dát Obrázok 19 Ukážka komunikácie pri odoslaní, odpovedaní a preposielaní u Obrázok 20 Priebeh testovania IMAP pull Obrázok 21 Priebeh testovania ActiveSync push Obrázok 22 Vývoj napätia batérie pri IMAP pull IX

10 Obrázok 23 Vývoj napätia batérie pri ActiveSync push Obrázok 24 Úvodná stránka Obrázok 25 Registrácia OPush konta Obrázok 26 Menu pre prácu s externými kontami Obrázok 27 Zobrazenie externých kont Obrázok 28 Pridanie nového externého konta Obrázok 29 Nastavenie pripojenia na server Obrázok 30 Adresáre vybraté na synchronizáciu Obrázok 31 Zoznam adresárov z oboch testovacích kont VII. Zoznam tabuliek Tabuľka 1 Ukážka XML dokumentu... 8 Tabuľka 2 Ukážka JSON dokumentu... 8 Tabuľka 3 Protokolový zásobník WAP Tabuľka 4 ActiveSync protokoly Tabuľka 5 Preklad obrázka Obrázok Tabuľka 6 Body rozšírenia projektu OPush Tabuľka 7 implementácie a rozšírenie bodov rozšírení Tabuľka 8 Implementované triedy Tabuľka 9 Zoznam upravených tried projektu OPush Tabuľka 10 Popis tabuľky OPUSH_EXTERNAL_ACCOUNT Tabuľka 11 Obsah tabuľky opush_external_account Tabuľka 12 Základné údaje z tabuľky UserObm Tabuľka 13 Základné údaje z tabuľky Domain Tabuľka 14 Vybrané záznamy z logov OPush servera - synchronizácia Tabuľka 15 Vybrané záznamy z logov OPush servera - SendMail, SmartReplay a SmartForward Tabuľka 16 Vybrané záznamy z logov OPush servera - Ping X

11 Tabuľka 17 Vybrané záznamy z logov OPush servera - MoveItems Tabuľka 18 Výsledky testovania Tabuľka 19 Slovník k fyzickému modelu Tabuľka 20 Fyzický model OPush XI

12 1 Úvod Organizácia času, práce, komunikácia, výmena informácií, toto všetko v reálnom čase, nezávisle od miesta kde sa práve nachádzate. Nie je to žiadna fikcia, ale každodenná realita mnohých ľudí. Taký je moderný svet, svet informácií, technológií a úspechu založenom na tom, ako rýchlo sa k Vám informácie dostanú. Mobilné zariadenia ako telefóny, organizéry, vreckové, alebo mobilné počítače priniesli do našej spoločnosti, spolu s celosvetovou počítačovou sieťou internet, informačnú revolúciu. V dobe, keď sa technológie a informatika spolu využívajú na zefektívnenie života viac ako kedykoľvek v histórií, je rozhodujúce akým spôsobom sa k informácie dostávajú. Jeden pohľad na tento problém spočíva v tom, že existujú len dva spôsoby ako sa dostať k informáciám: môžeme si ich vyhľadať sami, alebo nám ich niekto ponúkne. Bežný príklad zo života je čítanie novín[2]: Ak chceme čítať noviny, môžeme si ich ísť kúpiť, alebo si ich preplatíme a budú nám doručené priamo do schránky. Tie dva spôsoby sú vlastne dve paradigmy a to push a pull, z anglických slov: tlačiť a ťahať. Analógií týchto protichodných prístupov je viacero, no spoločné majú to hlavné: vykonanie používateľom iniciovanej akcie(kúpenie novín), po ktorej vykonaní sú informácie(správy v novinách) k dispozícií - pull, alebo naopak, keď sú informácie k dispozícii(v schránke), vykoná sa používateľom definovaná akcia(prečítanie novín) - push. 1

13 2 Porovnanie PUSH a PULL modelov PUSH aj PULL modely sú spôsoby prístupu k dátam. V oboch prípadoch uvažujeme klientserver architektúru. Dnes veľa aplikácií, ktoré sledujú udalosti v reálnom čas(ekonomické, burzové a iné správy), využíva PULL podel na aktualizovanie svojho obsahu. Klientská aplikácia v pravidelných intervaloch posiela požiadavky na server, či sú k dispozícii nové dáta. Keď porovnáme tento model s PUSH modelom, zistíme rozdiel v spôsobe komunikácie. Pri PUSH modeli sa klient prihlási na odber dát, alebo notifikácií a vždy, keď sú tieto k dispozícii, pošle ich server asynchrónne priamo klientskej aplikácii [1]. Obrázok 1 Znázornenie PUSH a PULL modelu, [19] 3 Aplikácie PUSH modelu v mobilných zariadeniach Mobilné zariadenia sú charakteristické rôznymi vlastnosťami, medzi inými aj limitovaný prísun elektrickej energie, majú batérie, ktorých výdrž závisí aj do použitia mobilného zariadenia. Špeciálne v mobilných zariadenia je preto vhodné použiť PUSH model, keďže zariadenia nespotrebúva energiu neustálym dopytovaním sa na server, či sú k dispozícii nové dáta. PUSH model má využitie v rôznych aplikáciách na mobilných zariadeniach: príjem elektronickej pošty, sledovanie rýchlo sa meniacich dát (stav zásob na skade, online aukcie, dopravné informácie a iné). 2

14 3.1 Ciele Ciele použitie PUSH modelu v mobilných zariadeniach sú: 1. okamžité doručenie dát (správy, alebo dokumentu) koncovému užívateľovi 2. automatická synchronizácia rôzneho druhu dát Synchronizácia je proces, ktorým sa v cieľovom zariadení dosiahne rovnaký stav ako v zdrojovom. V tomto procese je nutné identifikovať, ktoré dáta je nutné skopírovať do cieľového zariadenia. Môže ísť o nové kontakty, nové položky v kalendári, alebo vo všeobecnosti každý súbor dát zmenený od času poslednej úspešnej synchronizácie. Dáta sa spravidla prenášajú medzi obslužnou aplikáciou (server) a klientským zariadením (osobný počítač, organizér, telefón), oboma smermi. 3.2 Cieľová skupina používateľov Je dôležité poznať ako sa správajú používatelia služieb, ktoré ponúka PUSH model, ide hlavne o čas a dobu, ktorú sú pripojený k hlavnej synchronizačnej aplikácií (serveru). Z toho hľadiska môžeme používateľov rozdeliť na [3]: 1. statický nachádzajúci sa vždy na jednom mieste, väčšinu času pripojení 2. niekedy menia polohu, väčšinu času pripojení 3. mobilný - stále v pohybe, väčšinu času nepripojení Z tohto pohľadu na používateľov je PUSH model vhodnejší pre tretiu kategóriu, PUSH model im dovoľuje nebyť neustále pripojení, zariadenie sa pripojí k sieti len keď sú preň pripravené dáta. 3.3 Cieľová množina prenášaných dát Na každodennú prácu a uľahčenie niektorých činností, je vhodné, aby boli s mobilným zariadením používateľa synchronizované nasledovné dáta: a. kontakty (informácie o osobe, spoločnosti), b. položky v kalendári: stretnutia, pripomienky, c. úlohy, d. dokumenty (DOC,PPT,XLS,PDF), e. správy ( , skupinové diskusie), 3

15 f. internetové záložky, g. informácie o stave a predpovedi počasia, h. informácie o dopravnej situácií (zápchy na cestách, zablokované ulice, obchádzky). 4

16 4 Push - technická realizácia V tejto kapitole sa venujeme špecifikáciám PUSH protokolov, ktorými zariadenia komunikujú a formátom dát, ktoré sú prenášané medzi zariadeniami. 4.1 Protokol Http [14] HTTP je protokol prevažne určený na prenos odkazmi poprepájaných dokumentov z jednej internetovej lokality na inú. Spravidla zo servera na ktorom je spustená HTTP aplikácia, na klientský počítač, kde si tento dokument môžeme prezrieť, alebo uložiť. Protokol HTTP umožnil vzniku webu ako ho poznáme a používame dnes. Podľa architektúry HTTP a REST [23] všetky akcie medzi klientom a serverom sú iniciované od klienta. Jedným z dôvodov prečo je tomu tak je, že HTTP je bezstavový protokol. Server si neuchováva žiadne informácie o klientoch a medzi klientom a serverom nie je vytvorené žiadne permanentné spojenie. Žiadna interakcia nezávisí od predchádzajúcich, čiže nie je možné vytvoriť PUSH notifikácie, ktoré by boli posielané priamo klientom. Implementovanie push modelu striktne pomocou REST technológie nie je možné, pretože každá odpoveď servera musí predchádzať požiadavke zo strany klienta. Existuje ale niekoľko techník, ktorými sa dá k push modelu veľmi priblížiť. Tieto techniky opíšeme v nasledujúcich podkapitolách. Základný princíp akým pracuje väčšina dnešných webových aplikácií je znázornený na obrázku Obrázok 2 Základná architektúra webu, [20], ide o klient-server architektúru. Obrázok 2 Základná architektúra webu, [20] HTTP PULL Technika, kedy webová aplikácia v pravidelných intervaloch posiela požiadavky na aktualizáciu dát. Interval posielania požiadaviek sa nazýva Time to refresh (TTR). Je dôležité dobre nastaviť hodnotu TTR, aby nedochádzalo k zbytočnému zaťaženiu linky, ale zároveň aby boli nové 5

17 dáta doručené včas. Ideálne by hodnota TTR mala byť na úrovni frekvencie pribúdania dát, čiže Publish Rate (PR). Je to často používaná technológia, pretože je ľahko implementovateľná a dobre škálovateľná pre množstvo používateľov. Jedno dôležité rozšírenie HTTP PULL-u tvorí adaptívne TTR, kedy server môže zmeniť TTR klientovi na základe frekvencie PR. Adaptívne TTR vykazuje lepšie výsledky ako statické TTR, napriek tomu dochádza k zbytočným požiadavkám na server a dodanie správy nie je okamžité, ale vždy s istým oneskorením Http streaming Jedná sa o staršiu technológiu, predstavenú spoločnosťou Netscape v roku 1992 pod názvom dynamic document - dynamický dokument. Väčšina serverov pri odpovedi len spracuje požiadavku, získa dáta, tieto dáta pošle a spojenie uzatvorí. Pri http streaming-u sa spojenie neuzatvára, nechá sa otvorené a server čaká na ďalšie dáta, ktoré okamžite posiela klientovi. Klient sa akurát musí postarať o zobrazenie dát, keď ich dostane Service streaming Service streaming je závislé na XmlHttpRequest [24] (XHR) objekte. Podobne ako pri HTTP streaming-u sa udržiava so serverom dlhotrvajúce spojenie, no tento krát je to XHR objekt, ktorý je so serverom spojený a čaká na nové dáta. Takéto riešenie prináša istú flexibilitu v dĺžke spojenia a množstve spojení. Iniciálna stránka sa načíta celá a potom sa robí už len aktualizácia jej obsahu dátami, ktoré dostal XHR objekt a to po preddefinovaný čas živa spojenia. 4.2 AJAX AJAX je web technológia, ktorá umožňuje vytvárať interaktívnejšie aplikácie, znižuje oneskorenie aplikácie spôsobené načítaním celých stránok. Keď sú nejaké dáta, o ktoré má požívateľ záujem, môžu byť poslané hneď k nemu. AJAX je prístup k vytváraniu webových aplikácií, použitím existujúcich technológií: XHTML[25], CSS[26] a dynamický a interaktívne založený Document Object Model [4], výmena a manipulácia s dátami pomocou XHR objektu a celé to spája JavaScript. Mnoho moderných internetových prezeračov implementujú XHR objekt, ktorá umožňuje na pozadí web aplikácie vytvoriť nezávislé spojenie s webovým serverom na prenos dát. Nevyužíva request-response model ako iné klasické aplikácie. 6

18 4.3 Formáty prenášaných dát V tejto kapitole sa venujeme rôznym formátom dát. Dva z nich, XML a WBXML sa používajú v PUSH protokoloch, ktorým sa venujeme v kapitole Push protokoly. Formát JSON uvádzame pre jeho súčasnú populárnosť, je využívaný v mnohých AJAX aplikáciách, webových službách a má podporu v mnohých programovacích jazykoch a knižniciach XML[22] XML Extensible Markup Language, je textový formát na definovanie štruktúry a obsahu dát. Je vhodný na rozšírenie a dnes existuje mnoho jazykov založených na XML. Niektoré vlastnosti jazyka XML: stromová štruktúra podpora priestorov názvov (XML Namespace) validácie cez DTD, alebo XSD transformácie a šablónovanie cez XSLT, adresovanie pomocou Xpath človekom čitateľný Jazyk XML vznikol ako podmnožina SGML. XML dokument je definovaný ako reťazec Unicode znakov[9], čo ho robí ideálnym pre internacionálne použitie. Znaky v dokumente sa dajú rozdeliť na značkovacie a obsahové. Keďže ide o značkovací jazyk, značky, alebo tagy sa definujú do lomených zátvoriek(<, >), poznáme otváracie a zatváracie tagy. Základný stavebný kameň XML je element. Element začína začiatočným, a končí koncovým tagom, alebo obsahuje len jeden prázdny tag. Elementy obsahujú atribúty, ktoré predstavujú páry názov = hodnota. V tabuľke Tabuľka 1 Ukážka XML dokumentu sú popísané príklady tagov, elementov aj atribútov. Atribúty sa môžu nachádzať len v začiatočných, alebo v prázdnych tagoch. <menu id="file" value="file"> <popup> <menuitem value="new" onclick="createnewdoc()" /> <menuitem value="open" onclick="opendoc()" /> <menuitem value="close" onclick="closedoc()" /> </popup> <popup /> 7

19 </menu> Tabuľka 1 Ukážka XML dokumentu JavaScript Object Notation [7] JavaScript Object Notation (JSON) je jednoduchý, textovo orientovaný, jazykovo nezávislý formát na prenos dát. Bol odvodený zo zápisov objektovej štruktúry jazyka JavaScript, štandardu programovacieho jazyka ECMAScript[8]. JSON definuje malú skupinu pravidiel pre prenosnú definíciu štruktúrovaných dát. Tabuľka 2 Ukážka JSON dokumentu obsahuje ukážku JSON dokumentu. Pre porovnanie s jazykom XML, obsahuje táto ukážka ten istý dokument ako je v tabuľke Tabuľka 1 Ukážka XML dokumentu, iba zapísaný v jazyku JSON. JSON dokáže reprezentovať štyri primitívne typy: reťazce, čísla, boolovské (true-false) hodnoty a NULL, a dva štruktúrované typy: objekt a pole. Výhoda tohto jazyka je, že reťazec môže obsahovať Unicode znaky [9], čo umožňuje prenášať text v akomkoľvek svetovom jazyku Objekt je kolekcia párov meno - hodnota, kde meno je reťazec a hodnota môže byť: reťazec, číslo, BOOLEAN, NULL, objekt, alebo pole. Pole je sekvencia hodnôt. Termíny "objekt" a "pole" sú prevzaté z jazyka JavaScript. Dizajnové požiadavky na JSON boli: minimálnosť, prenosnosť medzi jazykmi a platformami, textovú reprezentáciu, a aby bol podmnožina JavaScript-u. {"menu": { "id": "file", "value": "File", "popup": { "menuitem": [ {"value": "New", "onclick": "CreateNewDoc()"}, {"value": "Open", "onclick": "OpenDoc()"}, {"value": "Close", "onclick": "CloseDoc()"} ] } }} Tabuľka 2 Ukážka JSON dokumentu Dnes už mnohé spoločnosti, napríklad Google, alebo Yahoo! podporujú formát JSON v ich webových službách. [10][11] 8

20 4.3.3 WBXML - WAP binárne XML WAP, čiže Wireless application protocol [5], je protokol definovaný WAP fórom špeciálne pre aplikácie a zariadenia komunikujúce bezdrôtovo. Pre účel tohto protokolu bol definovaný aj formát prenášaných dát, a to WAP binárne XML, alebo skrátene WBXML[6]. WBXML je kompaktná binárna reprezentácia XML jazyka. Tento formát je dizajnovaný, aby redukoval prenášanú veľkosť XML dokumentov, umožňujúc tak väčšiu efektivitu XML formátu v použití v úzkych komunikačných kanáloch. XML dokumenty sú do WBXML transformované s nulovou stratou funkcionality, alebo sémantických informácií, zachováva štruktúru elementov v XML, čo umožňuje preskočiť pri spracovaní WBXML elementy a atribúty, ktoré nie sú pre spracovateľa známe. Do binárnej podoby sa transformuje fyzická forma XML dokumentu, čiže štruktúra a obsah XML entít. Meta-informácie, ako DTD a voliteľné časti XML dokumentu, sú pri konverzií do binárnej podoby odstránené. 9

21 5 Push protokoly Aj keď sa PUSH model dá technicky implementovať výlučne nad HTTP protokolom, rozvíjajúcemu sa webu ale samotné HTTP nestačí. Bolo nutné definovať protokol špecifický práve pre túto doménu. Špeciálne sa PUSH protokoly vyvíjajú pre mobilné, tieto sú potom aplikovateľné aj na statické zariadenia. Týchto protokolov je momentálne už značné množstvo, uvádzame však len tri, ktoré pokladáme za jedny z najznámejších a zároveň nasadených a odskúšaných: WAP[18], definovaný spoločnosťou Open Mobile Alliance, SyncML, značkovací jazyk založený na XML formáte a ActiveSync ako proprietárny formát spoločnosti Microsoft. 5.1 WAP - Wireless Application Protocol WAP protokol bol vyvinutý na prepojenie klasického webu v ktorom sa podieľajú statické zariadenia, so svetom mobilných zariadení. WAP je spojením sieťových technológií, bezdrôtového prenosu dát, telefónie a internetu. Tvorí ho celá protokolová sada. WAP ponúka všetky služby štandardných webových prehliadačov, iba prispôsobené na podmienky mobilných zariadení, ako mala zobrazovacia plocha, úzke prenosové pásmo, menší procesorový výkon, menej pamäte, alebo rôzne vstupné zariadenia (klávesnica telefónu) [20]. Ako transportný formát používa WAP WBXML (viď kapitolu WBXML - WAP binárne XML). Vo verzií 1.0 vydaný v roku 1999, obsahoval niekoľko protokolov zaradených do vrstiev, ako je znázornené na nasledujúcej tabuľke. Wireless Application Environment (WAE) Wireless Session Protocol (WSP) Wireless Transaction Protocol (WTP) Wireless Transport Layer Security (WTLS) Wireless Datagram Protocol (WDP) Tabuľka 3 Protokolový zásobník WAP Na spodku protokolového zásobníka sa nachádza protokol WDP, ktorý slúži na transparentný prenos datagramov pre vyššie vrstvy. Ide o prenos bez potvrdenia a bez spojenia, vlastne presná kópia protokolu UDP(User datagram protocol). Nad WDP sa nachádza WTLS, ktorý pridáva podporu 10

22 vyššej bezpečnosti pomocou PKI, podobne ako protokol TLS, je to voliteľná vrstva. Nad WTLS sa nachádza WTP, protokol zaisťujúci potvrdený, transakčný prenos dát, prispôsobený na podmienky bezdrôtového prenosu. Jeho výhoda oproti TCP(Transmission control protocol) protokolu je v reagovaní na stratu paketov v bezdrôtovom prostredí a v 2G sieťach, ktorú by TCP vyhodnotilo ako zahltenie. Nad WTP sa na nachádza protokol WSP, ktorý sa dá pokladať za zjednodušené HTTP. Ďalej máme protokol WAE, ktorý predstavuje aplikačné značkovacie jazyky. Pre WAP 1.X je to WML - Wireless Markup Language [27] WAP Push[19] V roku 2000 bola vydaná verzia 1.2 s funkcionalitou WAP push. PUSH bol pridaný do protokolu WAP za účelom posielania dát zo servera na mobilné zariadenia s minimálnym zásahom používateľa. Sieťový komponent, ktorý posiela WAP Push správy sa nazýva Push Proxy Gateway (PPG). PPG ale neposiela celý obsah, len odkaz, pomocou ktorého môže používateľ daný obsah získať. Na obrázku Obrázok 3 WAP Push, [19] je zobrazená schéma WAP Push: medzi klientom a PPG prebieha komunikácia Push over-the-air protokolom a medzi PPG a iniciátorom PUSH notifikácie Push Access Protokolom (PAP). Obrázok 3 WAP Push, [19] WAP 2.0 V roku 2002 bola vydaná verzia 2.0. Zmeny v špecifikácii predstavujú: namiesto WML sa používa podmnožina jazyka XHTML - XHTML Mobile Profile a verziu kaskádových štýlov CSS. 11

23 5.2 SyncML SyncML je špecifikácia pre dátový synchronizačný framework, formát založený na XML, alebo protokol na synchronizáciu dát medzi sieťovými zariadeniami. SyncML je dizajnovaný aj na použitie priamo medzi zariadeniami (peer-to-peer, bez prítomnosti synchronizačného servera) a špeciálne pre prípady, kedy zaradenia zdieľajú a synchronizujú dáta v rôznych formátoch, alebo používajú rôzne softvérové systémy [21]. Cieľom SyncML je ponúknuť otvorený štandard ako náhradu za existujúce synchronizačné riešenia, ktoré sú väčšinou závislé na dodávateľovi, aplikácií, alebo operačnom systéme. SyncML má širokú podporu u výrobcov mobilných zariadení ako aj mnoho implementácií klient a server aplikácií. Obrázok 4 SyncML architektúra, [21] Aplikácia A poskytuje synchronizačnú službu a v tomto prípade má prebehnúť synchronizácia s aplikáciou B. A má synchronizačný protokol implementovaný ako Sync Engine. Sync Server Agent spravuje prístup Sync Engine do siete a komunikuje operácie dátovej synchronizácie z a do klientskych aplikácií. Sync Server Agent vykonáva tieto operácie pomocou rozhranie SyncML I/F, ktoré je aplikačným programovým rozhraním (API) pre SyncML Adapter. SyncML Adapter je konceptuálny proces, pomocou ktorého komunikujú odosielateľ a adresát SyncML správ. SyncML Adapter je zároveň entita framework-u, ktorá je na rozhraní s transportnou vrstvou a spravuje spojenie medzi aplikáciou A a B. Aplikácia B používa Sync Client Agent na prístup do siete a k SyncML Adapter, pomocou rozhrania SyncML I/F. [21] 12

24 Komunikácia v rámci SyncML pozostáva zo správ v XML formáte (XML formát viď kapitolu XML). SyncML má svoj vlastný MIME typ [28]. Všeobecne MIME umožňuje rozlišovať medzi rôznymi druhmi dokumentov, ktoré majú jednotné označenie v celej sieti internet. SyncML podporuje dátovú synchronizáciu modelom request-response, ako aj PUSH model. 5.3 ActiveSync Protokol ActiveSync je postavený na protokole HTTP. Správy sa posielajú ako HTTP POST, pričom telo správy obsahuje dáta kódované do WBXML. Hlavičky správy sú špecifikované v dokumente MS-ASHTTP(Tabuľka 4 ActiveSync protokoly). Telo HTTP správy obsahuje XML dokument so štruktúrou a obsahom požadovaný aktuálne vykonávaným príkazom. Príkazy protokolu ActiveSync sú definované dokumentom MS-ASCMD(Tabuľka 4 ActiveSync protokoly), v skrátenej podobe uvádzame ich popis aj v kapitole ActiveSync príkazy a dáta Súčasti protokolu Nasledujúca tabuľka sumarizuje všetky protokoly, ktoré v sebe zahsňa ActiveSync špecifikácia. Je to podskupina protokolov Microsoft Exchange Server Protocols [12] Názov protokolu Popis Skratka ActiveSync AirSyncBase Namespace ActiveSync Calendar Class ActiveSync Command Reference ActiveSync Contact Class Špecifikuje XML elementy a komplexné XML typy v AirSyncBase namespace, ktoré sú používané v AirSync príkazmi, na identifikovanie veľkosti, typu a obsahu dát prijatých klientskou aplikáciou v požiadavke na server, alebo odpovedi poslanej serverom. Špecifikuje protokol a formát dát na výmenu kalendárov medzi serverom a klientským zariadením. Špecifikuje ako synchronizovať prílohy elektronickej pošty, informácie o kontaktoch, kalendár, and rôzne dokumenty. Špecifikuje protokol a formát dát na výmenu kontaktov medzi serverom a klientským zariadením. 13 [MS-ASAIRS] [MS-ASCAL] [MS-ASCMD] [MS-ASCNTC]

25 ActiveSync Conversations ActiveSync Document Class Exchange ActiveSync Data Types ActiveSync Class ActiveSync HTTP ActiveSync Short Message Service (SMS) Špecifikuje protokol založený na XML, používaný na vylepšenie zobrazovanie elektronickej pošty v konverzáciách. Špecifikuje sú ako dokumenty, ktoré sú dostupné cez služby Microsoft Windows SharePoint a zdieľané pomocou UNC [57] lokátora cesty prenášané zo servera na klientskú stanicu. Špecifikuje formát každého dátového typu, používaného Exchange ActiveSync XSD schémou, ktorý je prenášaný prostredníctvom WBXML formátu. Špecifikuje XML reprezentáciu dát elektronickej pošty, prijatej, alebo odoslanej mobilným zariadením, ktoré komunikuje Exchange ActiveSync protokolmi. Špecifikuje protokol a formát komunikácie medzi klientmi a serverom použitím HTTP protokolu, POST metódy a to v UTF8 kódovaní. Špecifikuje XML formát na posielanie a prijímanie SMS správ. [MS-ASCON] [MS-ASDOC] [MS-ASDTYPE] [MS-AS ] [MS-ASHTTP] [MS-ASMS] ActiveSync Notes Class Špecifikuje protokol a formát, akým si klienti môžu synchronizovať poznámky. [MS-ASNOTE] ActiveSync Provisioning Špecifikuje XML formát na komunikovanie bezpečnostných politík klientským zariadenia. [MS-ASPROV] ActiveSync Tasks Class Špecifikuje formát výmeny úloh medzi klientmi a serverom. [MS-ASTASK] ActiveSync WAP Binary XML (WBXML) Špecifikuje ako sa používa formát WBXML, špecifikuje tokeny a kódové stránky použité na vykonanie WBXML kódovania. Tabuľka 4 ActiveSync protokoly [MS-ASWBXML] 14

26 5.3.2 Transportný formát WBXML Formát XML dokumentov použitých ActiveSync protokolom je podmnožina WBXML štandardu, používaným hlavne protokolom WAP. V ActiveSync nie sú teda využívané všetky vlastnosti štandardu WBXML. Protokol ActiveSync využíva nasledovné vlastnosti WBXML: Tokeny na kódovanie XML tagov. Kódové stránky na podporu viacerých XML Namespace. Vnorené textové reťazce. Notifikácie protokolu ActiveSync využíva nasledovné vlastnosti WBXML: Kódovanie atribútov. Užívateľské (opaque) dáta. Protokol ActiveSync nevyužíva nasledovné vlastnosti WBXML: Tabuľky textových reťazcov. Entity Procesné inštrukcie ActiveSync príkazy a dáta V nasledujúcej kapitole sa bližšie venujeme príkazom protokolu ActiveSync, ktorých porozumenie je základom k implementácii ActiveSync servera Parameter SyncKey Takmer každá požiadavka, ktorá manipuluje s dátami na klientskom zariadení (okrem iniciálnej synchronizácie) musí obsahovať špeciálny element SyncKey, na základ neho si vie ActiveSync server uchovať stav synchronizácie mobilného zariadenia, čo umožňuje synchronizáciu. Server tým padám vie o každom údaji, ktorý má mobilné zariadenie uložené a počas synchronizácie posiela len také údaje, ktoré sa na mobilnom zariadení ešte nenachádzajú. Po každej úspešnej operácií, ktorá manipuluje s dátami musí poslať server nový SyncKey, ktorý klient použi pri nasledovnej požiadavke. 15

27 AutoDiscover Slúži na zistenie potrebných dát o používateľovi na základe jeho adresy. Jediný nepoužíva WBXML, ale XML. Týmto príkazom je možné pomocou AutoDiscover servera získať všetky technické údaje, ktoré by ináč musel zadávať používateľ. Požiadavka obsahuje element Address, v ktorom je adresa používateľa a element AcceptableResponseSchema - XML schéma odpovede zo servera. Odpoveď obsahuje informácie ako: Action - akcia, ktorá môže byť jedna z: Redirect - presmerovanie na iný server, Settings - odpoveď obsahuje nastavenia, Error - nastala chyba. Ďalej obsahuje primárnu adresu používateľa, adresu servera, ktorý bude obsluhovať samotnú synchronizáciu dát a údaje o digitálnom podpise FolderCreate Príkaz FolderCreate slúži na vytvorenie adresára v adresárovej hierarchii ovej schránke. Požiadavka obsahuje SyncKey, ParentId - identifikátor rodičovského adresára v ktorom sa nový adresár bude nachádzať, DisplayName - zobrazované meno adresára, Type - typ adresára (generický, mail, kalendár, kontakty, úlohy, denník, poznámky alebo neznámy). Odpoveď obsahuje ServerId - jednoznačný Identifikátor adresára na serveri, používa sa napríklad v požiadavke na aktualizáciu adresára, alebo na zmazanie adresára. Status - obsahuje stav spracovania požiadavky, ktorý môže indikovať rôzne chyby, ako napríklad: nenájdenie rodičovského adresára, nesprávny SyncKey, adresár už existuje, a iné FolderDelete Príkaz FolderDelete slúži na zmazanie adresára z hierarchie adresárov na serveri. Požiadavka obsahuje SyncKey a ServerId - jednoznačný Identifikátor adresára na serveri. Odpoveď obsahuje SyncKey a Status - stav spracovania požiadavky, môže obsahovať hlásenia ako: úspech, adresár nemožno zmazať, lebo je to Inbox, Outbox, alebo Contacts, adresár neexistuje, alebo iné FolderSync Príkaz FolderSync slúži na synchronizáciu adresárovej štruktúry. Iniciálny FolderSync ma SyncKey rovný 0, v tom prípade server vie, že má poslať klientovi celú adresárovú štruktúru a 16

28 príslušný SyncKey. Ak je prítomný SyncKey použitý z predošlých synchronizácií, server odošle klientovi iba zmeny od poslednej synchronizácie. Požiadavka obsahuje iba SyncKey, ktorý môže mať hodnotu 0. Odpoveď obsahuje SyncKey, Status a Changes. Status podobne ako u predošlých príkazoch indikuje stav požiadavky (úspech, chyba, vypršanie času, neoprávnený prístup...). Changes obsahuje počet položiek celkove - Count, a zmeny ktoré boli vykonané od poslednej synchronizácie, ale celkové, ak sa vykonáva iniciálna synchronizácia so SyncKey rovným 0. Changes ďalej obsahuje nasledovné: Delete, Add, Update - sú to zoznamy adresárov, ktoré boli zmazané, pridané, alebo zmenené od poslednej synchronizácie. Každý adresár je identifikovaný svojim ServerId, ParentId, Type a DisplayName, ako bolo opísané v predošlých kapitolách. Atribút Type môže nadobúdať 18 stanovených hodnôt, ktoré obsahujú štandardné, aj používateľom definované typy adresárov FolderUpdate Príkaz slúži na premenovanie adresára, alebo premiestnenie adresára do inej lokácie na serveri. Požiadavka obsahuje SyncKey, ServerId, ParentId a DisplayName adresára. Odpoveď obsahuje SyncKey a Status podobne ako pri príkaze FolderDelete GetAttachment Príkaz slúži na prevzatie prílohy u, ktorá nie je automaticky prevzatá spolu s om. Požiadavka neobsahuje XML dáta, iba HTTP parameter AttachmentName, ktorý identifikuje prílohu o ktorú má klient záujem. Odpoveď obsahuje opäť neobsahuje žiadne XML dáta, zaujímavá je HTTP hlavička Contenttype, ktorá hovorí o tom akého typu sú prijímané dáta (obrázok, dokument, zvuková nahrávka,...), ak nie je prítomná, dáta obsahujú ASCII text. V prípade, že sa príloha nenachádza na serveri, v odpovedi je kód HTTP GetItemEstimate Príkaz slúži na získanie odhadu počtu položiek, ktoré sa budú synchronizovať. Požiadavka obsahuje kontajner Collections, ktorý môže obsahovať maximálne 300 elementov Collection, ktoré predstavujú samotné položky na synchronizovanie. Každá kolekcia musí obsahovať 17

29 SyncKey, CollectionId, ktoré zodpovedá ServerId, získanému príkazmi FolderSync, alebo FolderCreate a môže obsahovať FilterType, ktorý špecifikuje časové okno v ktorom klient požaduje synchronizovať dáta. Môže ním byť obdobie 1 alebo 3 dni dozadu, 1 alebo 2 týždne, 1, 3, alebo 6 mesiacov dozadu. Odpoveď obsahuje Status, Collection, kde každá Collection obsahuje CollectionId na identifikovanie kolekcie a Estimate, ktorý obsahuje počet položiek, ktoré budú synchronizované ItemOperations Príkaz slúži ako kontajner na operácie Fetch a EmptyFolderContents, je to z dôvodu poskytnutia hromadného spracovania dát na serveri. Klient má možnosť vybrať si z dvoch módov prenosu dát: Inline a Multipart. Pri Inline sú dáta vložené priamo do WBXML tela správy ako BASE64 zakódované dáta. Multipart využíva možnosť protokolu HTTP rozdeliť dáta na viac častí, kde prvá časť je WBXML správa a ďalšie časti sú požadované dáta. Multipart mód signalizuje klient serveru nastavením hlavičky MS-ASAcceptMultipar: T, neprítomnosť tejto hlavičky znamená Inline mód. Požiadavka obsahuje element Fetch, ktorý obsahuje odkazy na rôzne druhy dát, napríklad Microsoft UNS zdroj dát(element LinkId), výsledky vyhľadávaní, položky alebo prílohy (element FileReference). Operáciou Fetch vieme definovať množstvo dát, ktoré sa majú prevziať, alebo formát dát ( , contact, calendar, task). Pre operáciu EmptyFolderContents definujeme položku ServerId, ktorou jednoznačne identifikujeme adresár na serveri z ktorého má byť vymazaný obsah. Je možné ešte definovať, či sa majú zmazať aj podadresáre, a to elementom DeleteSubfolder. Odpoveď obsahuje ku každej operácií príslušné dáta, ktoré boli vyžiadané zo servera a Status element, ktorý hovorí o stave požiadavky, môže indikovať chybový stav MeetingResponse Príkaz slúži ako odpoveď na požiadavku o stretnutie. Odpoveď môže byť prijatie, podmienečné prijatie a odmietnutie. Požiadavka obsahuje CollectionId adresára s požiadavkou o stretnutie, RequestId požiadavky a UserResponse, čo je samotná odpoveď na požiadavku. Odpoveď obsahuje opäť RequestId, v prípade kladnej odpovede CalendarId, pretože bola vytvorená nová položka v kalendári a Status, ktorý hovorí o stave požiadavky, môže indikovať chybový stav. 18

30 MoveItems Príkaz slúži na premiestnenie položky z jedného miesta na serveri na iné. Požiadavka obsahuje ServerId položky, ktorá je premiestňovaná, ServerId zdrojového a cieľového adresára. Môže obsahovať viac položiek naraz, Odpoveď obsahuje Status premiestnenie každej položky, jej nové ServerId Ping Príkaz slúži na požiadanie servera o monitorovanie adresárov a pri prípadnej zmene ich obsahu o notifikáciu. Požiadavka obsahuje Folders, zoznam adresárov, ktoré majú byť monitorované a HeartBeatInterval, čas, ktorý má server čakať pre odoslaním odpovede. Server odpovedá ak: vyprší čas definovaný klientom, alebo nastane zmena na jednom z adresárov. Odpoveď obsahuje zoznam adresárov na ktorých nastala zmena, Status, ktorý hovorí o tom aká udalosť nastala. Ak žiadna zmena nenastala, klient môže požiadavku zopakovať. Na ušetrenie prenesených dát si server môže zapamätať zoznam adresárov a čas pre zaslaním odpovede a takým spôsobom môže obslúžiť aj príkaz Ping bez WBXML správy Provision Príkaz slúži na vyžiadanie bezpečnostných politík zo servera, ako dĺžka a sila hesla. Tento príkaz zvykne byť ako jeden z prvých zaslaný na server ResolveRecipients Príkaz slúži na identifikovanie zoznamu príjemcov, prípadne na prijatie ich bezpečnostných certifikátov. Požiadavka obsahuje pole To, čo je meno človeka, MaxAmbiguousRecipients, čo je maximálny počet návrhov adries pre jedno zadané meno v poli To, CertificateRetrieval, kde sa uvádza či chceme, alebo nechceme prijať bezpečnostný certifikát a či má byť typu X509, alebo nemusí. Odpoveď obsahuje pole Status, Recipient, ktoré obsahuje informácie o osobe ako jej , meno a bezpečnostné certifikáty. 19

31 Search Príkaz slúži na vyhľadávanie v zozname kontaktov, alebo mailovej schránke. V tomto príkaze sa na zistenie lokalizácie klienta používa HTTP hlavička Accept-Language (tu si môžeme všimnúť nesymetriu v tomto protokole, pretože v prípade príkazu AutoDiscover sa použi na zistenie lokácie klienta XML element Culture). Klient môže špecifikovať koľko maximálne položiek má server vrátiť, v tomto prípade musí server poslať aj celkový počet nájdených záznamov. Vyhľadávaný výraz je porovnávaný s viacerými poľami kontaktov, ako napríklad: Zobrazované meno, telefón, Kancelária, Titul, Spoločnosť, Alias, Prvé meno, Posledné meno alebo ová adresa. Požiadavka obsahuje pole Name, čo je názov úložiska kde sa bude vyhľadávať, môže obsahovať: Mailbox - poštová schránka, DocumentLibrary - vyhľadávanie v dokumentoch (Windows SharePoint Services, alebo UNC knižnica), alebo GAL - Global Adress List - zozname kontaktov. Do poľa Query sa zadáva text, ktorý chceme vyhľadať, môžeme pri tom použiť základné operátory And - A, Or - ALEBO, FreeText - kľúčové slová, Class, CollectionId, EqualTo, GreaterThan - väčší ako, alebo LessThan - menší ako- posledné dva v spojení s dátumom. Search podporuje ešte rôzne nastavenia a obmeny výsledku, ktorým sa nebudem venovať podrobne. Odpoveď obsahuje LongId, jedinečný identifikátor vyhľadávania, ktorý mu server priradí, aby bolo k nemu možné pristúpiť aj neskôr. Properties - vlastnosti každého objektu, ktorý príkaz Search identifikuje a pošle klientovi. Range - rozsah výsledkov vyhľadávania, aký bol doručený s touto odpoveďou, definovaný ako interval, napríklad: 0-19, znamená dvadsať doručených výsledkov. Result - predstavuje jeden element pre každú nájdenú položku, vnútri každého Result elementu sa nachádza element Properties. Status -indikuje stav spracovania požiadavky, môže indikovať chybový stav. Total - predstavuje celkový počet položiek, ktoré server našiel pre dané vyhľadávanie. Store - predstavuje kontajner pre elementy Status, Result, Rang a Total. Na obrázku Obrázok 5 Priebeh vyhľadávania v protokole ActiveSync [32] je znázornený možný priebeh vyhľadávania, kedy si klient v prvých dvoch krokoch pýta výsledky vyhľadávania a v treťom kroku je použitý príkaz Fetch na prevzatie položky ( ) a odpovedanie - SmartReplay, respektíve preposlanie - SmartForward. 20

32 SendMail Obrázok 5 Priebeh vyhľadávania v protokole ActiveSync [32] Príkaz slúži na posielanie MIME ovej správy na ActiveSync server. Správa neobsahuje WBXML, ale MIME formátovanú správu. Dodatočný parameter v URL - SaveInSent - umožňuje klientovi špecifikovať, aby server uložil túto správu do adresára Odoslané položky. Pole From ovej správy je na serveri prepísané primárnou mailovou adresou používateľa. Požiadavka obsahuje MIME formátovanú správu podľa RFC 822 [33]. Odpoveď je zaujímavá iba z hľadiska HTTP status kódu Settings Príkaz slúži na ukladanie a načítanie globálnych nastavení. Požiadavka obsahuje Set a Get príkazy a tie zas názvy premenných, a to: Oof (Out of office) - informácie o prítomnosti používateľa na pracovisku, DevicePassword - klient môže nastaviť, alebo vymazať obnovovacie heslo klientskeho zariadenia, DeviceInformation - klient môže nastaviť rôzne nastavenie o klientskom zariadení (Model, IMEI číslo, Názov zariadenia, Operačný systém... ), UserInformation - informácie o používateľovi - no jediná informácia, ktorú vie klient prečítať je zoznam ových adries osoby, nedá sa zapísať. 21

33 Odpoveď obsahuje Status, ktorý indikuje stav spracovania, môže obsahovať chybové hlásenie. Jeden Status element je na vrchu XML štruktúry, ktorý hovorí o celkovom spracovaní a potom pre každý Set príkaz osobitný Status element. V odpovedi sú ďalej polia Oof, DevicePassword, DeviceInformation a UserInformation, ktoré predstavujú odpovede na Set a Get príkazy z požiadavky SmartForward Príkaz slúži na preposielanie správ bez toho, aby bolo nutné stiahnuť celú správu zo servera. Požiadavka neobsahuje WBXML správu, len URL parametre ItemId - identifikátor preposielanej správy a CollectionId - ktorý predstavuje ServerId kolekcie, ktorá obsahuje správu a SaveInSent parameter podobne ako pri príkaze SendMail. SmartForward môže byť použitý aj na požiadavky o stretnutie. Požiadavka obsahuje MIME formátovanú správu podľa RFC 822 [33]. Odpoveď je zaujímavá iba z hľadiska HTTP status kódu. Kód 500 znamená, že správa, ktorú sa klient snaží preposlať bola odstránená, alebo s nenachádza na stanovenom mieste SmartReplay Príkaz slúži na odpovedanie na správu bez toho, aby bolo nutné stiahnuť celú správu zo servera. Podobne ako SmartReplay a SendMail, neobsahuje požiadavka WBXML správu, iba URL parametre ItemId, CollectionId a SaveInSent, s rovnakým významom ako pri spomínaných príkazoch. SmartReplay môže byť použitý aj na požiadavky o stretnutie. Požiadavka obsahuje MIME formátovanú správu podľa RFC 822 [33]. Odpoveď je zaujímavá iba z hľadiska HTTP status kódu. Kód 500 znamená, že správa, na ktorú sa klient snaží odpovedať bola odstránená, alebo s nenachádza na stanovenom mieste Sync Príkaz slúži na synchronizovanie kolekcií (adresárov) medzi klientom a serverom. Požiadavka obsahuje SyncKey, iniciálne musí klient poslať SyncKey rovný nule, aby mohol byť inicializovaný stav na serveri, server odošle validný SyncKey, ktorý môže klient poslať v ďalšej požiadavke a prebehne reálna synchronizácia. Spracovanie synchronizácie je znázornené na Obrázok 22

34 6 - klient pridáva do požiadavky zmeny vykonané na adresároch, kým nie je naplnené okno, alebo kým nespracoval všetky adresáre. Obrázok 6 Spracovanie synchronizácie na klientskej strane [32] V Tabuľka 5 Preklad obrázka Obrázok 6 sa nachádza preklad anglických hesiel z obrázka Obrázok 6 Spracovanie synchronizácie na klientskej strane [32] Reset folder-enumerator Entry/Get next folder If (more folders) Inicializácia enumerácie adresárov Vstúpiť/vyžiadať ďalší adresár Ak sú dostupné ďalšie adresáre 23

35 Add folder changes If (windows full) Entry/Send Sync request and wait Sync response received Process Sync response Pridať zmeny na adresároch Ak je plné odosielacie okno Poslať Sync príkaz a čakať na odpoveď Prijatá odpoveď na Sync príkaz Spracovať Sync odpoveď Tabuľka 5 Preklad obrázka Obrázok 6 V požiadavke Sync je možné špecifikovať: Wait - analógia HeartBeatInterval z príkazu Ping; Partial - indikuje, že klient posiela len čiastočný zoznam kolekcií a ostatné má použiť server z jeho pamäte (podobne ako pri príkaze Ping, kedy si server pamätá posledný zoznam synchronizovaných kolekcií, tým pádom šetrí množstvo prenášaných dát); WindowSize - maximálny počet synchronizovaných položiek, ktoré klient očakáva od servera v jednej odpovedi, ak nie je prítomný, server použije hodnotu 100; Add, Change, Delete - s možnosťou zadania viacnásobne, slúžia na pridanie na server, zmenu a zmazanie ových správ, kontaktov, stretnutí, úloh, alebo poznámok. V odpovedi od servera sa vykoná pridanie, zmena, alebo vymazanie na klientskom zariadení. Obsahom príkazov Add, Change a Delete sa kvôli ich zložitosti zaoberať bližšie nebudem ValidateCert Príkaz slúži na overenie certifikátu, ktorý dostal klient cez S/MIME poštu. Na potvrdenie platnosti certifikátu musí server overiť jeho exspiráciu, či nebol odvolaný, a musí podobne overiť aj každý certifikát v certifikačnej hierarchií a že koreňová autorita je dôveryhodná certifikačná autorita. Požiadavka obsahuje kontajner Certificates, ktorý obsahuje jeden, alebo viac elementov Certificate - Base64 zakódovaný certifikát, CertificationChain - obsahuje zoznam certifikátov v certifikačnej hierarchií na validáciu. CheckCRL - slúži na povolenie serveru ignorovať neoveriteľnosť certifikátu, ak je nastavený na "false" Odpoveď obsahuje Status - celkový stav spracovania, Certificate s Base64 zakódovaným certifikátom a elementom Status - ako stav overenia platnosti toho konkrétneho certifikátu. 24

36 5.3.4 ActiveSync klientske aplikácie ActiveSync. V nasledujúcich kapitolách predstavíme niekoľko aplikácie, ktoré narábajú s protokolom Aplikácia ActiveSync [30] Najnovšia verzia je 4.5, je podporovaná len systémom Windows XP SP2 a predošlými verziami Windows. Nie je štandardnou súčasťou systému, je ju nutné doinštalovať. Je to aplikácia, ktorá synchronizuje PIM údaje medzi osobným počítačom a mobilným zariadením pomocou USB kábla. S mobilným zariadením je najskôr nutné nadviazať partnerstvo (partnership), potom môže prebiehať samotná synchronizácia Windows Mobile Device Center [31] Od systému Windows Vista existuje náhrada za program ActiveSync a to Windows Mobile Device Center. Podporuje Windows Vista Home Basic, Premium, Windows Vista Business, Enterprise, Ultimate a Server, Windows 7 Home Premium, Professional, Enterprise a Ultimate. Podporuje synchronizáciu štandardných PIM dát, a nové funkcie systému Windows Mobile 6, Information Rights Management ochrana dokumentov. Na synchronizáciu elektronickej pošty, kontaktov, úloh a poznámok s PC je vyžadovaný MS Outlook 2003, alebo Má základnú podporu pre Windows CE 4.2, 5.0, Pocket PC 2002 a Smartphone 2002, pripájanie cez USB a sériový port, internetové pripojenie hosťujúceho PC a prezeranie súborov cez hosťujúce PC. Plne podporované zariadenia: Windows Mobile 2003, Windows Mobile 2003 Second Edition, Windows Mobile 5.0, Windows Mobile 5.0 s Messaging and Security Feature Packom, Windows Mobile 6.0 a Windows Embedded CE Bezpečnosť Vo väčšine prípadov, všetka komunikácia medzi klientom a serverom prebieha cez HTTP spojenie zabezpečené štandardom Secure Sockets Layer - SSL[14], referencia č. [14]. Predpokladá sa, že SSL spojenie je zabezpečené dostatočne na prenos dôverných dát, ako osobné, resp. prihlasovacie údaje, alebo súkromná elektronická pošta. Zároveň špecifikácia ActiveSync protokolu predpokladá, že klientská aplikácia dôveruje certifikátom SSL spojenia. 25

37 6 Implementácie ActiveSync protokolu 6.1 Komerčné implementácie Stručne spomenieme niektoré dostupné komerčné riešenia, keďže sa v tejto práci sústredím na OpenSource riešenia, nebudem im venovať veľkú pozornosť ExchangeServer ExchangeServer je groupware balík programov od spoločnosti Microsoft, ktorý obsahuje implementáciu protokolu ActiveSync Scalix Scalix je komerčný groupware vyvíjaný na platforme Linux s podporou aplikácie Microsoft Outlook, webovým rozhraním a synchronizáciou pomocou protokolu ActiveSync. 6.2 OpenSource implementácie V tejto kapitole bližšie popisujem niektoré OpenSource implementácie ActiveSync protokolu Zarafa Z-Push Z-Push je súčasť komerčného projektu Zarafa [34] určená na synchronizáciu PIM obsahu s mobilnými zariadeniami. Má podporu u všetkých zariadení, ktoré podporujú ActiveSync. Z-Push je vyvíjaný na platforme Apache servera [16] a implementovaný v jazyku PHP [29] a teda umožňuje aplikáciám s podporou PHP synchronizovať svoje dáta s ľubovoľným zariadením podporujúcim protokol ActiveSync. Na obrázku Obrázok 7 Z-Push architektúra je znázornená architektúra systému Z-Push, v hornej časti sa nachádzajú dáta obsahujúce backend aplikácie. V súčasnosti existujú štyri: maildir, vcard, IMAP špeciálny Zarafa balíček, obsahujúci podporu synchronizácie elektronickej pošty, kalendára, kontaktov a úloh. 26

38 Obrázok 7 Z-Push architektúra, [17] Z-Push je modulárny systém, ktorý dovoľuje pridávať zdroje dát, čiže implementácie backendov. Je kompatibilný s mnohými zariadeniami, podmienkou je, aby tieto zariadenia mali podporu protokolu ActiveSync Inštalácia a konfigurácia systému Inštalácia systému je pomerne jednoduchá. Systém vyžaduje: - web server, odporúčaných je Apache2 s podporou PHP 4 - nainštalovaný a nakonfigurovaný niektorý podporovaný backend systém: o IMAP server o Maildir server o VCard server o MAPI backend [35] - nakopírovanú Z-Push distribúciu do adresára Apache servera určeného na publikovanie na WWW 27

39 Konfigurácia pozostáva z nastavenia niekoľkých položiek pre Apache server a nastavenia spojenia so zvoleným backend systémom: Základná konfigurácia Apache: o httpd.conf, pridať Alias: Alias /Microsoft-Server-ActiveSync d:\web_root\z-push\index.php - Základná konfigurácia Z-Push, nachádza sa v config.php o $BACKEND_PROVIDER = "BackendICS"; define('mapi_server', 'file:///var/run/zarafa'); o $BACKEND_PROVIDER = "BackendIMAP"; define('imap_server', 'localhost'); define('imap_port', 143); o $BACKEND_PROVIDER = "BackendMaildir"; define('maildir_base', '/tmp'); define('maildir_subdir', 'Maildir'); o $BACKEND_PROVIDER = "BackendVCDir"; define('vcarddir_dir', '/home/%u/.kde/share/apps/kabc/stdvcf'); O-Push O-Push je modul systému OBM Sync, ktorý je súčasťou OBM projektu [36]. OBM v sebe zahsňa a groupware riešenia na báze OpenSource technológií, je dostupný pod GPL licenciou[37], čo umožňuje prezeranie a modifikovanie zdrojových kódov a prispievanie do projektu vlastnou prácou. O-Push je implementovaný v jazyku Java a predstavuje implementáciu ActiveSync protokolu vo verzii 12.1, čo zodpovedá implementácii Microsoft Exchange Projekt sa nachádza na stránke [38]. 28

40 Technológie využívané pri vývoji O-Push: Eclipse Server-Side Equinox [38] OSGi [40] Eclipse plugins [41] Jetty continuations [42] Relačná databáza (podporované sú PostgreSQL, alebo MySQL) Rozšírenia systému je možné robiť cez rozšírenia Eclipse pluginov: úložný systém, kde O-Push ukladá synchronizačné údaje, údaje o mobilných zariadeniach, bezpečnostné nastavenia o implementovaný úložný systém využíva jazyk Java na prístup do databázy, skade získava dáta backendová časť, ktorá poskytuje dáta ako: y, kalendár, úlohy, alebo kontakty. o implementovaný backend používa OBM systém na synchronizáciu kontaktov, kalendára a úloh, a protokol IMAP na prístup k om. 29

41 7 Návrh riešenia - rozšírenie projektu OPush Po zvážení faktov, ktoré sme doteraz v rámci tejto práce nadobudli a zohľadnení všetkých kritérií zadania tejto práce sme vybrali systém OPush ako ten systém, ktorý rozšírime v rámci implementácie prototypu o nasledovnú funkcionalitu: možnosť spojenia viacerých ových kont do jedného spoločného o pre každé konto samostatné adresáre o pre každé konto samostatný IMAP a SMTP server Obrázok 8 Znázornenie rozšírenia systému OPush 30

42 7.1 Postup návrhu rozšírenia V nasledujúcej kapitole sa venujeme jednotlivým krokom, ktoré boli potrebné na úspešné implementovanie navrhnutého rozšírenia systému. Jednotlivé kroky predstavujú štúdium či už protokolu na ktorom je OPush postavený (ActiveSync[32]), štúdium samotného systému OPush Oboznámenie sa s protokolom ActiveSync Predtým, ako sme sa mohli zaoberať samotným rozšírením systému, bolo potrebné spoznať komunikačný protokol, akým je realizovaný prenos dát medzi serverom a mobilným klientom. Systém OPush je postavený nad protokolom ActiveSync, ktorý popisujeme v kapitole Oboznámenie so systémom OPush Základné informácie o systéme popisujeme v kapitole Viac informácií sme k dispozícií nemali, ani po vyžiadaní od správcu projektu na code.google.com. Vitálna je pre naše účely dokumentácia dátového modelu, dokumentácia samotného kódu a všeobecne algoritmov, akými sa riadi systém OPush. Systém sme teda museli spoznať sami, niekde systémom pokus - omyl. Na návrh a implementáciu nášho rozšírenia bolo potrebné spoznať projekt OPush v oveľa väčších detailoch, spoznať jeho architektúru, procesy aké v ňom prebiehajú a ako sú implementované jednotlivé operácie protokolu ActiveSync (protokol ActiveSync popisujem v kapitole 5.3.3). 31

43 Architektúra Obrázok 9 Architektúra OPush systému znázorňuje komponenty a ich závislosti, ktoré spolu tvoria OPush systém. Obrázok 9 Architektúra OPush systému 32

44 Databáza a dátový model OPush zdieľa databázu so systémom OBM, z ktorého využíva niekoľko tabuliek. Sú to hlavne tabuľka UserObm, ktorá obsahuje dáta o používateľoch (meno, priezvisko, login, heslo, doménu a iné), ďalej tabuľku Domain, ktorá obsahuje informácie o doméne používateľa. Presný účel tabuľky Domain sa mi nepodarilo zistiť, pre moje potreby ale nie je relevantná. Fyzický dátový model je znázornený na obrázku Obrázok 10 Dátový model OPush. Z pohľadu tejto práce sú zaujímavé tabuľky: opush_device - mobilné zariadenia, obsahuje typ a referenciu na jeho majiteľa opush_folder_mapping - pre každé zariadenie uchováva zoznam adresárov, ako napríklad štandardné adresáre protokolu IMAP: INBOX, Trash, Drafts. Pre každý adresár je uchované meno a identifikátor. Meno je v tvare- "obm:\\test@hmailserver.local\ \inbox", kde hrubo vyznačené je ová adresa používateľa test. Takémuto adresáru sa hovorí kolekcia. opush_sync_state - uchováva pre každú kolekciu SyncKey (viď kapitolu Parameter SyncKey), a dátum jej poslednej synchronizácie. opush_sync_perms - jej jediným účelom je povedať, či má používateľ identifikovaný menom a ID zariadenia právo na synchronizáciu, ide o autorizačnú tabuľku. opush_ping_heartbeat - uchováva si hodnoty HeartBeat pre operácie Sync a Ping, v prípade, že ich klient - mobilné zariadenie nepošle v požiadavke (viď kapitoly Ping a Sync). opush_sync_mail - obsahuje zoznam UID ových správ, ktoré sú aktuálne uložené na klientskom zariadení. Táto informácia je dôležitá, keď sa vytvára diferencia medzi ami na serveri a na klientskom zariadení. 33

45 Obrázok 10 Dátový model OPush Presný fyzický model uvádzame v Prílohe A - fyzický dátový model OPush, ako zoznam tabuliek s popisom stĺpcov, ktoré využíva OPush na implementáciu protokolu ActiveSync Hlavné triedy a rozhrania V tejto kapitole popisujeme vedomosti, ktoré sme nadobudli štúdiom zdrojových kódov systému OPush. Na vrchu hierarchie Java tried a rozhraní projektu OPush sú dva rozhrania: IBackend a IStorage, ktorých implementáciou je možné dosiahnuť veľkú variabilitu systému IBackend Hlavné rozhranie celého OPush projektu, určené komunikáciu klient-server, čiže na prenos dát (import a export dát z backendového systému) a poskytuje rozhranie pre štandardné procedúry ActiveSync protokolu ako: reset synchronizácie, monitoring zmien v dátach, autentifikáciu a autorizáciu. Rozhranie IBackend zoskupuje objekty, ktoré sú zodpovedné za narábanie s dátami: IImporter - rodičovské rozhranie pre import dát z klientskeho zariadenia na server IHierarchyImporter - import hierarchie adresárov IContentsImporter - import obsahu ( , úlohy, kalendár...) IExporter - rodičovské rozhranie pre export dát zo servera na klientske zariadenie IHierarchyExporter - export hierarchie adresárov 34

46 IContentsExporter - export obsahu ( , úlohy, kalendár...) ISyncStorage - v nasledujúcej kapitole ISyncStorage Toto rozhranie je zodpovedné za ukladanie dát, potrebných na implementovanie protokolu ActiveSync. Protokol prikazuje, aby bol na serveri uložený aktuálny stav dát, aký sa nachádza na klientskom zariadení. V niektorých prípadoch môže klient poslať prázdnu požiadavku, v tom prípade sa zoberú parametre, aké boli použité pri poslednom volaní. Dáta, ktoré uchováva server sú: hierarchia adresárov, zoznam ov, úloh, stretnutí v kalendári, kontaktov čas, aký má server čakať pri operáciách Push a Sync (HeartBeat) Rozšíriteľnosť a modulárnosť Projekt OPush je postavený nad technológiou OSGi, ktorej základná vlastnosť je modulárnosť. OPush poskytuje tri body rozšírenia (Extension points) a teda tri spôsoby ako si projekt prispôsobiť podľa vlastnej potreby. Pre všetky body rozšírenia existujú v projektu moduly, ktoré ich rozširujú (implementujú rozhrania spomínané v kapitole Hlavné triedy a rozhrania). Tabuľka 6 Body rozšírenia projektu OPush sumarizuje body rozšírenia, ich rozhrania a implementácie. Názov bodu rozšírenia Informácie org.obm.push.backend Rozhranie org.obm.push.backend.ibackendfactory, (je to rozhranie, ktoré produkuje objekty typu IBackend) Implementácia org.obm.push.backend.obm22.backendfactory Modul org.obm.push.backend.obm22 org.obm.push.storage Rozhranie org.obm.push.store.isyncstorage Implementácia org.obm.push.storage.jdbc.syncstorage 35

47 Modul org.obm.push.storage.jdbc org.obm.push.search Rozhranie org.obm.push.search.isearchsource Implementácie org.obm.push.searchsource.ldap.booksource org.obm.push.backend.obm22.search.obmsearchcontact Modul org.obm.push.backend.obm22 Tabuľka 6 Body rozšírenia projektu OPush 36

48 Model správania V tejto kapitole sa venujeme vnútornej komunikácii medzi triedami. Snažíme sa ju zachytiť sekvenciami volaní jednotlivých metód Java tried. Sústredíme sa na komunikáciu medzi hlavnými rozhraniami. Obrázok 11 predstavuje spracovanie jednej ActiveSync požiadavky. Spracovanie začína prípravou objektu typu IContinuation, ktorý uchováva otvorené TCP spojenie medzi požiadavkami, čo je dôležité pre PUSH funkcionalitu. Metódami ispending a isresumed sa zisťuje, či existuje otvorené TCP spojenie, alebo sa jedná o novú požiadavku. Ak sa jedná o existujúce spojenie, spracovanie požiadavky je posunuté objektu typu IContinuationHandler (je to buď PingHandler, alebo SyncHandler, podľa operácie, ktorá bola volaná z mobilného zariadenia), a to volaním metód senderror, alebo sendresponse. Ak sa jedná o novú požiadavku, overí sa o akú HTTP metódu sa jedná. Ak ide o OPTIONS, alebo GET, zašle sa ako odpoveď informácia o možnostiach OPush servera (verzia ActiveSync protokolu, zoznam ActiveSync operácií, ktoré server podporuje a iné). Následne sa vykoná autentifikácia (ActiveSync využíva HTTP Basic). Overí sa používanie bezpečnostných politík: skontroluje sa HTTP hlavička X-Ms-PolicyKey (alebo parameter v URL), ak je prítomná a obsahuje hodnotu 0 a práve spracovávaný príkaz nie je Provision, tak sa ako odpoveď pošle status kód 449 (Retry with), čo mobilnému zariadeniu hovorí, aby najskôr poslalo príkaz Provision, ktorým mu budú odoslané bezpečnostné politiky nastavené administrátorom ActiveSync konta. Ak overenie používania bezpečnostných politík prebehlo v poriadky, je pokračuje sa spracovaním konkrétneho ActiveSync príkazu, metódou processactivesyncmethod (Obrázok 12). Metóda skontroluje verziu protokolu, akú podporuje mobilné zariadenie, získa z požiadavky ActiveSync módu, ktorá má byť vykonaná, podľa toho vyberie implementáciu rozhrania IRequestHandler, ktorá spracuje príkaz. Pre každú ActiveSync metódu existuje jedna implementácia IRequestHandler-a. 37

49 Obrázok 11 Spracovanie požiadavky ActiveSync 38

50 Obrázok 12 Spracovanie operácie metódou processactivesyncmethod 39

51 7.2 Navrhované zmeny v projekte OPush Cieľom práce je navrhnúť a implementovať prototyp, čo v tomto prípade znamená, že sa budeme venovať len synchronizácií ov. Po oboznámení sa s protokolom ActiveSync a preštudovaním projektu OPush, sme schopný navrhnúť jeho zmeny a doplnenia., aby bolo možné dosiahnuť vytýčený cieľ - synchronizáciu ov z viacerých kont. Prvým a hlavným doplnením projektu je zavedenie pojmu externé konto. Externé preto, lebo momentálne existuje pre každého používateľa jedno konto (tabuľka UserObm, viď kapitolu ), ktoré môžeme nazvať interným. Vytvoríme teda reláciu medzi jedným interným a N externými kontami. Zachováme primárny autentifikačný mechanizmus - čiže klientske zariadenie bude naďalej posielať meno a heslo interného konta. Pribudnú sekundárne autentifikácie externých kont - pri každom vytvorení spojenia na mailový server. Zavedením externých kont získame tieto výhody: na klientskom zariadení budú prístupné adresáre zo všetkých externých kont, a keďže protokol ActiveSync dovoľuje vybrať ktoré adresáre sa majú synchronizovať, je vhodné vybrať napríklad všetky adresáre s prichádzajúcou poštou, takto predídeme problému synchronizácií adresárov, ktoré obsahujú menej zaujímavý obsah. každému externému kontu môžeme priradiť svoj vlastný server pre odchádzajúcu poštu, čo má význam v prípade, že nechceme aby boli správy zo všetkých kont odosielané z jedného servera. Reálne by to znamenalo, že na správu odpovie z inej adresy na akú bola odoslaná Ďalej bude potrebné upraviť, niektoré služby, aby boli viac použiteľnejšie pre naše potreby: Locator - služba slúži na získanie doménového mena servera podľa služby a používateľa, rozšírili sme ju tak, aby poskytovala URL, port, protokol, a informáciu o tom, či je spojenie zabezpečené. Manager - služba slúži na komunikáciu s mail serverom. Projekt OPush je navrhnutý na komunikáciu s jedným mail serverom, ktorého URL je pri štarte aplikácie získaná cez službu Locator a uložená. Službu Manager je potrebné upraviť, aby bola schopná komunikovať s viacerými mail servermi, podľa toho ku ktorému externému kontu chceme pristúpiť. MailBackend - služba slúži na získanie adresárovej štruktúry z mail servera, projekt OPush má túto službu implementovanú tak, že adresáre nie sú načítavané zo servera, ale služba stále vráti tú istú 40

52 množinu adresárov: prijatá(inbox), odoslaná(sent), rozpísaná (Drafts) a zmazaná (Trash) pošta. Naša úprava spočíva v načítaní skutočnej množiny adresárov z mail servera. Z pohľadu zachovania transparentnosti voči klientským zariadeniam, je vhodné zaistiť, aby existoval na klientskom zariadení len jeden predvolený - "Default" adresár z každého druhu (jeden default INBOX, jeden default Sent, atď.), aby nevznikol problém, keby sme na klientskom zariadení chceli vytvoriť dva INBOX adresáre. Využijeme teda možnosť označiť adresáre jedného konta ako predvolené a ostatných ako používateľom vytvorené - "User-created". 41

53 8 Implementácia rozšírenia systému OPush Implementáciou rozhrania IBackend a *Importer a *Exporter tried, bola vytvorená prídavná vrstva v projekte OPush, ktorá umožňuje všetky operácie, ktoré tieto triedy poskytujú, robiť súčasne s viacerými kontami. 8.1 Implementácia MultiBackend-u Pre implementáciu riešenia, aké je navrhnuté v kapitole 7 Návrh riešenia - rozšírenie projektu OPush, podľa kapitoly 7.2 Navrhované zmeny v projekte OPush, bolo potrebné rozšíriť projekt OPush nasledovným spôsobom: v prípade rozhrania IBackend ide o implementácia bodu rozšírenia, v prípade ISyncStorage ide len o rozšírenie aktuálnej implementácie. Zmeny sumarizujú: Tabuľka 7 a Tabuľka 8. Názov bodu rozšírenia Informácie org.obm.push.backend Rozhranie org.obm.push.backend.ibackendfactory Implementácia sk.fiit.opush.backend.multi.multibackendfactory (trieda, ktorá produkuje objekty typu MultiBackend Modul sk.fiit.opush.backend.multi org.obm.push.storage Rozhranie org.obm.push.store.isyncstorage Rozšírenie org.obm.push.storage.jdbc.syncstorage Modul org.obm.push.storage.jdbc Tabuľka 7 implementácie a rozšírenie bodov rozšírení Názov pôvodnej triedy/rozhrania Implementujúca trieda org.obm.push.backend.obm22.mail: IBackend sk.fiit.opush.backend.multi.multibackend 42

54 IContentsExporter IContentsImporter IHierarchyExporter IHierarchyImporter MailBackend org.obm.locator.client.servicelocator sk.fiit.opush.backend.multi.impl.contentsexporter sk.fiit.opush.backend.multi.impl.contentsimporter sk.fiit.opush.backend.multi.impl.hierarchyexporter sk.fiit.opush.backend.multi.impl.hierarchyimporter sk.fiit.opush.backend.multi.mbmailbackend sk.fiit.opush.backend.multi.mbservicelocator Tabuľka 8 Implementované triedy Názov triedy org.obm.push.store.syncstorage org.obm.locator.client.locatorclient org.obm.push.backend.obm22.folderbackend org.obm.push.backend.obm22.mail.mailback end org.obm.push.backend.obm22.mail. mo nitoringthread org.obm.push.backend.obm22.mail. man ager org.obm.push.backend.obm22.impl.obmsync Backend org.obm.push.backend.foldertype Popis rozšírenia Pridané metódy na výber externých kont. Rozšírenie poskytovaných dát o port, protokol a príznak, či server vyžaduje bezpečné pripojenie. Zmena prístupu ku konštruktoru z protected na public, aby bolo možné vytvoriť objekt aj v inom module. Zmena prístupu k niektorým metódam, aby bolo ich možné upraviť v zdedenej triede. Úprava kvôli kompatibilite s novým Locator klientom. Rozšírenie na možnosť prístupu k viacerým mail serverom. Zmena prístupu k niektorým metódam, aby bolo ich možné upraviť v zdedenej triede. Pridané mapovanie z predvolených typov adresárov na používateľom vytvorené. Tabuľka 9 Zoznam upravených tried projektu OPush 43

55 Nasledujúci obrázok znázorňuje hlavné rozhrania a triedy systému OPush, červeno ohraničené sú hlavné, nami implementované triedy. Základ tvorí rozhranie IBackend (úplne vľavo), od neho je odvodená trieda MultiBackend, ktorá cez 4 hlavné rozhrania, ktoré sú taktiež implementované príslušnými triedami (viď Tabuľka 8 Implementované triedy), pristupuje k službám mailového servera, ktoré sú sprístupnené triedami MBMailBackend a FolderBackend. Obrázok 13 Class diagram najdôležitejších tried OPush 44

56 8.2 Zmeny v databázovom modeli Do databázy OPush bola pridaná tabuľka, ktorá obsahuje externé kontá, zoznam a popis jej stĺpcov popisuje Tabuľka 10 Popis tabuľky OPUSH_EXTERNAL_ACCOUNT. Názov Typ Popis id serial not null Primárny kľúč, generovaný databázou. owner int4 Referencia na používateľský účet OBM. device_id int4 not null ID zariadenia z tabuľky opush_device domain varchar(255) not null Doména mailového konta. username varchar(255) not null Meno priradené k mailovému kontu. password varchar(255) not null Heslo mailového konta. incom_mail_host varchar(100) Názov servera, ktorý poskytuje dané mailové konto. incom_mail_protocol varchar(20) ový protokol na preberanie (download) pošty (IMAP, POP - v prototype nie je podporovaný POP) incom_mail_port int4 TCP/UDP port (záleží na protokole) incom_mail_secure bool Vyžaduje server bezpečný kanál, taktiež závislé aj od protokolu(prototyp podporuje IMAP over TLS). out_mail_host varchar(100) Názov servera, ktorý poskytuje dané mailové konto. out_mail_protocol varchar(20) ový protokol na odosielanie pošty (SMTP) out_mail_port int4 TCP/UDP port (záleží na protokole) out_mail_secure bool Vyžaduje server bezpečný kanál, taktiež závislé aj od protokolu(prototyp podporuje SMTP over TLS). Tabuľka 10 Popis tabuľky OPUSH_EXTERNAL_ACCOUNT 8.3 Implementácia riešenia na strane klienta Pre praktické použitie riešenia sme navrhli a implementovali webovú aplikáciu, ktorá poskytne používateľom možnosť prezerať a definovať externé kontá systému OPush. 45

57 8.3.1 Webová aplikácia RegisterAccount Webová aplikácia bola dizajnovaná na použitie v mobilných zariadeniach, je programovaná štandardnými metódami Java Enterprise Edition, za použitia webového frameworku JavaServer Faces a jeho implementáciu MyFaces. Aplikácia bola testovaná na Java Servlet kontajneri Apache Tomcat. Funkcionalita aplikácie sa dá zhrnúť do troch bodov: 1. registrácia hlavného konta (tabuľka UserObm) 2. registrácia externého konta (zápis do tabuľky opush_external_account) 3. prezeranie zoznamu definovaných externých kont (vyber z tabuľky opush_external_account) Na obrázku Obrázok 14 je ukážka aplikácie, ako vyzerá na PC, viac o použití aj s obrázkami z mobilného telefónu, sa nachádza v Prílohe B - Používateľská príručka aplikácie RegisterAccount. Obrázok 14 Ukážka aplikácie RegisterAccount Aplikácia overuje používateľa pomocou mena a hesla, ktoré sa kontroluje v tabuľke ObmUser. Metóda na poslanie autentifikačných dát bola zvolená HTTP Basic, síce nie je bezpečná, pretože prenáša heslo v otvorenej podobe, no vzhľadom k tomu, že aplikácia je prototyp, je toto postačujúce. 46

58 9 Testovanie riešenia V nasledujúcich kapitolách popisujeme ako bolo rozšírenie projektu OPush testované. Testovaniu predchádzala inštalácia mailového servera a výber klientskej aplikácie na mobilnom zariadení. 9.1 Príprava testovania Na testovacie účely sme nainštalovali voľne dostupný mailový server hmailserver ( a vytvorili na ňom doménu hmailserver.local. V testovacej zostave nebol použitý DNS server, na tieto účely sme si vystačili s pridaním záznamu do súboru hosts. Ďalej boli v tejto doméne vytvorené dve kontá: test a test2. V databáze systému OPush, tabuľke UserObm bolo vytvorené jedno testovacie konto - test, ktorému boli priradené dve externé kontá - test@hmailserver.local a test2@hmailserver.local. Obsah tabuľky opush_external_account je uvedený v tabuľke Tabuľka 11 Obsah tabuľky opush_external_account Vzhľadom k tomu, že tabuľka UserObm má cca 60 stĺpcov, neuvádzam jej celý obsah, len niekoľko stĺpcov dôležitých pre našu prácu. Nachádzajú sa v tabuľke Tabuľka 12 Základné údaje z tabuľky UserObm. Pre tabuľku Domain uvádzam taktiež len relevantné stĺpce, v tabuľke Tabuľka 13. ID 1 2 OWNER 1 (ID z tabuľky UserObm) 1 (ID z tabuľky UserObm) DOMAIN hmailserver.local hmailserver.local USERNAME test@hmailserver.local test2@hmailserver.local PASSWORD test test INCOM_MAIL_HOST localhost localhost INCOM_MAIL_PROTOCOL imap imap INCOM_MAIL_PORT INCOM_MAIL_SECURE FALSE FALSE OUT_MAIL_HOST localhost localhost OUT_MAIL_PROTOCOL smtp smtp OUT_MAIL_PORT OUT_MAIL_SECURE FALSE FALSE Tabuľka 11 Obsah tabuľky opush_external_account USEROBM_ID 1 USEROBM_LOGIN test USEROBM_PASSWORD test Tabuľka 12 Základné údaje z tabuľky UserObm 47

59 DOMAIN_ID 1 DOMAIN_NAME Hmailserver.local Tabuľka 13 Základné údaje z tabuľky Domain Po naplnení databázy údajmi môžeme nastaviť mobilné zariadenie na pripojenie sa k serveru. Na testovacie účely bol použitý Smartphone od spoločnosti HTC. Telefón komunikoval so serverom cez bezdrôtovú sieť. Ako klientský program bol z pomedzi viacerých odskúšaných použitý TouchDown pre Android 2.0 (Obrázok 16) pre veľké množstvo nastavení a funkcií, ktoré poskytoval. Takmer ekvivalente dobrý klient, s ktorým sme sa stretli bol RoadSync (Obrázok 15), ten mal ale kratšiu dobu evaluácie ako TouchDown (TouchDown 30 dní, RoadSync 14 dní) preto nebol použitý pre finálne testovanie, len pre testovanie počas vývoja OPush rozšírení. Obrázok 16 Klient TouchDown ( x) Obrázok 15 Klient RoadSync ( 9.2 Nastavenie klienta Nastavenie klientskej aplikácie TouchDown je popísané v Prílohe C. 9.3 Testovanie Po nastavení klienta, pripojenia na server a nastavení adresárov na synchronizáciu, prebehli úspešne a podľa očakávaní (v súlade so špecifikáciou ActiveSync, popísané v kapitole 5.3). Overenie bolo vykonané kontrolou logov servera, skade sa dalo vyčítať, ktoré operácie prebehli a v akom poradí. 48

60 9.3.1 Test pripojenia na OPush server Očakávaný stav: Zariadenie sa pripojí na server a dostane od neho odpoveď. Reálny stav: Na obrázku Obrázok 17 je zachytená komunikácia servera s klientom, klient mal IP adresu a server Vidíme ako prišla HTTP požiadavka s metódou POST a bola odoslaná odpoveď s kódom 200, čo znamená úspešné spracovanie a odoslanie obsahu. Obrázok 17 Záznam odchytenej komunikácie OPush servera a mobilného zariadenia Test synchronizácie dát Očakávaný stav: Mobilné zariadenie sa pripojí na server a vykoná podľa ActiveSync špecifikácie operácie prislúchajúce kompletnej synchronizácií v správnom poradí, ako ukazuje Obrázok 18Obrázok 18 Ukážka komunikácie pri synchronizácií dát. Dáta, ktoré dostane budú zodpovedať, pre dané konto, stavu na mailovom serveri. Obrázok 18 Ukážka komunikácie pri synchronizácií dát Reálny stav: Z logov servera (Tabuľka 14) je vidieť, že mobilné zariadenie odoslalo HTTP požiadavky, ktoré server zaznamenal. Dáta na mobilnom zariadení zodpovedajú dátam na mailovom serveri (adresáre a ové správy) :20:38,003 Base64QueryString INFO - protoversion: 12.1 cmd: Provision locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android 49

61 :20:38,006 ActiveSyncServlet INFO - activesyncmethod: Provision :20:39,814 Base64QueryString INFO - protoversion: 12.1 cmd: GetItemEstimate locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :20:39,957 ActiveSyncServlet INFO - activesyncmethod: GetItemEstimate :20:41,237 Base64QueryString INFO - protoversion: 12.1 cmd: FolderSync locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :20: 41,239 ActiveSyncServlet INFO - activesyncmethod: FolderSync :20: 42,433 Base64QueryString INFO - protoversion: 12.1 cmd: Sync locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :20: 42,567 ActiveSyncServlet INFO - activesyncmethod: Sync Tabuľka 14 Vybrané záznamy z logov OPush servera - synchronizácia Test odoslania, preposlania a odpovedania na z mobilného zariadenia Očakávaný stav: Mobilné zariadenie sa pripojí na server a vykoná operácie SendMail, SmartReplay a SmartForward ako ukazuje Obrázok 19. Dáta, ktoré odošle budú zodpovedať, pre dané konto, stavu na mailovom serveri. Obrázok 19 Ukážka komunikácie pri odoslaní, odpovedaní a preposielaní u Reálny stav: Z logov servera (Tabuľka 15) je vidieť, že mobilné zariadenie odoslalo očakávané HTTP požiadavky, ktorou odoslalo na adresu :50:52,979 Base64QueryString INFO - protoversion: 12.1 cmd: SendMail locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android 50

62 :50:52,982 ActiveSyncServlet INFO - activesyncmethod: SendMail :53:39,455 Base64QueryString INFO - protoversion: 12.1 cmd: SmartReplay locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :53:39,457 ActiveSyncServlet INFO - activesyncmethod: SmartReplay :54:00,728 Base64QueryString INFO - protoversion: 12.1 cmd: SmartForward locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :54:00,731 ActiveSyncServlet INFO - activesyncmethod: SmartForward Tabuľka 15 Vybrané záznamy z logov OPush servera - SendMail, SmartReplay a SmartForward Test push notifikácie na mobilné zariadenie Očakávaný stav: Po nastavení push notifikácií na mobilnom zaradení, toto odošle požiadavku Ping so zoznamom adresárov, ktoré sa majú synchronizovať. Reálny stav: Z logov servera (Tabuľka 16) je vidieť, že požiadavka Ping bola zaznamenaná na serveri. Prijaté dáta zodpovedali očakávania :09:19,513 Base64QueryString INFO - protoversion: 12.1 cmd: Ping locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :09:19,516 ActiveSyncServlet INFO - activesyncmethod: Ping Tabuľka 16 Vybrané záznamy z logov OPush servera - Ping Test presunutia správy v rámci konta a medzi kontami Očakávaný stav: po vykonaní operácie presunutia správy na mobilnom zariadení sa táto správa vymaže zo zdrojového adresára a presunie do cieľového adresára. Reálny stav: Server OPush prijal požiadavku na vykonanie presunutia správy (Tabuľka 17) a spracoval ju podľa očakávaní :19:23,897 Base64QueryString INFO - protoversion: 12.1 cmd: MoveItems locint: 2308 devid: MzUzODMzMDQ0NDkyODk3 pkey: type: Android :19:23,976 ActiveSyncServlet INFO - activesyncmethod: MoveItems Tabuľka 17 Vybrané záznamy z logov OPush servera - MoveItems 51

63 10 Prínos riešenia a jeho overenie Zámerom je poskytnúť službu na báze otvoreného zdroja (OpenSource), ktorá by mala zjednodušiť používanie viacerých ových kont súčasne, a hlavne by mala by znížiť počet požiadaviek na server a tým aj znížiť objem prenášaných dát, čo sa prejaví na výdrži batérie zariadenia a v neposlednom rade aj na finančných nákladoch spojených s prenosom dát v mobilnej sieti. Výhoda spočíva aj v počte otvorených TCP spojení (ktorý je pri niektorých mobilných zariadeniach obmedzený), naše riešenie si vystačí s jedným TCP spojením pre všetky synchronizované kontá. V overovaní riešenia sledujeme objem prenesených dát, počet TCP spojení a úroveň napätia batérie. Sledujeme aj počet požiadaviek, ktoré musí mobilné zariadenie vykonať. Porovnávané sú dva módy v akých môže synchronizácia dát prebiehať, push a pull Porovnanie PUSH a PULL v reálnom nasadení Testovali sme synchronizáciu ov v nasledovnej konfigurácií: test PUSH: ActiveSync klient TouchDown s nastaveným OPush kontom a synchronizovaním štyroch externých kont, pre každé konto boli nastavené na push dva IMAP adresáre. test PULL: IMAP klient K-9 Mail s nastavenými tými istými štyrmi kontami, ktoré boli nastavené ako externé v prípade klienta TouchDown. Bol zakázaný IMAP push a nastavený interval obnovenia ov na 5 minút. Aby bolo porovnanie týchto prístupov čo najvernejšie, obom testom sme nastavili rovnaké podmienky: Test trval v oboch prípadoch dve hodiny a v intervale 10 minút bola na každé konto odoslaná jedna ová správa prvú hodinu a druhú hodinu po päť správ. Mobilné zariadenie neprijímalo žiadne telefónne hovory a nebola na ňom vykonávaná ani iná aktivita. Obom klientom bolo nastavené, že nemajú stiahnuť celé telo u, len hlavičky. Výsledky testovania sú zosumarizované v nasledujúcich grafoch a tabuľke. 52

64 IMAP pull ActiveSync push Začiatočné napätie batérie [V] 4,162 4,167 Konečné napätie batérie [V] 4,074 4,127 Počet prenesených bajtov Počet prenesených paketov Tabuľka 18 Výsledky testovania Obrázok 20 Priebeh testovania IMAP pull Obrázok 21 Priebeh testovania ActiveSync push 53

65 Obrázok 22 Vývoj napätia batérie pri IMAP pull Obrázok 23 Vývoj napätia batérie pri ActiveSync push Tabuľka 18 obsahuje celkové výsledky testovania, je z nej jasne vidieť, že predpoklady o protokole ActiveSync sa naplnili. Z grafov na obrázkoch: Obrázok 20, Obrázok 21 vyplýva, že ActiveSync bol stabilnejší prenosy dát sú viac predvídateľnejšie a pravidelnejšie. Vývoj napätí baterky pri oboch testovaniach je znázornená na obrázkoch: Obrázok 22, Obrázok 23, vidíme, že pri ActiveSync push sa začne baterka vybíjať neskôr. 54

66 11 Záver V tejto práci sme sa venovali problematike ako môžu byť mobilné zariadenia lepšie využité v náš prospech a ako môžu naše životy spraviť efektívnejšími. Model PUSH ako spôsob prístupu k dátam sa v súvislosti s mobilnými zariadeniami používa už dlhú dobu a vzniklo pomerne veľké množstvo rôznych technológií ako tento model implementovať. Vybrali a popísali sme tri protokoly WAP, SyncML a ActiveSync a tri formáty v akých sa dáta prenášajú XML, JSON a WBXML. Ďalej opisujeme dve open-source implementácie protokolu ActiveSync - O-Push a Z-Push. Po analýze dostupných technológií na realizáciu PUSH notifikácií sme si vybrali protokol ActiveSync a jeho implementáciu O-Push. Protokol ActiveSync nás zaujal hlavne relatívne nedávne zverejnenie jeho špecifikácie, veľkú základňu klientskych programov (dnes prakticky v každom novom mobilnom telefóne je vstavaný ActiveSync klientský program). Predstavuje konkurenciu pre IMAP protokol a to bola pre nás výzva. Návrh a implementácia rozšírenia projektu O-Push so sebou niesli ten problém, že projekt je veľmi slabo dokumentovaný. No s vedomosťami o protokole ActiveSync, ktoré sme nadobudli vo fáze analýzy, bolo aj spoznávanie projektu O-Push ľahšie. Projektu O-Push bola pridaná funkcionalita, ktorú sme nazvali Externé kontá. Bola vytvorená webová aplikácia, cez ktorú je možne zaregistrovať O-Push konto a k nemu niekoľko externých kont. Externé konto tvorí dvojica IMAP a SMTP server. Takto sú používateľovi transparentne prístupné IMAP adresáre zo všetkých externých kont, ktoré môže synchronizovať push prístupom. Medzi adresármi dvoch externými kont môže presúvať poštu, ako by boli na jednom IMAP konte. Tým, že klientske zariadenie sa reálne pripája len na jeden, O-Push server, šetrí naše riešenie: počet TCP spojení, počet požiadaviek, ktoré robí zariadenie, množstvo prenesených dát a energiu batérie mobilného zariadenia. Náš prínos sme overili v simulovanej prevádzke, kedy sme oba prístupy - IMAP pull aj ActiveSync push testovali po dve hodiny, odosielaním ových správ každých 10 minút. Overili sme všetky predpoklady - push prístupom sme ušetrili na energií batérie, na prenesených dátach, aj na počte požiadaviek, ktoré musel mobilný klient vykonať. Riešenie bolo testované s rôznymi klientskymi programami (TouchDown, RoadSync, Mail for Android) platformy Android a na natívnom klientovi telefónu IPhone. 55

67 12 Ďalšia práca Mojou prácou som dokázal, že je možná synchronizácia ov z externých kont do mobilného zariadenia a že je možné spraviť transparentnú zjednotenú ovú schránku pomocou protokolu ActiveSync. Štandardnou výbavou každého dobrého mobilného zariadenia je aj synchronizácia kalendára, kontaktov a úloh. Toto všetko podporuje aj protokol ActiveSync, preto by bolo vhodné rozšíriť môj prototyp aj o tieto druhy dát. 56

68 13 Referencie [1]. Engin Bozdag: A Comparison of Push and Pull Techniques for Ajax, ArXiv.org, 2007 [2]. J. P. Martin-Flatin: Push vs. Pull in Web-Based Network Management, ArXiv.org, 1998 [3]. Ivana Podnar, University of Zagreb; Manfred Hauswirth, EPFL; Mehdi Jazayeri, Technical University of Vienna, Mobile Push: Delivering Content to Mobile Users, Vienna, Austria, 2 Jul 2005,ISBN: [4]. Document Object Model, [5]. "Wireless Application Protocol Architecture Specification", WAP Forum, 30-April URL: [6]. WAP Binary XML Content Format, [7]. The application/json Media Type for JavaScript Object Notation (JSON), [8]. ECMAScript Documentation, [9]. The Unicode Consortium, [10]. Using JSON (JavaScript Object Notation) with Yahoo! Web Services, [11]. Using JSON in the Google Data Protocol, SK/apis/gdata/docs/json.html [12]. Exchange ActiveSync Protocols, [13]. Universal Naming Convention, [14]. Hypertext transfer protocol, [15]. Zarafa Deutschland GmbH, [16]. The Apache Software Foundation, [17]. Z-push, 57

69 [18]. Open Mobile Alliance, Wireless Application Protocol, [19]. Wireless Application Protocol Forum, 3. Júl 2001, WAP Push Architectural Overview, Ltd., a.pdf [20]. Wireless Application Protocol Forum, 12. Júl 2001, WAP Architecture, [21]. SyncML Representation Protocol, version 1.0.1, df [22]. Extensible Markup Language (XML) 1.0 (Fifth Edition), [23]. Roy Thomas Fielding, 2000, Architectural Styles and the Design of Network-based Software Architectures, [24]. XMLHttpRequest, [25]. The Extensible HyperText Markup Language, [26]. Cascading Style Sheets, [27]. Wireless Application Protocol Forum, , Wireless Markup Language, [28]. Multipurpose Internet Mail Extensions, [29]. PHP Home page, [30]. ActiveSync [31]. Windows mobile device center, 58

70 [32]. [MS-ASCMD]: ActiveSync Command Reference Protocol Specification, Microsoft Corporation, rok 2009, prevzaté z adresy: [33]. STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES, [34]. Projekt Zarafa, domáca stránka: [35]. Techinická dokumentácia: Messaging Application Programming Interface, [36]. Projekt OBM, domáca stránka: [37]. GPL: GNU Public License, [38]. O-Push domáca stránka projektu: [39]. Eclipse Server-Side Equinox: [40]. OSGi technológia, [41]. Vývoj Eclipse pluginov: [42]. Jetty contnuations: [43]. Google Android OS, domáca stránka: 59

71 Príloha A: Fyzický dátový model OPush Tabuľka 20 obsahuje všetky databázové tabuľky, ktoré sú v systému OPush použité pri implementácií protokolu ActiveSync. Tento model je vygenerovaný nástrojom SchemaCrawler ( a keďže ide o nástroj s anglickou lokalizáciou, uvádzam v Tabuľka 19 Slovník k fyzickému modelu krátky Anglicko - Slovenský slovník v kontexte relačných databáz. Anglický pojem table primary key foreign key update delete Slovenský ekvivalent Databázová tabuľka Primárny kľúč Cudzí kľuč Operácia nad dátami, ktorá vykoná ich zmenu, aktualizáciu. Výmaz dát cascade (on delete, on update) Kaskádové vykonanie definovanej operácie (výmazu, alebo aktualizácie) nad záznamom, ktorý je zviazaný s týmto záznamom cez cudzí kľúč. unique index not null Zoznam jedinečných hodnôt. Obmedzenie hovoriace, že atribút, resp. stĺpec musí nadobúdať hodnotu. Tabuľka 19 Slovník k fyzickému modelu 60

72 public.opush_device [table] id identifier owner type serial not null varchar(255) not null int4 varchar(64) not null opush_device_pkey [primary key] id ascending opush_external_account_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_external_account.d evice_id opush_folder_mapping_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_folder_mapping.dev ice_id opush_ping_heartbeat_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_ping_heartbeat.devi ce_id opush_sync_mail_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_sync_mail.device_id opush_sync_perms_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_sync_perms.device_ id opush_sync_state_device_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_sync_state.device_i 61

73 d opush_device_owner_fkey [foreign key, on update no action, on delete cascade] public.userobm.userobm_id owner public.opush_external_account id owner device_id domain username password incom_mail_host incom_mail_protocol incom_mail_port incom_mail_secure out_mail_host out_mail_protocol out_mail_port out_mail_secure [table] serial not null int4 int4 not null varchar(255) not null varchar(255) not null varchar(255) not null varchar(100) varchar(20) int4 bool varchar(100) varchar(20) int4 bool opush_external_account_pkey [primary key] id ascending opush_external_account_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id opush_folder_mapping_external_account_fkey [foreign key, with no action] id public.opush_folder_mapping.ext ernal_account 62

74 opush_external_account_owner_fkey [foreign key, on update no action, on delete cascade] public.userobm.userobm_id owner user_domain [unique index] username domain ascending ascending public.opush_folder_mapping id device_id collection external_account [table] serial not null int4 not null varchar(255) not null int4 opush_folder_mapping_pkey [primary key] id ascending opush_folder_mapping_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id opush_folder_mapping_external_account_fkey [foreign key, with no action] public.opush_external_account.id external_account opush_sync_mail_collection_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_sync_mail.collection _id opush_sync_state_collection_id_fkey [foreign key, on update no action, on delete cascade] id public.opush_sync_state.collectio n_id public.opush_invitation_mapping [table] 63

75 mail_collection_id mail_uid event_collection_id event_uid dtstamp status sync_key int4 int4 int4 varchar(512) timestamp varchar(512) varchar(512) public.opush_ping_heartbeat device_id last_heartbeat [table] int4 not null int4 not null opush_ping_heartbeat_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id unique_opush_ping_heartbeat_col_dev [unique index] device_id ascending public.opush_sec_policy [table] id device_password_enabled serial not null bool opush_sec_policy_pkey [primary key] id ascending opush_sync_perms_policy_fkey [foreign key, on update no action, on delete set null] id public.opush_sync_perms.policy public.opush_sync_mail [table] collection_id device_id int4 not null int4 not null 64

76 mail_uid int4 not null opush_sync_mail_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id opush_sync_mail_collection_id_fkey [foreign key, on update no action, on delete cascade] public.opush_folder_mapping.id collection_id public.opush_sync_per ms [table] owner device_id policy int4 int4 not null int4 opush_sync_perms_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id opush_sync_perms_policy_fkey [foreign key, on update no action, on delete set null] public.opush_sec_policy.id policy opush_sync_perms_owner_fkey [foreign key, on update no action, on delete cascade] public.userobm.userobm_id owner public.opush_sync_stat e [table] sync_key collection_id device_id last_sync varchar(64) not null int4 not null int4 not null timestamp not null 65

77 opush_sync_state_device_id_fkey [foreign key, on update no action, on delete cascade] public.opush_device.id device_id opush_sync_state_collection_id_fkey [foreign key, on update no action, on delete cascade] public.opush_folder_mapping.id collection_id opush_sync_state_sync_key_key [unique index] sync_key ascending unique_opush_col_dev [unique index] collection_id device_id ascending ascending Tabuľka 20 Fyzický model OPush 66

78 Príloha B: Používateľská príručka aplikácie RegisterAccount Aplikácia RegisterAccount umožňuje: 1. zaregistrovanie OPush konta (toto konto sa nastavuje v mobilnom zariadení na prihlásenie na OPush server) 2. pridanie externého konta 3. zobrazenie zoznamu externých kont Na úvodnej stránke (Obrázok 24) nájdeme menu pre vstup do aplikácie a registráciu. Po kliknutí na linku Register, zobrazí sa formulár (Obrázok 25) na zadanie prihlasovacieho mena, hesla a domény pre OPush konto. Obrázok 24 Úvodná stránka Obrázok 25 Registrácia OPush konta 67

79 Po registrácií OPush konta sa môžeme prihlásiť do aplikácie kliknutím na linku Enter application. Zobrazí sa nám menu na prezeranie externých kont: View your accounts a pre pridanie nového externého konta: Add new account. Obrázok 26 Menu pre prácu s externými kontami Po kliknutí na linku View your accounts sa nám zobrazí tabuľka s informáciami o každom konte(obrázok 27): prihlasovacie meno, mailová adresa, protokol, názov servera, port a zabezpečenie pre prichádzajúcu a odchádzajúcu poštu. Obrázok 27 Zobrazenie externých kont Po kliknutí na linku Add new account sa zobrazí formulár s údajmi o externom konte(obrázok 28). Po vyplnení údajov (v tejto verzií aplikácie sú prednastavené: imap a port 143 pre prichádzajúcu poštu a smtp a port 25 pre odchádzajúcu poštu) a stlačení tlačidla Add sa vstupné údaje skontrolujú: server sa pokúsi vytvoriť spojenie na zadaný mailový server pre prichádzajúcu poštu a pokúsi sa poslať cez server odchádzajúcej pošty. Ak sa podaria obe operácie, vytvorí sa externé konto a používateľovi sa zobrazí informácia o úspešnom vytvorení. 68

80 Obrázok 28 Pridanie nového externého konta 69

81 Príloha C: Nastavenie mobilného klienta TouchDown Sériou obrazoviek z aplikácie TouchDown ukážeme ako bolo nastavené spojenie so serverom, aké možnosti bolo vhodné nastaviť, aby sme využili maximálny potenciál práce s viacerými kontami. Menu aplikácie je dostatočne intuitívne a tak používateľ rýchlo nájde menu s nastavením pripojenia na server, ktorému sa venujeme na prvom mieste. Na obrázku Obrázok 29 sú zobrazené nastavenia pripojenia na OPush server: OPush Login ID - je v tvare doména\meno, kde o o doména je z tabuľky Domain a meno z tabuľky UserObm Address - tvare meno@doména (podobne ako Login ID) Server Name - je možné zadať aj IP adresu, v tomto prípade je to privátna adresa v rámci testovacej bezdrôtovej siete. Uses SSL - odškrtnuté, pretože na serveri nie je nastavené SSL checking frequency - je možné zadať interval v minútach, alebo Push, kedy je udržiavané spojenie so serverom o nových dátach prichádza push notifikácia. ostatné nastavenia môžu ostať ako boli predvolené 70

82 Obrázok 29 Nastavenie pripojenia na server Na obrázku Obrázok 30 Adresáre vybraté na synchronizáciu máme k dispozícií možnosť ako vybrať adresáre na synchronizáciu. Nemusíme teda synchronizovať celé konto, ale len adresáre, ktoré nás zaujímajú. V tomto prípade sme vybrali INBOX z oboch kont. kontám poskytuje pohľad na všetky dostupné adresáre z oboch testovacích kont. Obrázok 30 Adresáre vybraté na synchronizáciu Obrázok 31 Zoznam adresárov z oboch testovacích kont Takto sme úspešne nastavili pripojenie na server, nastavili push notifikácie a vybrali, ktoré adresáre chceme synchronizovať. 71