Gleichmacher

SyncML hat sich zum Standard für den Abgleich von Adress- und Termindaten entwickelt. Viele aktuelle Handys und PDAs nutzen das Protokoll, um ihre Adressbücher und Kalender mit dem PC oder mit Web-Diensten zu synchronisieren. Dieser Artikel zeigt, was hinter den Kulissen passiert, wenn man den Sync-Knopf drückt.

Synchronisation von PDA-Daten ist ein alter Hut. Bereits der Urahn aller PDAs, der Apple Newton, hatte seine eigene Synchronisationstechnik. Richtig bekannt wurde das Konzept dann mit dem PalmPilot und dessen HotSync. Etwas später zog Microsoft mit Windows CE und ActiveSync nach.

Anders als HotSync und ActiveSync ist der SyncML-Standard in mehrerlei Hinsicht offen. Jeder Hersteller darf SyncML-Funktionen in seine Geräte einbauen; jedes Gerät mit einem SyncML-Client kann Daten mit jedem SyncML-Server abgleichen. SyncML ist nicht auf eine bestimmte Netzwerkarchitektur festgelegt, sondern kann Daten zum Beispiel über das Internet, ein Mobilfunknetz oder zwischen zwei direkt miteinander verbundenen Endgeräten abgleichen.

Die Vielseitigkeit von SyncML hat dazu geführt, dass es sich auf breiter Basis durchsetzen konnte. Mittlerweile verwenden mehr als 250 Unternehmen den Standard in ihren Produkten. Ein weiterer Grund für den Erfolg des SyncML-Standards dürfte sein, dass er nur diejenigen Funktionen festschreibt, die für das Zusammenspiel zwischen Client und Server unabdingbar sind, sich aber nicht in Details ergeht, die den Implementierungsspielraum unnötig einschränken (Standspezifikation bei der Open Mobile Alliance).

Offen und schlank

Die Aufgabe jeder Synchronisationstechnik ist es, zwei Listen von Objekten auf den gleichen Stand zu bringen und synchron zu halten. Davon befindet sich typischerweise eine Liste auf dem Server – meist ein Desktop-PC oder ein Server im Internet – und eine auf dem Client, dem mobilen Gerät. Allerdings müssen Datensätze nicht auf beiden Seiten mit denselben IDs referenziert werden. Vielmehr übernimmt ein so genanntes ID-Mapping auf dem Server die Zuordnung zwischen den IDs des Clients und denen des Servers.

Die drei Phasen Initialisierung, Datenaustausch und Mapping können sich überlappen.

Client und Server müssen zudem in der Lage sein, festzustellen, welche Objekte seit der letzten Synchronisation gelöscht, welche geändert und welche hinzugefügt wurden. Der Client muss dabei nicht einmal Änderungen von neu hinzugefügten Objekten unterscheiden können. SyncML hält sich bei der Frage zurück, wie Client und Server die Änderungen in den Datensätzen erkennen. Hierfür können sie zum Beispiel Checksummen oder Zeitstempel einsetzen.

Der Client beginnt

Der Client startet immer den Synchronisationsvorgang. Dieser besteht aus einer Abfolge von Anfragen, den Requests, und Serverantworten, den Responses. Jeder Request und jede Response besteht aus einer SyncML-Message. Das "ML" in SyncML kommt nicht von ungefähr – Messages sind XML-Dokumente.

Eine Synchronisation läuft in drei Phasen ab: Initialisierung, Datenaustausch, Mapping. In jeder Phase tauschen Client und Server mindestens eine, aber oft mehrere Requests und Responses aus. Alle Requests (oder Responses) einer Phase zusammen bilden ein Package. Packages können sich in den beiden Richtungen aus unterschiedlich vielen Messages zusammensetzen. Daher überlappen sich die Phasen mitunter.

Auf die Plätze, ...

In der Initialisierungsphase meldet zuerst der Client dem Server durch das Alert-Command mit einem numerischen Code seine Synchronisationswünsche an. 200 bedeutet zum Beispiel "normale Zweiwege-Synchronisation". Bei dieser Synchronisationsform tauschen Client und Server nur diejenigen Datensätze aus, die sich bei dem letzten Synchronisationsvorgang geändert haben. Das Beispiel initiiert die Synchronisation der Adressdatenbestände. Der Client könnte aber auch gleichzeitig die Termine abgleichen. Dazu müsste er einfach einen weiteren Alert übermitteln.

