OMA DATA SYNC Filip Jarończyk, Mateusz Klimek. Co to jest OMA Data Sync: Protokół używający wiadomości zapisanych w SyncML Cele: Synchronizacja danych.

Prezentacja na temat: "OMA DATA SYNC Filip Jarończyk, Mateusz Klimek. Co to jest OMA Data Sync: Protokół używający wiadomości zapisanych w SyncML Cele: Synchronizacja danych."— Zapis prezentacji:

1 OMA DATA SYNC Filip Jarończyk, Mateusz Klimek

2 Co to jest OMA Data Sync: Protokół używający wiadomości zapisanych w SyncML Cele: Synchronizacja danych sieciowych z dowolnym urządzeniem mobilnym i odwrotnie Cechy: może używać dowolnego protokołu komunikacji, i sieci można wymieniać dane dowolnego typu niezależny od aplikacji i ich danych musi działać na urządzeniach z ograniczoną ilością pamięci musi być w stanie zsynchronizować dowolne urządzenia

3 SyncML SyncML SyncML (ang. Synchronization Markup Language) Definicja z wikipedi: Protokół synchronizacji danych stworzony przez organizację Open Mobile Alliance (OMA). Wiadomości SyncML przesyłane są w formacie XML.

4 Podstawy Protokołu

5 Logi ● Protokół wymaga aby klient i serwer pamiętały w logach: ● jakie zmiany zaszły pomiędzy synchronizacjami z każdym urządzeniem ● Dodanie nowych danych ● Modyfikacja danych ● Usunięcie danych ● Log zmiany zawiera tez unikatowy identyfikator obiektu danych ●

6 Podstawy SyncML Wiadomości SyncML są prośbami o wykonanie jakiejś czynności: -synchronizacji danych -sprawdzenia danych - uaktualnienia stanu -obsługi błędów powstałych przy wykonywaniu czynności czy wysyłaniu wiadomości (zagubienie wiadomości )

7 Sync Anchors ● Pozwalają na sprawdzanie poprawności synchronizacji ● Dwa rodzaje Sync Anchor: ● Last sync anchor opisuje ostatnie wydarzenie synchronizacji np. czas synchronizacji. ● Next sync anchor opisuje obecne zdarzenie synchronizacji ● Serwer i klient wysyłają sobie nawzajem oba sync anchors i porównują czy poprzedni przysłany next sync anchor jest identyczny z nowoprzysłanym last sync anchor

8

9 SyncML Wiadomość Sync Header ( ) ● Zawiera Meta dane takie jak docelowa oraz źródłowa baza danych (, ) ● Informacja wymagane do uwierzytelnienia ( ) ● ID sesji ● ID Wiadomości ● SyncML wersje Ciało ● Zwiera dane dotyczące żądania

10 SyncML mapowanie ● SyncML klient przyznaje każdemu obiektowi unikalny identyfikator (LUID) ● SyncML Serwer przyznaje każdemu obiektowi unikalny identyfikator (GUID) ● LUID jest zawsze nadawany przez klienta i wysyłany do serwera ● Serwer może nadać tymczasowy LUID kiedy wysyła coś nowego do klienta ● Serwer wysyłając wiadomości do klienta używa LUID

11

12 Cache operacji mapowania ● Kiedy klient otrzymuje nowe dane od serwera, tworzy nowe LUID-y ● Klient zazwyczaj natychmiast informuje serwer jakie są nowe LUID-y ● Jeśli serwer wcześniej informował że nie wymaga odpowiedzi na na jego sync to klient może wysłać nowo stworzone LUID-y na początku następnej synchronizacji

13 Rozwiązywanie konfliktów ● Konflikty powstają kiedy te same dane na kliencie i serwerze zostaną zmodyfikowane ● Zazwyczaj serwer rozwiązuje konflikty i informuje o tym klienta ● Konflikt może być rozwiązany na kilka sposobów: ● Połączenie danych ● Dane klienta „wygrały” ● Stworzenie kopi danych

14 Adresowanie ● Adresowanie urządzenia lub serwisu w nagłówku jest zrobione przy pomocy URI http://www.syncml.org/sync-server ● Urządzenia które są połączone tymczasowo mogą się adresować w inny sposób np. IMEI:493005100592800 ● Adresowanie na poziomie warstwy transportu (np. http) jest niezależne od adresowanie użytego w SyncML

15 Adresowanie baz danych Jak poprzednio adresowanie używa URI np:..../calendar/james_bond... http://www.syncml.org/sync-server/calendar/james_bond...

16 Adresowanie danych Adresowanie odbywa się przez używanie LUIDS... 101...

