Programmation XML/SyncML

SVG

MathML

Programmation XML

Applications fondamentales

Applications finales

Version imprimable

[ Modifier le sommaire ]

SVG

MathML

Objectifs

Après avoir lu ce chapitre, vous serez capable de :

Comprendre les bases de SyncML et la syntaxe générale ;
Comprendre comment et pourquoi SyncML est mis en œuvre ;
Trouver rapidement et utiliser les spécifications techniques de SyncML.

Introduction

Les terminaux mobiles comme les PDA, les pagers, les téléphones mobiles et les ordinateurs portables ne sont par nature pas connectés en permanence à un réseau. Cependant, ces appareils contiennent des applications qui ont besoin d'informations provenant d'un réseau afin d'être utilisables. La plupart des PDA et mobiles possèdent des applications comme des calendriers, des listes de taches, des répertoires pour stocker des informations qui deviennent moins utiles à partir du moment où elles sont statiques, uniquement disponibles sur l'appareil. Par exemple, des copies statiques d'informations seront différentes de l'original dès qu'une modification est apportée d'un côté ou de l'autre. La synchronisation offre la possibilité à un terminal de se connecter à un réseau afin de mettre à jour à la fois l'information de l'appareil et l'information du réseau pour que les deux soient identiques et à jour.

Devant la prolifération d'appareils mobiles et de protocoles propriétaires ainsi que la demande croissante d'accès à de l'information en situation de mobilité, les sociétés leader sur le domaine ont compris l'intérêt de créer un langage standard et universel décrivant les actions de synchronisation entre les terminaux et les applications. Elles ont formé un consortium pour sponsoriser cette initiative et pour créer ce langage.

Actuellement, le consortium SyncML a été adopté et incorporé à l'Open Mobile Alliance, un regroupement de plus de 300 sociétés qui supporte plusieurs projets collaboratifs portant sur les technologies et les protocoles.

Qu'est-ce que SyncML ?

SyncML ou Synchronization Markup Language est le protocole standard basé sur XML de synchronisation de données au travers d'une multitude de réseaux, de plates-formes et de terminaux. SyncML a été démarré en tant qu'initiative en 2000 par de grandes sociétés comme Ericsson, IBM, Palm Inc., Lotus, Matsushita Ltd. (Panasonic), Motorola, Nokia, Openwave, Starfish Software, Psion et Symbian. Leur but était la création d'un langage universel à partir de la myriade de protocoles de synchronisation propriétaires utilisés par les appareils mobiles et de fournir un ensemble complet de fonctionnalités de synchronisation pour les futurs terminaux. Le consortium a sorti la version 1.0 en décembre 2000. Ils ont développé des nouvelles fonctionnalités et résolu les problèmes découverts avec cette version, finalisant le protocole avec la version 1.1 en février 2002.

Le protocole SyncML a été conçu en gardant ces objectifs à l'esprit :

Garder en cohérence deux ensembles de données
Être indépendant du transport
Être indépendant des données synchronisées (PIM, email, fichier, ....)

SyncML comprend des commandes client et serveur définies par des DTD...

Principes de SyncML

Vocabulaire

Commençons avec un peu de vocabulaire :

Client - le terminal mobile, son application et sa base de données locale.
Serveur - un système distant communiquant avec la base de données du système ou de l'application.
Modifications - les données dans les champs d'une base de données qui sont modifiées.
Synchronisation - le client et le serveur échangent des messages SyncML avec des commandes.
Package - Balises XML conformes à la DTD de SyncML décrivant les requêtes ou actions qui doivent être effectuées par un client ou un serveur SyncML. Un package est un ensemble d'actions à effectuer.
Message - La plus petite unité de balise SyncML. Les grands packages sont découpés en messages séparés.
Mapping - Utilisation d'un identifiant intermédiaire pour lier deux informations. Exemple : Disons que 'vert' c'est '5', et '5' c'est bien. Qu'est-ce qui est bien ? Si vous répondez 'vert', vous êtes tombé juste. vous avez réalisé un mapping !