<SyncML xmlns="syncml:SYNCML1.1">
<SyncHdr>
... (SyncML-Header für Client-Message Nr. 1) ...
</SyncHdr>
<SyncBody>
... (andere Commands) ...
<Alert>
<CmdID>3</CmdID>
<Data>200</Data>
<Item>
<Target><LocURI>contacts</LocURI></Target>
<Source><LocURI>C:\Tel\Contact.cdb</LocURI></Source>
<Meta>
<Anchor>
<Last>20060428T142515Z</Last>
<Next>20060428T160053Z</Next>
</Anchor>
</Meta>
</Item>
</Alert>
<Final/>
</SyncBody>
</SyncML>

Mit dem Anchor überprüfen Client und Server, ob sie beide von derselben vorhergegangenen Synchronisations-Session ausgehen. Das Next-Tag enthält zu diesem Zweck eine Referenz auf die aktuelle Session für den Client (und nur für ihn); Last enthält den entsprechenden Wert für die vorangegangene Session. Der Server speichert Next am Ende einer erfolgreichen Session ab. Wenn in einer nächsten Session das Alert eintrifft, vergleicht er das darin enthaltene Last mit dem gespeicherten Next vom letzten Mal. Stimmen die Werte nicht überein, ist die vermeintlich letzte Session nicht auf beiden Seiten dieselbe, und es wird ein so genannter Slow Sync erzwungen (siehe Aller Anfang ist langsam). Zwar sind diese Werte meist Zeitstempel – für den Server aber sind es bloße, beliebige Strings, die er lediglich auf Übereinstimmung vergleichen darf.

Optional kann der Client mit einem Get-Command die so genannte devInf anfordern. Sie enthält die Device Information, eine Beschreibungsstruktur mit Namen, Hersteller, Version und einer Liste der unterstützten Datenformate. Damit weiß der Client zum Beispiel, welche Felder er überhaupt mit dem Server synchronisieren kann. Das <Final/>-Element schließlich kennzeichnet als letztes Element in der letzten Message das Package-Ende.

... fertig, los!

Der Server wertet nun die Commands aus und erzeugt für jedes eine Statusmeldung als Antwort. Die Status-Codes lehnen sich an HTTP an. 200 bedeutet zum Beispiel "o.k.", 404 wie im Web "nicht gefunden". Darüber hinaus gibt es auch SyncML-spezifische Codes.

Eine SyncML-Schnittstelle ist heute, außer bei Budget-Handys, Standard.

Damit ist die Initialisierungsphase abgeschlossen – es ist jetzt vereinbart, welche Art der Synchronisation ansteht, und aus der devInf der jeweiligen Gegenseite sind auch die Details wie unterstützte Felder und Features bekannt. Jetzt kann die eigentliche Synchronisation starten. In Package drei sendet der Client dem Server seine Änderungen, worauf der Server in Package vier seine Änderungen dem Client mitteilt. Dabei führen beide Seiten einfach die Änderungen gemäß den empfangenen Add-, Replace- und Delete-Commands aus, und quittieren dies mit einem entsprechenden Status an den Absender. Die Objekte werden immer durch ihre clientseitige ID adressiert.

Damit wäre die Synchronisation auch schon erledigt – wenn es nicht den Fall von neuen Datensätzen gäbe, die der Server auf dem Client erzeugt hat. Hier kann die obige Regel der Adressierung durch die clientseitige ID nicht gelten, denn bevor der Datensatz auf dem Client angelegt ist, existiert diese noch gar nicht.

Deshalb enthalten vom Server gesendete Add-Commands die serverseitige ID. Der Client erzeugt nun einen neuen Datensatz, womit auch eine neue clientseitige ID entsteht. In der dritten und letzten Phase der Synchronisation sendet der Client in einem speziellen Map-Command die neuen Client-IDs paarweise mit den vom Server erhaltenen IDs. Damit kann der Server seine Mappings nachführen, und spätere Änderungen an den neu angelegten Objekten wieder anhand der Client-Ids anweisen.