17 Wymiana informacji o możliwościach urządzeń ● Klient wysyła informacje o swoich możliwościach: ● Podczas pierwszej synchronizacji ● Kiedy jego możliwości się zmieniły ● Kiedy serwer poprosi o to ● Serwer wysyła informacje kiedy klient prosi oto ● Serwer musi wykorzystywać informacje o możliwościach klienta np. podczas tworzenia tymczasowego LUID

18 Zarządzanie pamięcią urządzenia ● Rozmiar wolnej pamięci może być wysyłany podczas każdej synchronizacji zarówno przez klienta oraz serwera. ● Serwer musi używać informacji o wolnej pamięci klienta podczas komunikacji

19 Przykład wiadomości z informacją o pamięci 1./calendar/james_bond./dev-calendar 8100 <!--Free memory (bytes) in Calendar database on a device → 81......

20 Refresh sync od klienta Klient wysyła wszystkie dane do serwera a serwer zastępuje swoje dane nowo przybyłymi danymi

21 Jednostronna synchronizacja od klienta Klient wysyła zmiany do Serwera ale serwer nie wysyła zmian do klienta

22 Jednostronna synchronizacja od serwera Klient otrzymuje zmiany od serwera ale nie wysyła swoich zmian

23 Refresh sync od serwera Serwer wysyła wszystkie dane do klienta i klient zastępuje swoje dane danymi z serwera.

24 Serwera Alert Sync Serwer prosi klienta o określony rodzaj synchronizacji Klient inicjuje synchronizacje

25 Jak wygląda obustronna synchronizacja

26 Przykład modyfikacji danych przez klienta 1.2 SyncML/1.2 4 2 http://www.syncml.org/sync- server IMEI:493005100592800 1 1 0 SyncHdr IMEI:493005100592800 http://www.syncml.org/sync-server 212 2 1 5 Alert./dev-contacts./contacts/james_bond 200 20040120T093223Z 3./contacts/james_bond./dev-contacts 8100 81 1 4 text/x-vcard 1012

27 Zmiany od serwera do klienta 1.2 SyncML/1.2 4 2 IMEI:493005100592800 http://www.syncml.org/sync- server 1 2 0 SyncHdr http://www.syncml.org/sync-server IMEI:493005100592800 200 2 2 3 Sync./contacts/james_bond./dev-contacts 200 3 2 4 Replace 1012 200 4./dev-contacts./contacts/james_bond 2 5 text/x-vcard 1023 6 text/x-vcard 10536681

28 Status aktualizacji danych do serwera 1.2 SyncML/1.2 4 3 http://www.syncml.org/sync- server IMEI:493005100592800 1 2 0 SyncHdr IMEI:493005100592800 http://www.syncml.org/sync-server 200 2 2 4 Sync./dev-contacts./contacts/james_bond 200 3 2 5 Replace 1023 200 4 2 6 Add 10536681 200 5./contacts/james_bond./dev-contacts 10536681 1024

29 Potwierdzenie Mapowania od serwera 1.2 SyncML/1.2 4 3 IMEI:493005100592800 http://www.syncml.org/sync-server 1 3 0 SyncHdr http://www.syncml.org/sync-server IMEI:493005100592800 200 1 3 5 Map./contacts/james_bond./dev-contacts 200

30 Źródła OMA-TS-DS_Protocol-V1_2_1-20070810-A – Specyfikacja OMA DS http://en.wikibooks.org/wiki/XML_- _Managing_Data_Exchange/SyncML

31 Inicjalizacja ● Cele inicjalizacji ● Dokonanie autoryzacji klienta ● Odkrycie jakie bazy mogą być synchronizowane oraz jakie typy protokołów mogą zostać użyte ● Wymiana obsługiwanych formatów, informacji itp. (capabilites)

32 Inicjalizacja ● 1 punkt jest wykonywany dołączanie klient – będzie w przykładzie ● 2 punkt jest wykonywany przez dodawanie alert do każdej z synchronizowanych baz danych ● 3 punkt jest realizowany poprzez Put oraz Get ● Put oznacza podanie informacji o urządzeniu ● Get oznacza zapytanie o takie informacje drugiego urządzenie ● Put i Get mogą wysyłać zarówno serwer jak i klient

33 Inicjalizacja

34

35 Wymagania ● Klient musi w inicjalizacji poinformować serwera jakie bazy chce synchronizować oraz jakie typ połączenia chce użyć, może co nie jest wymagane podać swoje „capabilites” oraz informacje do autoryzacji ● Serwer po otrzymaniu komunikatu powinien odpowiedzieć komunikatem z sync anchors, informacjami o urządzeniu oraz informacjami o tożsamości