Abréviations :

IMEI	International Mobile Equipment Identifier - numéro d'identification des terminaux mobiles
GUID	Global Unique Identifier - identifiant global unique
LUID	Local Unique Identifier - identifiant local unique

Messages et Packages

Un message est un ensemble de commandes SyncML transmises (en une seule fois) vers le client ou le serveur. La taille maximale d'un message est définie par la Meta données MaxMessageSize. Si un message à transmettre dépasse cette taille on le découpe en plusieurs messages. On parle alors de Multiple Message in Package. Un package correspond à un ensemble de messages pour effectuer une des étapes de la synchronisation. Les packages sont les suivants: pkg1 = initialisation du client (authentification, échange des devinf, des informations sur les bases à synchroniser), pkg2 = initialisation du serveur, pkg3 = modification côté client, pkg4 = modification côté serveur, pkg5 = mise à jour des données et statuts, pkg6 = mapping des id client et serveur.

Structure d'un message SyncML

Comme SOAP, il y a deux parties dans un message SyncML, un en-tête <SyncHdr> et un corps <SyncBody>. L'en-tête contient des meta-informations sur la requête comme la base de données cible <Target> et la base de données source <Source>, les informations d'authentification <Cred>, l'identifiant de session <SessionID>, l'identifiant du message <MsgID>, et la déclaration de la version de SyncML <VerDTD>. Le corps contient les commandes SyncML (les statuts des commandes du message précédent, et toutes les autres commandes prévues par SyncML).

Adressage

L'adressage est réalisé au travers des balises <Source> et <DocURI>. Un serveur aura une URI du genre http://www.chris.syncml.org/sync et le terminal mobile client aura un numéro d'identification IMEA comme ceci 30400495959596904.

Mapping ou Correspondance

SyncML est basé sur l'idée que les clients et les serveurs peuvent avoir leur propre méthode pour faire correspondre les informations dans leur base de données. Aussi, les clients et les serveurs doivent avoir leur propre ensemble d'identifiants uniques.

En effet, par gain de place, certain terminaux mobile ne peuvent accepter des id trop longs, ils vont alors définir leur propres id, et envoyer au serveur le mapping à effectuer à l'aide de la balise <Map>. De cette manière, le mobile ne stocke que l'id qu'il a choisi (généralement assez court) et le serveur, lui, stocke les deux, ce qui lui permet de s'adresser au mobile avec l'id que le mobile connait. Le serveur conserve l'ensemble des id indéfiniment.

Dans les futurs échanges, le mobile utilisera seulement l'id qu'il connait, et le serveur se chargera d'effectuer les mappings correspondants.

Les identifiants locaux uniques (LUID - Locally Unique Identifiers) sont des nombres assignés par le client à une donnée dans la base de données locale (comme un champ ou une ligne). Ce sont des nombres non réutilisables assignés à ces objets par le client SyncML.

Les identifiants globaux uniques (GUID - Globally Unique Identifiers) sont des nombres assignés à une donnée utilisés dans une base de données distante. Cet identifiant est assigné par le serveur.

Le serveur va créer une table de correspondance pour lier les LUID et GUID ensemble.

Données côté client

LUID
----
5

Data
----
Green

Données côté serveur

GUID
----
5050505

Data
----
Green

Correspondance sur le serveur

GUID
----
5050505

LUID
----
5

Journaux de modification (change logs)

Les change logs sont une manière pour un device (client ou serveur) de déterminer la liste des modifications dans la base depuis la dernière synchro.

Les ancres

Les ancres servent à savoir si la dernière synchro s'est bien passée. Au début de session, le client envoie ses ancres (last et next). Le serveur stock la next du client. À la fin de la session (s'il n'y a pas eu d'interruption), le client met à jour ses ancres (last = next et il incrémente next). Lors de la prochaine session, le client envoie son next et last. Le serveur vérifie que le last du client vaut le next qu'il a stocké précédemment. Si c'est le cas, c'est OK, on continue. Sinon, cela ne va pas du tout et le serveur PEUT forcer une slow sync.

