SyncML
SyncML ist eine Abkürzung von Synchronization Mark-up Language und faktisch eine Spezifikation zur Datensynchronisation.[1]
Die Spezifikation besteht hauptsächlich aus einem XML-basierten Repräsentationsprotokoll und einem Synchronisationsprotokoll sowie dessen exemplarischen Bindungen an HTTP, OBEX und WSP.[1][2]
Bei den Daten kann es sich um beliebige Formate handeln, soweit sie in MIME registriert oder repräsentierbar sind.[3]
SyncML wurde zuerst im Dezember 2000 von der SyncML Initiative veröffentlicht, die im Februar 2000 als Gemeinschaftsunternehmen ohne Gewinnerzielungsabsicht gegründet worden war, beispielsweise Ericsson, IBM, Lotus, Matsushita, Motorola, Nokia, Palm und Psion als ursprüngliche Sponsoren hatte, und im November 2002 in der Open Mobile Alliance aufging.[3]
Eine Spezialform von SyncML ist SyncML-DM (SyncML for Device Management), das Fernwartungsfunktionen für mobile Endgeräte definiert, womit ein Server Konfigurationen und Softwareaktualisierungen verwalten kann.
Plattformunabhängigkeit
Jedes beliebige Gerät mit einem SyncML-konformen Client kann Daten mit einem SyncML-fähigen Server abgleichen, unabhängig von Betriebssystem und Hersteller. Typische Endgeräte, zwischen denen Daten abgeglichen werden können, sind PC, Mobiltelefone und Handcomputer.
Datensynchronisation
Datensynchronisation ist grundsätzlich der Vorgang, bei dem zwei verschiedene Endgeräte (egal ob zum Beispiel Mobiltelefone, Handhelds oder Laptops bzw. PCs) Daten aneinander angleichen. Es wird dabei erkannt, welches Endgerät welche Daten hat, und auch kontrolliert, ob das jeweilige andere Endgerät diese Daten zusätzlich zu seinen eigenen besitzen will. Für den Fall, dass beide Endgeräte dieselben Dateninhalte haben, nur in unterschiedlichen Versionen (wenn beispielsweise eine Adresse auf einer Seite geändert wurde) kann definiert werden, welche Änderung beibehalten wird.
Mittels SyncML-Nachrichten tauschen Clients mit einem Server Daten für die Synchronisation aus. Typischerweise initiiert immer der Client den Start einer Synchronisation. Erst eine zukünftige Version 1.3 soll einen echten Push vom Server zum Client ermöglichen. SyncML-Nachrichten ähneln in ihrer Struktur ganz normalen E-Mail-Nachrichten. Es gibt einen Kopf mit Empfänger und Senderinformationen und für den Server eindeutige Synchronisations-IDs. Dem Kopf folgen die Synchronisationsbefehle zum Hinzufügen, Löschen und Ersetzen von Daten.
Beispiel
Alice und Bob haben jeweils ein Mobiltelefon und sind als Außendienstmitarbeiter derselben Firma angestellt. Diese Firma verwaltet alle Kundendaten zentral an einem Server.
Alice lernt nun einen Kunden Dave kennen, und speichert dessen Telefonnummer und Namen in ihrem Handy ab. Das Handy von Alice übermittelt den neuen Eintrag automatisch an den zentralen Firmenserver, der nun den neuen Kontakt zentral speichert. Jetzt sendet der Server dem Mobiltelefon von Bob den Eintrag sofort zu, nachdem das Mobiltelefon von Alice den Eintrag dem Server bekannt gegeben hat. Der Server hat somit die Dateninhalte zwischen Alice und Bob synchronisiert. Dies funktioniert auch mit mehr als zwei Teilnehmern.
Ändert sich die Nummer von Dave, dann wird diese von Alice auf ihrem Mobiltelefon geändert und beim Synchronisieren auch auf dem zentralen Firmenserver geändert, und bei folgenden Synchronisierungen dann auch auf das Gerät von Bob gelangen.
Herausforderungen
Aus der Funktionsweise von SyncML ergeben sich einige Probleme:
- Woher weiß der zentrale Server wirklich zu 100 %, welchen Kontakt er zu aktualisieren hat, wenn Alice die Nummer eines Kontakts an ihrem Handy ändert?
- Wie kann sich der Server sicher sein, dass eine Änderung stattgefunden hat? Das heißt, welche Daten sollen verglichen werden?
- Was passiert, wenn Alice und Bob innerhalb kurzer Zeit eine Änderung an der Telefonnummer von Dave durchführen? Wessen Nummer gilt dann als die „richtige“ und wird unter allen anderen Mitarbeitern synchronisiert?
- Was soll geschehen, wenn ein neuer Mitarbeiter diverse Privatnummern in seinem Telefon einträgt – sollen diese wirklich auf den zentralen Server geladen werden und somit allen anderen zugänglich sein?
- Zusammengefasst: Wessen Daten sollen wann und zwischen wem synchronisiert werden?
Um diese Probleme lösen zu können, gibt es einige weiterführende Konzepte für den Synchronisationsprozess.
Konzepte
Folgende Konzepte müssen zwecks funktioneller Datensynchronisation implementiert werden:
- ID handling: Dient zur eindeutigen Identifikation eines Datensatzes (zum Beispiel Kontakteintrag). Diese wird durch eine eindeutige ID (identification data – meistens eine Nummer) realisiert. Somit können Server und Endgeräte (Handys und so weiter) erkennen, ob es sich bei zum Beispiel zwei Kontakten auf zwei Geräten um dieselben handelt, oder nicht.
- Change detection: Ab wann gilt ein Datensatz als geändert? Reicht es, wenn etwa der Vorname anders geschrieben wird, oder muss schon die ganze Telefonnummer eine neue sein? Dies definiert die change detection, die meist auch mit einem timestamp (konkreter Zeitpunkt – Datum inklusive Uhrzeit) arbeitet, um den Zeitpunkt der Änderung zu definieren.
- Modification exchange: Wie wird eine Änderung durchgeführt? Soll gelöscht, ersetzt oder neu erstellt werden? All dies wird hier definiert.
- Conflict detection: Dieses Konzept kümmert sich um die Erkennung der oben beschriebenen Fälle, wie gleichzeitiges Ändern diverser Daten oder darum, wessen Daten synchronisiert werden sollen.
- Conflict resolution: Hier wird nun entschieden, wie der oben erkannte Konflikt gelöst werden soll, frei nach dem Prinzip: „Wer zuerst kommt mahlt zuerst“, oder „Der Letzte gewinnt“ – also: Wessen Datensatz soll als Referenz für die Aktualisierung dienen.
- Slow and fast synchronisation: Sollen nur die Daten verglichen werden, die sich seit dem letzten vollen Synchronisationsvorgang geändert haben, oder alle?
Dies ist nur ein Überblick über die Konzepte – er wurde nur aus Gründen der Vollständigkeit wiedergegeben.
Schema
Mit SyncML erhalten die Geräte ein einheitliches Austauschprotokoll. Dieses arbeitet dabei unabhängig vom Gerätetyp und vom Übertragungsweg: Damit so unterschiedliche Gerätegattungen wie PDAs, Handhelds, Mobiltelefone, Kameras und PCs ihre Daten mit dem Synchronisationsprotokoll austauschen können, unterstützt SyncML etablierte Protokolle wie HTTP, WSP (Wireless Session Protocol, Teil des WAP-Protokolls) und OBEX für Bluetooth- und IrDA-Verbindungen.
Kommunikation
Die folgende Grafik soll den Synchronisationsablauf zwischen einem Server und einem Client schematisch darstellen. Man erkennt deutlich, dass sowohl Server als auch Client über eine SyncML-Schnittstelle (Interface) verfügen, die den reibungslosen Datenaustausch ermöglichen.
Die SyncML-konvertierten Daten werden über ein beliebiges Protokoll vom Server zum Client und umgekehrt übertragen – dies kann sowohl HTTP (TCP/IP), als auch WSP (WAP) oder OBEX (Bluetooth, Infrarot) sein.
Der Sync Client Agent leitet einen Synchronisationsvorgang auf Basis des SyncML-Protokolls ein und verwaltet die Übertragungsvorgänge auf Client-Seite. Auf der Gegenseite des Client wartet der Sync Server Agent auf eine Synchronisationsanforderung.
Die Sync Engine führt dabei eine Analyse durch und prüft, welche Daten verändert werden müssen. Dazu öffnet und modifiziert sie Datenbanken, reagiert auf Veränderungen im Terminkalender oder aktualisiert die Ordner des E-Mail-Programms.
Nutzen
Auf der Client-Seite, das bedeutet im Grunde die Seite des Endbenutzers – und somit den mobilen Teil – beherrscht SyncML die Datentypen, wie sie bei E-Mail, Kalendereinträgen, Adressverzeichnissen und Dokumenten vorkommen. Gleichzeitig ist SyncML so flexibel, dass sich neue Formate ohne größeren Aufwand einbinden lassen. Im Einzelnen leistet das Protokoll folgendes:
- Es ermöglicht Datenkommunikation über kabelgebundene Netze, Funknetze sowie Infrarot-Verbindungen.
- Es unterstützt eine Vielzahl von Transportprotokollen und Datenformaten.
- Es ermöglicht den Datenzugriff von vielen verschiedenen Geräten aus.
- Es berücksichtigt die begrenzten Ressourcen von mobilen Systemen bezüglich Speicher und Verarbeitungsleistung.
- Es stützt sich auf bewährte Netzwerktechnologien.
- Es unterstützt diejenigen Synchronisationsfunktionen, auf die möglichst viele Systeme zurückgreifen.
In der Praxis
SyncML (OMA DS) hat sich mittlerweile als Standard für den Abgleich von Termin-, Kontakt- und anderen PIM-Daten durchgesetzt, in der Praxis gibt es aber noch Herausforderungen:
- Im Gegensatz zu IMAP-Implementationen für E-Mails unterstützen bislang relativ wenige Desktop-Applikationen SyncML. Microsoft Outlook oder Mozilla Thunderbird benötigen beispielsweise zusätzliche PlugIns, um Kalender- oder Kontaktdaten auf diese Weise mit einem Server zu synchronisieren. Von aktuellen mobilen Geräten unterstützen die meisten Handys diesen Standard, auf Smartphones mit den Betriebssystemen Android, Windows Mobile, Blackberry oder Apple iOS muss er mittels Zusatzapplikation nachgerüstet werden.
- Vorhandene Server- und Clientprogramme, insbesondere unterschiedlicher Entwickler, kommunizieren nicht immer reibungslos miteinander, was zum Teil auf unausgereifte Implementierungen zurückzuführen ist. So funktioniert die Synchronisation bei einigen Konstellationen gar nicht, erst nach aufwändiger Konfiguration oder fehlerhaft (es kommt unter anderem zur Dublettenbildung).
Es gibt mittlerweile Lösungen, die intelligenten Datenabgleich mit Duplikats- und Konfliktlösung beherrschen und dem Anwender die meiste Arbeit abnehmen.
- In Deutschland setzen mittlerweile alle großen Mobilfunkanbieter und Internetprovider auf Dienste zur Datensicherung und -abgleich auf Basis von SyncML, vor allem T-Mobile mit MyPhonebook, Vodafone mit MeinAdressbuch, o2 mit dem Communication Center, Mobilcom mit dem MSync Service, oder T-Home (T-Online) mit dem Data Sync Service. Auch in anderen Ländern sind solche Dienste bereits etabliert, beispielsweise mit dem A1 Adressbuch bei Mobilkom Austria oder Orange Adressbuch in Österreich, sowie der Online Messaging Address Book Synchronisation bei o2 Irland.
Einzelnachweise
- Enabler Release Definition for SyncML Common Specifications. (PDF; 91 KB) Open Mobile Alliance, 24. Juli 2009, abgerufen am 11. Februar 2018.
- SyncML WSP Binding, Version 1.1. (PDF; 97 KB) Open Mobile Alliance, 15. Februar 2002, abgerufen am 11. Februar 2018.
- OMA DS Standards Change History. (PDF; 111 KB) Open Mobile Alliance, 31. März 2008, abgerufen am 11. Februar 2018.
Weblinks
- Aktuelle SyncML-Spezifikationen (v1.2.2) der OMA (englisch)
- SyncML Reference Toolkit (englisch)