Den wirklichen Abschluss einer Session bildet dann ein OK-Status des Servers für das Map-Command. Erst wenn der Server dieses abgeschickt hat, darf er die Session als erfolgreich beendet anschauen und den ganz am Anfang vom Client erhaltenen Next-Anchor abspeichern. Das Gleiche gilt für den Client – erst nach Empfang eines Map-OK-Status gilt die Session als komplett.

Ein Sonderfall bei Datenabgleich ist der so genannte Sync-Konflikt. Dabei wurde zwischen zwei Synchronisationen auf beiden Seiten eine Änderung am gleichen Datensatz vorgenommen. Die Auflösung des Konflikts ist bei SyncML Sache des Servers; wiederum schreibt der Standard nicht vor, welche Strategie verwendet werden soll. Von einfacher Priorisierung ("Server überschreibt Client"), über Speichern beider Versionen bis zu Algorithmen, die Daten analysieren und zusammenführen können, ist alles möglich.

Nicht vorgesehen ist jedoch ein interaktives Eingreifen während des Synchronisationsvorganges. Wenn man aber bei einem Konflikt erst mal immer beide Versionen speichert, kann ein Anwender später die "falsche" Version löschen, und so den Konflikt im Nachhinein lösen.

Aller Anfang ist langsam

Die wichtigste Aufgabe bei der Synchronisation müssen Client und Server gleich bei der ersten Synchronisation bewältigen. Angenommen, Sie haben ein Handy mit etlichen gespeicherten Kontakten und einen Server-Account, auf dem Sie teilweise dieselben, teilweise andere Kontakte erfasst haben. Zu diesem Zeitpunkt verfügen Client und Server zwar schon teilweise über dieselben Daten, es exisitiert aber noch kein ID-Mapping.

Falls der Abgleichvorgang länger dauert, wähnen sich Client und Server nicht synchron und tauschen alle Datensätze aus.

Client und Server können aber auch in Folge eines Datenverlusts, eines zwischenzeitlich zurückgespielten Backups, oder eines Abbruchs mitten in einer Synchronisation nicht synchron sein. In den beiden letzten Fällen muss der Server davon ausgehen, dass die existierenden Mappings, wenn überhaupt schon vorhanden, ungültig sind.

Es kommt daher zum Slow Sync. Den Namen hat dieser Vorgang (den es bei allen Sync-Technologien gibt) bekommen, weil es ohne Mappings eben nicht möglich ist, nur die Änderungen zu übertragen, und deshalb mindestens eine Seite ihren ganzen Datenbestand der anderen Seite übermitteln muss. Das kann bei großen Datenmengen lange dauern.

Bei SyncML ist es der Client, der alle seine Objekte dem Server sendet, welcher dann die heikle Aufgabe hat, den Daten-Inhalt dieser Clientobjekte mit seinen eigenen zu vergleichen. Passt ein Vergleich, so kann er nun die ID des Clientobjekts mit der des Serverobjekts "mappen" – man spricht von einem Slow Sync Match. Passt das Clientobjekt mit keinem Serverobjekt zusammen, fügt der Server es seinem Datenbestand neu hinzu. Umgekehrt sendet der Server am Ende des Datenaustauschs alle Serverobjekte, für welche er kein Clientobjekt finden konnte, dem Client als neue Datensätze.

Ein Mapping zu generieren, ist eine heikle Aufgabe, weil Client und Server selten zu hundert Prozent identische Datenfelder haben. Würde der Server 1:1-Vergleiche machen, fände er kaum je einen Slow Sync Match, und der Anwender hätte am Ende eines Slow-Syncs die meisten Daten doppelt. Die Kunst liegt also darin, einen Vergleich zu verwenden, der unscharf genug ist, um Duplikate zu vermeiden, aber scharf genug, um falsche Zuordnungen zu verhindern. Wie an anderen Stellen auch schreibt SyncML hierfür keine Methode vor. Jeder Server fährt eigene, dem Anwendungsfall angepasste Strategien.

Fazit

Trotz derzeit viel medialen Wirbels um proprietäre Synchronisationssysteme wie Blackberry und ActiveSync wird sich SyncML weiter entwickeln und leistet vielleicht etwas weniger spektakuläre, aber effiziente Arbeit dort, wo eine große und heterogene Palette von Mobilgeräten unterstützt werden soll. (jo)