Session 1 : C'est une slow sync : le client envoie juste son next. La synchro se passe nickel

Client                     Serveur
 |---------next=1------------>|        next client = 1
 |
 |
 |
 |

Fin de synchro : last=1, next=2

Session 2 : Une interruption se produit lors de cette synchro

Client                        Serveur
 |--------last=1, next=2------>|          last = next stocké (1). next client devient 2
 |                             |
 |
Interruption

Comme la session va pas au bout, le client update pas ses ancres

Session 3 Après l'interruption on essaye de repartir

Client                      Serveur
 |------last=1, next=2------>|          CA MATCH PAS : 1!= 2 La dernière synchro s'est mal passée ! Le serveur peut demander une slow sync
 |

En comparant les ancres envoyées et celles stockées avec le type de synchronisation demandé, le serveur peut déterminer quel est l'information la plus récente. Par exemple, il est possible de réécrire une information 'nouvelle'- c'est l'information pour laquelle l'empreinte temporelle est la plus récente dans les logs- avec une information plus ancienne. Cela peut être fait en choisissant une synchronisation dans laquelle le client dit au serveur d'effacer ses informations avec les données client. Cette opération est appelée 'refresh sync from client'. Les différents types de synchronisation sont décris ci-dessous.

Synchronisations (Syncs)

Dans sa version 1.1, le langage SyncML définit 7 types de synchronisation. La section ci-dessous définit ces différents types :

Two-way Sync (Synchronisation bi-directionnelle) - Le client et le serveur s'échangent des informations relatives aux données modifiées. Le client transmet les modifications en premier.
Slow sync (Synchronisation lente) - Le client renvoie l'intégralité de ses données. Le serveur calcule le delta (avec les siennes) et le renvoie au client. Ce type de synchronisation est généralement utilisé lors d'une première synchro, lors d'une interruption, ou lorsque l'une des deux parties le demande.
One-way sync, client only (Synchronisation uni-directionnelle, Client uniquement) - Le client transmet ses modifications. Le serveur les accepte puis met à jour les données sans transmettre en retour ses modifications.
Refresh sync from client (Synchronisation de mise à jour avec les donnés du client) - Le client transmet sa base de données entièrement au serveur. Le serveur remplace la base de données cible par celle transmise par le client.
One-way sync, server only (Synchronisation uni-directionnelle, Serveur uniquement) - Le serveur transmet ses modifications au client. celui ci les accepte puis met à jour ses données locales sans transmettre en retour ses modifications.
Refresh sync from server (Synchronisation de mise à jour avec les donnée du serveur) - Le serveur transmet l'intégralité des informations de sa base de données. La base de données du client est entièrement remplacée.
Server alerted sync - Le serveur télé-commande au client d'initier un des modes de synchronisation présentés ci-dessus. De cette façon, le client est contrôlé à distance par le serveur.

Initialisation de la synchronisation

L'initialisation de la synchronisation est un passage obligatoire pour le client et le serveur avant d’entamer une synchronisation. La première étape est que le client et serveur parlent le même langage, en s'échangeant l'un et l’autre leur capacité (définies par le matériel, comme la quantité de mémoire, et le protocole définit par la DTD). La seconde étape est l'identification des bases de données à synchroniser. Ensuite, les deux doivent décider du type de synchronisation. La troisième et dernière partie est l'authentification. Une fois que cette étape à été complétée avec succès, la synchronisation à proprement parler peut commencer.

Authentification

Le serveur SyncML peut envoyer au client un message contenant la balise <Chal> qui représente une demande d'authentification (Challenge en anglais) pour les informations auxquelles le client tente d'accéder. Le client doit alors répondre et donner le login et mot de passe dans une balise <Cred> (Credential en anglais).