36 Exchange device capabilities ● Wymiana informacji „capabilities” odbywa się w fazie inicjalizacji połączenia ● Wymieniane informacje to np. obsługiwane typy danych (np. VCARD wersja), informacje o typach danych poszczególnych baz, itp.

37 Exchange device capabilities ● Urządzenie(Klient) musi wysłać swoje „capablities” w czasi swojej pierwszej synchronizacji z serwerem oraz kiedy informacje o urządzeniu się zmieniły ● Klient musi być w stanie wysłać swoje „capabilites” jeśli serwer o nie poprosi ● Klient powinien umieć przetworzyć takie „capabilites” wysłane przez serwer ● Serwer musi być w stanie przetworzyć informacje „capabilities” wysłane przez klienta ● Sewer musi być w stanie wysłać swoje „capabilites” jeśli klient o nie poprosi

38 Implementacja ● Wymiana „capabilites” może wymagać przesyłania dużej ilości informacji dlatego urządznia powinny unikać przesyłania takich informacji przy każdej inicjalizacji ● Urządzenia powinny także podczas wymiany informacji unikać przysyłania niepotrzebnych informacji (informacji o obsłudze „capabilites” nie obsługiwanych przez drugą stronę

39 Autoryzacja ● 2 typy autoryzacji ● Prosta – Przesłanie hasła w odpowiednim formacie ● MD5 – Polega na utworzeniu skrótu MD5 z hasła, nazwy użytkownika oraz podanego przez serwer pewnego wymyślonego słowa (ang. nonce) ● Oba typy muszą być wspierane przez urządzenia

40 Autoryzacja ● Jeśli odpowiedź serwera na żądzanie zawiera „status code” równy 401 (Unauthorized) bądź 407 (Authentication requied) to znaczy że dane żądanie wymaga autoryzaji ● Pole Status odpowiedzi serwera musi w takim razie zawierać element Chal (Będzie widać w przykładzie) ● Status code nazywany jest odpowiedzią

41 Autoryzacja - Odpowiedź ● Jeśli odpowiedź na żądanie to 212 ('Authentication accepted') to dla tej sesji synchronizacji nie potrzebne jest już autoryzacja ● Jeśli używany typ synchronizacji to MD5 to w odpowiedzi może również występować element Chal z elementem next nonce który w takim razie musi zostać użyty podczas następnej inicjalizacji połączenia ● Jeśli odpowiedź na żądanie to 200 to w następnym żądaniu trzeba ponownie dodać element Cred z tymi samymi danymi jak poprzednio, wyjątkiem jest sytuacja kiedy typ synchronizacji to MD5 oraz odpowiedź zawiera element next nonce wtedy w skrócie MD5 należu użyć tego elementu.

42 Przykład prostej autoryzjacji ● Klient wysyła wiadomość bez credentials

43 Odpowiedź serwera

44 Klient się autoryzuje

45 Serwer autoryzuje klienta `

46 MD5 Autoryzacja – Odp. Serwera

47 MD5 Autoryzacja - Klient

48 Obsługa błędów ● Jeśli klient wysłał pakiety synchronizacyjny ale nie otrzymał kompletnej odpowiedzi od serwera, to klient musi założyć że pakiet nie doszedł do serwera i wysłać go ponownie ● Jeśli serwer wysłał pakiet do klienta i nie otrzymał kompletnej odpowiedzi serwer musi założyć że pakiet nie doszedł do klienta, serwer może zerwać sesje tak że przy następnym połączeniu ponownie będzie wymagana inicjalizacja.

49 Network Address Book Celem Network Address Book jest dostarczyć zcentralizowany i jednolity mechanizm do zarządzania swoimi kontaktami w sieciach obsługujących RCS Sercem NAB jest sieciowe repozytorium które jest w sieci operatora, jest ono zarządzane i utrzymywane przez operatora.

50 Enhanced Address Book Książka adresowa aplikacja pokazująca informację o znajomych. Pobiera dane z repozytorium NAB oraz dodaje do nich informacje o dostąpności (presence information)

51 Enhanced Address Book ● Używa protokołu SIMPLE dla dostarczenia „presence information” czyli informacji o dostępności oraz o usługach obsługiwanych przez innych.

52 Użycie ● Z poziomu EAB(Enhanced Address Book) użytkownik może edytować (tworzyć, kasować) informację o swoich kontaktach i załadować je do repozytorium ● Użytkownik jest właścicielem swoich informacji o kontaktach i tylko on może jest edytować ● Po załadowaniu informacji do repozytorium użytkownik może synchronizować się z nim także przy pomocy innych urządzeń np. PC

53 NAB Wymagania ● Możliwość synchronizacji lakalnych danych o kontaktach z repozytorium ● Dodawanie, edytowanie i usuwanie informacji o kontaktach na lokalnej kopii danych ● Beckapowanie danych oraz odtwarzenie danych z repozytorium

54 Komponenty ● NAB jest oparte na OMA DS i składa się z następujących komponentów ● Urządzenie które posiada OMA Data Sync Client, jest używany do wysyłania i otrzymywania Data synchronization requests / responses ● OMA DS Server który zawiera Data Sync Server, otrzymuje wiadomości do synchronizacji odpowiada na nie do urządzenie (Data Sync Clienta) ● Network Repository, repozytorium kontaktów użytkownika w sieci ● Może zawierać „notification entity” które Server może wykorzyć do spowodowania rozpoczęcia synchronizacji przez urządzenie

55 Architektura NAB

56 Użycie Aby użycie Network Address Book było możliwe operator powinien dostarczyć do użytkownika (urządzenia) adres usługi

57 Autoryzacja ● Możliwe różne typy autoryzacji ● Prosta – Np. Dodanie MSIDN wykrytego przez sieć operatora do nagłówka HTTP w HTTP/SyncML request. ● MD5 – Zgodna z specyfikacją MD-5 w OMA DS (server-based challenge to authentication)

58 Pierwsza synchronizacja ● Przy pierwszej synchronizacji urządzenie oraz serwer powinny wymienić między sobą takie rzeczy jak ● Identyfikator ● Wspierane metody synchronizacji ● Bazy danych ● Formaty danych wspierana dla tych baz ● I inne tak jak zdefiniowano w OMA DS

59 Pierwsza synchronizacja Użytkownik powinien wykonać pierwszą synchronizację inicjując Full Sync (Slow Sync) tak jak zdefiniowano ją w OMA DS

60 Synchornizacja ● Użytkownik powinien móc zmieniać swoją lokalną kopie (dodawać, edytować) inicjując Two-way sync po to aby wymieniać z serwerem informację o modyfikacjach ● Powinen mieć możliwość backupu danych poprzez zainicjowanie Refresh sync from client only – klient wysyła całą swoją bazę do serwera a on ją zapisuje jak własną ● Powinen mieć możliwość odzyskania backapowanych danych poprzez zainicjowanie Refresh sync from server only – serwer wysył dane do klienta on zapisuje je jako własne

61 Synchronizacja Synchronizacja danych według preferencji użytkownika lub ustawień operatora może być ręczna lub wykonywana w jakimś odstępie czasu np. dziennie

62 Notification ● Serwer sam nie może rozpoczynać synchronizacji może jednak dostarczyć do Klienta powiadomienie o tym aby to on rozpoczął jakiś wybrany rodzaj synchronizacji. Jeśli urządzenie otrzyma „powiadomienie” to powinno rozpocząć synchronizację. ● Żeby takie powiadomienie było możliwe urządzenie musi wspierać notification event package tak jak w OMS DS - struktura tego pakietu jest opisana w specyfikacji tego protokołu ● Serwer nie dostarcza „powiadomienia” bezpośrednio. Najpierw dostarcza je do „Notification entity”, które później dostarcza je do urządzenia

63 Notification ● Serwer powinien dostarczyć informacje jakiego rodzaju synchronizacji oczekuje

64 Suspend, Resume ● RSC NAB powinien wpierać funkcje Suspend oraz Resume tak jak to zdefiniowano w OMA DS Specyfication ● Możliwe przyczyny ● Utrata zasiągu sieci ● Uszkodzenie telefonu ● Chęć urzytkownika ● Daje możliwość powrotu do poprzedniego stanu synchronizacji bez ponownej inicjalizacji połączenia ● Nie zawsze jest to możliwe

65 File transfer ● Powinien używać protokołu MSRP do przesłania plików tak jak jest to zdefiniowane w IM ● Opis protokołu w specyfikacji rozdział file transfer http://www.openmobilealliance.org/Technical/release_program/docs/S IMPLE_IM/V1_0-20080903-C/OMA-TS-SIMPLE_IM-V1_0-20080903- C.pdf ● Nie jest zależny od innych usług może być wykonywany zarówno podzczas innych sesji jak i bez nich ● Urządzenie może wykorzystać informacje z EPB (Enhanced Phone Book) aby stwierdzić czy inne urządzenie absługuje możliwość wymiany plików

66 RCS Architektura

67 ● UNI – User Netowork Interfejs ● NNI – Network Network Interejs

68 RCS, główne części

69 Źródła ● Rich Communication Suite Release 1Technical Realization 1.2 ● Rich Communication Suite Release 1 Functional Description 1.0 ● OMA-TS-DS_Protocol-V1_2_1-20070810-A – Specyfikacja OMA DS ● http://en.wikibooks.org/wiki/XML_- _Managing_Data_Exchange/SyncML