SyncML

SyncML este o abreviere pentru Synchronization Mark-up Language și este de fapt o specificație pentru sincronizarea datelor .

Specificația constă în principal dintr-un protocol de reprezentare bazat pe XML și un protocol de sincronizare, precum și conexiunile sale exemplare la HTTP , OBEX și WSP .

Datele pot fi în orice format, atât timp cât sunt înregistrate sau reprezentabile în MIME .

SyncML a fost publicat pentru prima dată în decembrie 2000 de inițiativa SyncML , care a fost formată ca o societate mixtă non- profit în februarie 2000, cu sponsori originali, inclusiv Ericsson , IBM , Lotus , Matsushita , Motorola , Nokia , Palm și Psion , iar în noiembrie 2002 a crescut în Open Mobile Alliance .

O formă specială de SyncML este SyncML-DM ( SyncML pentru gestionarea dispozitivelor ), care definește funcțiile de întreținere la distanță pentru dispozitivele mobile cu ajutorul cărora un server poate gestiona configurațiile și actualizările de software.

Independența platformei

Orice dispozitiv cu un client compatibil SyncML poate sincroniza datele cu un server compatibil SyncML, indiferent de sistemul de operare și de producător. Dispozitivele finale tipice dintre care datele pot fi comparate sunt computerele , telefoanele mobile și computerele portabile .

Sincronizarea datelor

Sincronizarea datelor este practic procesul prin care două dispozitive finale diferite (indiferent dacă sunt telefoane mobile, dispozitive portabile sau laptopuri sau PC-uri) sincronizează datele între ele. Se recunoaște ce dispozitiv terminal are ce date și se verifică, de asemenea, dacă celălalt dispozitiv terminal respectiv dorește să aibă aceste date pe lângă propriile date. În cazul în care ambele terminale au același conținut de date, numai în versiuni diferite (de exemplu, dacă o adresă a fost modificată pe o parte), se poate defini ce modificare este reținută.

Folosind mesaje SyncML, clienții schimbă date pentru sincronizare cu un server. De obicei, clientul inițiază întotdeauna începutul unei sincronizări. Doar o versiune viitoare 1.3 ar trebui să permită o împingere reală de la server la client. Mesajele SyncML au o structură foarte asemănătoare cu mesajele de e-mail obișnuite. Există un antet cu informații despre receptor și expeditor și ID-uri de sincronizare care sunt unice pentru server. Capul este urmat de comenzile de sincronizare pentru adăugarea, ștergerea și înlocuirea datelor.

exemplu

Alice și Bob au fiecare un telefon mobil și sunt angajați ca lucrători de teren de la aceeași companie. Această companie gestionează toate datele clienților la nivel central pe un server.

Alice ajunge acum să cunoască un client Dave și își salvează numărul de telefon și numele în telefonul mobil. Telefonul mobil al Alicei transmite automat noua intrare către serverul companiei centrale, care acum stochează noul contact central. Acum, serverul trimite intrarea pe telefonul mobil al lui Bob imediat după ce telefonul mobil al lui Alice a anunțat intrarea pe server. Serverul a sincronizat astfel conținutul datelor între Alice și Bob. Acest lucru funcționează și cu mai mult de doi participanți.

Dacă numărul lui Dave se schimbă, Alice îl schimbă pe telefonul său mobil și, la sincronizare, este modificat și pe serverul central al companiei și apoi este transferat și pe dispozitivul lui Bob în timpul sincronizărilor ulterioare.

Provocări

Există câteva probleme cu modul în care funcționează SyncML:

• Cum știe serverul central 100% ce contact trebuie să actualizeze atunci când Alice schimbă numărul unui contact de pe telefonul său mobil?
• Cum poate serverul să fie sigur că a avut loc o modificare? Adică, ce date ar trebui comparate?
• Ce se întâmplă dacă Alice și Bob modifică numărul de telefon al lui Dave într-o perioadă scurtă de timp? Al cărui număr este considerat apoi cel „corect” și este sincronizat între toți ceilalți angajați?
• Ce ar trebui să se întâmple dacă un nou angajat introduce numeroase numere private în telefon - acestea ar trebui să fie încărcate cu adevărat pe serverul central și astfel să fie accesibile tuturor celorlalți?
• Pe scurt: ale cui date ar trebui sincronizate când și între cine?

Pentru a putea rezolva aceste probleme, există câteva concepte avansate pentru procesul de sincronizare.

Concepte

Următoarele concepte trebuie implementate în scopul sincronizării funcționale a datelor:

• Gestionarea ID-ului : servește pentru identificarea unică a unei înregistrări de date (de exemplu, intrarea de contact). Acesta este implementat folosind un ID unic (date de identificare - de obicei un număr). În acest fel, serverele și dispozitivele finale (telefoane mobile și așa mai departe) pot recunoaște dacă, de exemplu, două contacte de pe două dispozitive sunt aceleași sau nu.
• Detectarea modificărilor : Când se consideră modificată o înregistrare de date? Este suficient dacă prenumele este scris în mod diferit sau întregul număr de telefon trebuie să fie unul nou? Aceasta definește detectarea modificării, care funcționează de obicei și cu un timestamp (punct specific în timp - dată, inclusiv ora) pentru a defini punctul în timp al schimbării.
• Schimb de modificări : Cum se face o schimbare? Ar trebui șters, înlocuit sau recreat? Toate acestea sunt definite aici.
• Detectarea conflictelor : acest concept are grijă de detectarea cazurilor descrise mai sus, cum ar fi schimbarea simultană a diferitelor date sau ale căror date ar trebui sincronizate.
• Rezolvarea conflictelor : Aici se decide modul în care conflictul identificat mai sus trebuie rezolvat, în mod liber, în conformitate cu principiul: „primul venit, primul servit” sau „ultimul câștig” - adică al cărui set de date ar trebui să servească drept referință pentru Actualizați.
• Sincronizare lentă și rapidă : ar trebui să fie comparate doar datele care s-au schimbat de la ultimul proces de sincronizare completă sau toate?