SyncML peut utiliser l'accès authentifié par le hachage md5. Le client et le serveur échangent leurs identifiants durant la phase d'authentification, retournant un code d'erreur si le processus s'arrête quelque part. La balise <Cred> est utilisée dans le <SyncHdr> pour fixer le type d'authentification qui sera utilisé dans la phase d'authentification. (Il y a le hashage md5, mais aussi l'encodage base64 et d'autres... Il faut donc que le serveur informe le client du type d'authentification utilisée).

Common SyncML implementations

Nokia a été la première entreprise à commercialiser un téléphone mobile pouvant utiliser SyncML pour la synchronisation de la base de données du calendrier du téléphone. SyncML permet de synchroniser des listes de choses à faire, des calendriers, des carnets d'adresses, des carnets de numéros de téléphone, bien plus que ce qu'un organiseur peut faire. SyncML est capable de faire beaucoup plus de choses.

En fait, il serait même approprié d'utiliser SyncML à chaque fois que deux applications distantes différentes partagent les mêmes données.

Syntaxe SyncML

Exemple SyncML

Exemple de SyncML abrégé

<SyncML>
<SyncHdr>
<VerDTD>1.1</VerDTD>
<VerProto>SyncML/1.1</VerProto>
<SessionID>104050403</SessionID>
<MsgID>5</MsgID>
<Cred>...</Cred>
</SyncHdr>
<SyncBody>
<Status>...</Status>
<Sync>
<Target>target database URI</Target>
<Source>source database URI</Source>
<Add>datafield and data</Add>
<Replace>an existing data field with some data</Replace>
</Sync>
</SyncBody>
</SyncML>

Notez que la ligne {1} et {18} débutent le fichier SyncML par la balise racine. Ensuite, le SyncHdr est défini par les lignes {2} et {8}. Puis les ligne {3,4} qui définissent des informations concernant la version de SyncML utilisée, la ligne {5} définit l'identifiant de session (sessionID) qui permet d'identifier de façon unique le dialogue qui est en cours entre le client et le serveur, la ligne {6} représente l'identifiant du message (MsgID) qui permet d'identifier de façon unique cet ensemble de requêtes (toutes ces balises) qui vont être exécutées par l'application réceptrice. À la ligne {7}, on trouve la balise Cred (demande d'authentification, non détaillée ici) qui fait également partie de l'entête. La ligne {8} est la fermeture du SyncHdr (entête).

Le SyncBody (Corps du message) commence à la ligne {9}. Dans cette partie du message SyncML, on trouve : le status de l'application/l'appareil {10}, la source et cible de la requête (source/target) {12,13}, et les actions demandées comme la synchronisation elle-même entre les ligne {11,16}. Aux lignes {14,15}, on peut voir les commandes Add et Replace qui commandent respectivement l'ajout et le remplacement de données dans la base de donnée cible.

WBXML et SyncML

WAP Binary XML (WBXML) est une forme de XML dans laquelle les tags sont abrégés dans le but de raccourcir les balises pour la transmission vers des périphériques mobiles. En effet, ces périphériques ont en général une bande passante et une mémoire limitées. Les tags XML sont encodés en binaire pour économiser de la place. Regardons l'exemple suivant, cela aura plus de sens.

Ce qui suit est du code binaire WBXML représentant un message SyncML. Notez que sur la première ligne il y a le définition du type de document, représentée ici en hexadécimal. Regardez ce qui est arrivé à la chaine suivante "//SYNCML//DTD SYNCML 1.1//EN"

Immédiatement après cette chaîne, on trouve les caractères '6D 6C 71'. Chacun d'entre eux représente un tag SyncML

Abréviations wbxml

6D
6C
71

 = "<SyncML>"
 = "<SyncHdr>"
 = "<VerDTD>"

Abréviations wbxml (cont.)

C3
03
"1" "." "1"
01

 = représente le début des données opaques
 = ceci représente la longueur de ces données opaques
 = le caractère "1" suivit d'un "." et de "1"
 = représente "</VerDTD>"

