SyncML

SyncML (Synchronization Markup Language) ist ein plattformunabhängiger Standard zur Datensynchronisation zwischen Computern. Bei den Daten kann es sich um beliebige Informationen handeln, meist PIM-Daten wie Adressen, Kalendereinträge oder E-Mail-Nachrichten.

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.

SyncML ist Beschreibungssprache und Protokollvereinbarung in Einem. Die Syntax beruht auf XML.

Plattformunabhängigkeit

Um den Datenabgleich zwischen unterschiedlichen Endgeräten über Hardware- und Systemgrenzen hinweg unabhängig vom Hersteller der verwendeten Komponenten zu ermöglichen, ist SyncML als nicht-proprietärer offener Standard ausgelegt. Es ist auf keine Netzwerkarchitektur festgelegt. Dadurch ist zum Beispiel eine Synchronisation über das Internet, das Mobilfunknetz oder zwischen zwei direkt miteinander verbundenen Endgeräten (TCP/IP, WSP oder Obex) möglich.

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.

Das Protokoll wurde auf Initiative führender Mobilfunkgeräte- und Computerhersteller entworfen, die sich Anfang 2000 zum SyncML-Konsortium zusammengeschlossen haben. Das Konsortium, das nun unter dem Dach der Open Mobile Alliance angesiedelt ist, besteht aus etwa 200 Firmen, darunter Nokia, HP Palm, IBM, Motorola, Samsung, Ericsson, Symbian und Lotus. Microsoft gehört nicht dazu, für seine PocketPCs gibt es aber SyncML-Clients von Drittanbietern.

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

SyncML-Protokollaufbau, Quelle: www.tecchannel.de

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

Grundsätzlicher Ablauf bei einer Synchronisation zwischen Server und Client, Quelle: www.syncml.org

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 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 Doublettenbildung).

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.

Weblinks

• Aktuelle SyncML-Spezifikationen (v1.2.2) der OMA (Englisch)
• SyncML Reference Toolkit (Englisch)