Aceasta este doar o prezentare generală a conceptelor - este inclusă din motive de completitudine.

Sistem

Structura protocolului SyncML, sursă: www.tecchannel.de

Cu SyncML, dispozitivele primesc un protocol de schimb uniform. Acest lucru funcționează independent de tipul dispozitivului și de calea de transmisie: astfel încât diferite tipuri de dispozitive precum PDA-uri, dispozitive portabile, telefoane mobile, camere și PC-uri să își poată schimba datele cu protocolul de sincronizare, SyncML acceptă protocoale stabilite precum HTTP, WSP (Wireless Session Protocol, parte a protocolului WAP) și OBEX pentru conexiunile Bluetooth și IrDA.

comunicare

Procedură de bază pentru o sincronizare între server și client, sursă: www.syncml.org

Următorul grafic este destinat să arate procesul de sincronizare între un server și un client. Puteți vedea clar că atât serverul, cât și clientul au o interfață SyncML, care permite schimbul de date fără probleme.

Datele convertite SyncML sunt transmise de la server către client și invers prin orice protocol - acesta poate fi HTTP (TCP / IP), WSP (WAP) sau OBEX (Bluetooth, infraroșu).

Agentul Sync Client inițiază un proces de sincronizare bazat pe protocolul SyncML și gestionează procesele de transfer din partea clientului. Pe cealaltă parte a clientului, Agentul de sincronizare a serverului așteaptă o cerere de sincronizare.

Motorul de sincronizare efectuează o analiză și verifică ce date trebuie modificate. Pentru a face acest lucru, ea deschide și modifică bazele de date, reacționează la modificările din calendarul întâlnirilor sau actualizează folderele din programul de e-mail.

Utilizare

Din partea clientului, aceasta înseamnă practic partea utilizatorului final - și, astfel, partea mobilă - SyncML stăpânește tipurile de date care apar în e-mail, intrări de calendar, directoare de adrese și documente. În același timp, SyncML este atât de flexibil încât noile formate pot fi integrate cu puțin efort. În detaliu, protocolul face următoarele:

• Permite comunicarea datelor prin rețele cu fir, rețele radio și conexiuni în infraroșu.
• Suportă o mare varietate de protocoale de transport și formate de date.
• Permite accesul la date de pe mai multe dispozitive diferite.
• Ține cont de resursele limitate ale sistemelor mobile în ceea ce privește memoria și puterea de procesare.
• Se bazează pe tehnologii de rețea dovedite.
• Suportă acele funcții de sincronizare pe care le utilizează cât mai multe sisteme.

In practica

Între timp, SyncML (OMA DS) s-a impus ca standard pentru compararea datelor despre întâlniri, contact și alte date PIM , dar în practică există încă provocări:

• Spre deosebire de implementările IMAP pentru e-mailuri, relativ puține aplicații desktop au acceptat până acum SyncML. Microsoft Outlook sau Mozilla Thunderbird , de exemplu, au nevoie de pluginuri suplimentare pentru a sincroniza datele calendarului sau de contact cu un server în acest mod. Majoritatea telefoanelor mobile ale dispozitivelor mobile actuale acceptă acest standard; pe smartphone-urile cu sisteme de operare Android, Windows Mobile, Blackberry sau Apple iOS, acesta trebuie să fie modernizat utilizând o aplicație suplimentară.

• Programele existente pentru server și client, în special de la diferiți dezvoltatori, nu comunică întotdeauna fără probleme între ele, ceea ce se datorează parțial implementărilor imature. În unele constelații, sincronizarea nu funcționează deloc, doar după o configurație complexă sau incorect (printre altele, se formează duplicate ).

Acum există soluții care stăpânesc comparația inteligentă a datelor cu rezolvarea duplicatelor și a conflictelor și ușurează utilizatorul de cea mai mare parte a activității.

• În Germania, toți furnizorii majori de telefonie mobilă și furnizorii de internet se bazează acum pe servicii de backup și sincronizare a datelor bazate pe SyncML, în special T-Mobile cu MyPhonebook, Vodafone cu MeinAdressbuch, o2 cu Centrul de comunicații, Mobilcom cu MSync Service sau T -Acasă (T-Online) cu serviciul de sincronizare a datelor. Astfel de servicii sunt deja stabilite și în alte țări, de exemplu cu agenda A1 la Mobilkom Austria sau agenda Orange în Austria, precum și sincronizarea agendei de mesagerie online la O2 Ireland.

Dovezi individuale

1. ↑ ^{a b} Definiția versiunii Enabler pentru specificațiile comune SyncML. (PDF; 91 KB) Open Mobile Alliance, 24 iulie 2009, accesat la 11 februarie 2018 . 
2. ↑ SyncML WSP Binding, versiunea 1.1. (PDF; 97 KB) Open Mobile Alliance, 15 februarie 2002, accesat la 11 februarie 2018 . 
3. ↑ ^{a b} Istoricul modificărilor standardelor OMA DS. (PDF; 111 KB) Open Mobile Alliance, 31 martie 2008, accesat la 11 februarie 2018 . 

Link-uri web

• Specificațiile curente SyncML (v1.2.2) ale OMA (engleză)
• SyncML Reference Toolkit (engleză)