le code snippet WBXML 6D6C71C303"1.1"01 représente :

Extrait d'une entête SyncML header snippet

1
2
3

<SyncML>
<SyncHdr>
<VerDTD>1.1</VerDTD>

Donc on peut voir que la syntaxe WBXML este plus compacte que XML, économisant du réseau pour les appareils mobiles.

Pour plus d'information, voir les articles de Ed Dumbill's sur syncML avec WBXML :

Spécifications de SyncML

La meilleure source d'informations sur SyncML c'est le protocole lui-même. Allez voir le site de l'Open Mobile Alliance pour obtenir les spécifications de SyncML.

Open Mobile Alliance

Téléchargez les Spécifications et White Papers SyncML de l'OMA sur le site de l'Open Mobile Alliance. Ou regardez les articles sur SyncML sur le site de l'Open Mobile Alliance.

Mises en œuvre de SyncML

Bien que les spécifications de SyncML soient utiles, vous devez toujours intégrer le protocole dans votre application. Il existe quelques boîtes à outils et transpositions que vous pouvez utiliser pour un démarrage rapide.

Boîte à outils SyncML de référence

l'Open Mobile Alliance a publié une boîte à outils en C pour implémenter SyncML. Vous pouvez l'obtenir ici. Si vous comprenez l'allemand, vous pouvez obtenir un exemple d'application utilisant cette boîte à outils ici.

Funambol

Si vous êtes intéressé par le développement d'application basée sur SyncML en Java, regardez le projet open source Funambol. Il propose une bibliothèque de classes Java mettant en œuvre le protocole de synchronisation de données SyncML, un framework Java pour construire des applications serveurs SyncML et un serveur SyncML indépendant.

Conclusion sur SyncML

La technologie des appareils mobiles se développe très rapidement, et la 4G permet de nouveaux appareils puissants sur le marché. Ces derniers proposent du streaming multimédia, et auront pour valeur ajoutée leurs applications personnalisées et services synchronisés en SyncML.

Exercice

Exercices

Visiter le site de l'Open Mobile Alliance^[1], et télécharger le PDF du protocole SyncML v. 1.1 pour répondre à ces questions :

Qu'est-ce qu'est le WBXML et où est-il utilisé ?
Quelles sont les prévisions pour SyncML ?
Nommer une situation problématique où SyncML est la meilleure solution.

Solution

WBXML is Wap Binary XML, it is a form of XML whereby the XML tags are abbreviated in order to shorten the markup for transmission to mobile devices, which commonly have bandwidth and memory limitations.
SyncML will likely be used as a general, standard synching mechanism for synchronizing data sets between systems, not just for mobile devices.
A ticket-tracking system called TNT helpdesk is a web-based open work request management system. The staff funning this system would like to have live data from this system on their PDAs, listing open requests. Currently, the PDA database is synched via a docking synch station attached to the staff members' PCs. Staff members have to download the request list as a CSV file, convert it into a usable PDA database and upload it to the PDA, making it this process cumbersome, prone to error, and always out-of-date. Recommendation: Create a custom app to push live updates to the PDAs using SyncML over Bluetooth/Wireless

Références

↑ http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/syncml-archive

Dumbill, E.(2003, March 1). XML Watch: WBXML and basic SyncML server requirements. IBM.com. Retrieved April 6, 2004 from
http://www-106.ibm.com/developerworks/xml/library/x-syncml2.html

Open Mobile Alliance (2002, April 2). SyncML version 1.0, 1.1 specification, white paper, errata. Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html

SyncML Initiative, Ltd.(2000, December 7). SyncML Specification Protocol version 1.0. The Open Mobile Alliance. Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncml_represent_v10_20001207.pdf

SyncML Initiative, Ltd.(2002, February 15). SyncML Device Information DTD version 1.1. . Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncml_devinf_v11_20020215.pdf

Site de synchronisation (démo gratuite et webmaster très sympathique)
http://www.memotoo.com/

[1] ttps://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/syncml-archive

[1]