Principes de base des fournisseurs personnalisés

Microsoft Sync Framework inclut des fournisseurs pour plusieurs scénarios de synchronisation tels que la synchronisation de fichier, mais dans certains cas, un fournisseur personnalisé est nécessaire. Les fournisseurs personnalisés impliquent plus d'écriture de code que les fournisseurs inclus avec Sync Framework, mais ils sont un composant clé de la flexibilité et de l'extensibilité de Sync Framework. Cette rubrique fournit des informations qui vous aident à comprendre les fournisseurs personnalisés et à faire des choix sur le type de fournisseur personnalisé qui convient pour votre application. Si Sync Framework ne vous est pas encore familier, nous vous recommandons également de lire « Composants de Sync Framework » dans la rubrique Sélection des composants de Sync Framework appropriés.

Fonctionnement des fournisseurs, des applications et de la gestion des métadonnées

Microsoft Sync Framework synchronise des réplicas à l'aide de quatre composants de base : le runtime de synchronisation, une session de synchronisation et deux fournisseurs de synchronisation. Pour synchroniser des données, une application crée une session de synchronisation et lui transmet un fournisseur de source et un fournisseur de destination. La session utilise le fournisseur de source pour obtenir les nouvelles modifications qui se sont produites sur le réplica source et utilise le fournisseur de destination pour appliquer ces modifications au réplica de destination. Un fournisseur gère les métadonnées, notamment la connaissance, pour chaque réplica et chaque élément à synchroniser. La connaissance représente les métadonnées qui décrivent toutes les modifications appliquées à un réplica, directement ou par synchronisation.

Lorsque Sync Framework ne propose pas de fournisseur pour le magasin de données à synchroniser, un fournisseur personnalisé doit être écrit. Sync Framework inclut des API managées et non managées pour deux types de fournisseurs personnalisés : fournisseurs personnalisés simples et fournisseurs personnalisés standard :

• En raison d'un plus petit nombre d'interfaces et de leur simplicité, les fournisseurs simples offrent une vitesse supérieure de développement et une prise en charge plus intuitive pour les magasins de données qui sont dépourvus de mécanismes de suivi des modifications sophistiqués.

• Les fournisseurs standard offrent le plus de flexibilité et les niveaux plus élevés de performance et de robustesse.

Les deux types de fournisseurs peuvent être utilisés pour synchroniser une large gamme de magasins de données et ils fournissent tous deux des options dans des domaines importants tels que le filtrage et la gestion des conflits. Cependant, ils présentent des différences importantes. Pour plus d'informations, consultez « Fournisseur simple ou fournisseur standard » dans cette rubrique.

L'illustration suivante montre les éléments principaux utilisés dans un scénario de synchronisation. Elle est semblable à celle figurant dans Sélection des composants de Sync Framework appropriés, mais la légende fournit des informations supplémentaires pertinente sur les fournisseurs personnalisés et montre comment le flux des données et des métadonnées s'effectue à travers le système.

Les éléments illustrés sont de trois types :

• Éléments écrits par le développeur.

  • L'application démarre la synchronisation, répond aux événements et gère d'autres tâches selon les besoins de l'application. Pour plus d'informations, consultez Implémentation d'une application de synchronisation.

  • Le fournisseur gère les métadonnées pour un réplica et utilise Sync Framework pour énumérer les modifications et détecter les conflits. Le fournisseur utilise également le magasin de données d'un réplica pour envoyer des données d'élément lorsque le fournisseur agit comme fournisseur de source et pour appliquer des modifications lorsque le fournisseur agit comme fournisseur de destination. Le fournisseur est propre au type des données synchronisées. Les deux fournisseurs dans une session sont souvent du même type, mais ce n'est pas une obligation. Pour plus d'informations sur l'interopérabilité, consultez Intégration de données de fournisseurs différents.

    Code managé Un fournisseur simple implémente FullEnumerationSimpleSyncProvider ou AnchorEnumerationSimpleSyncProvider. Un fournisseur standard implémente KnowledgeSyncProvider, IChangeDataRetriever et INotifyingChangeApplierTarget.

    Code non managé Un fournisseur simple implémente IFullEnumerationSyncProvider ou IAnchorSyncProvider. Un fournisseur standard implémente IKnowledgeSyncProvider, ISyncProvider, ISynchronousDataRetriever et ISynchronousNotifyingChangeApplierTarget (ou, dans le cas des fournisseurs asynchrones, les versions asynchrones).

  • Le magasin de données est un magasin quelconque pour lequel vous écrirez un fournisseur.

  • Le protocole de transfert des données détermine la façon dont les modifications de données sont transmises entre deux fournisseurs.

• Éléments fournis par Sync Framework.

  • Selon si le code utilisé est managé ou non, l'application communique avec un orchestrateur de synchronisation (SyncOrchestrator) ou une session de synchronisation (ISyncSession), qui communique ensuite avec chaque fournisseur de synchronisation, dirige le processus de synchronisation et communique l'état, les conflits et les erreurs à l'application cliente.

  • Le runtime de synchronisation aide les fournisseurs à effectuer des tâches de synchronisation courantes, telles que la gestion des métadonnées, la détection de conflit et l'application des modifications.

• Éléments qui sont écrits par le développeur ou fournis par Sync Framework, en fonction du fournisseur et des spécifications de l'application.

  • Le magasin des métadonnées contient les métadonnées dont se sert Sync Framework pour déterminer quelles modifications chaque fournisseur doit sélectionner et appliquer au magasin de données utilisé. Le magasin des métadonnées peut être séparé du magasin de données (par exemple, une base de données ou un fichier distinct), ou intégré au magasin (par exemple, une table supplémentaire dans une base de données). En général, le fournisseur de synchronisation gère les métadonnées requises pour la synchronisation. Toutefois, en fonction de l'implémentation du réplica, il peut être plus utile pour certaines parties de la gestion des métadonnées d'être effectuée par un composant séparé, tel qu'un service qui nettoie des des métadonnées obsolètes à des heures planifiées et non pendant la synchronisation. Les métadonnées obligatoires et la façon dont elles sont stockées et fonctionnent dépendent du fournisseur utilisé. Pour plus d'informations sur les spécifications des métadonnées pour chaque type de fournisseur, consultez Gestion des métadonnées pour les fournisseurs simples et Métadonnées requises pour les fournisseurs standard.

    Le fournisseur simple protège presque entièrement le développeur d'interagir avec le magasin des métadonnées. Il utilise une implémentation de service de stockage des métadonnées inclus avec Sync Framework. Les fournisseurs personnalisés standard peuvent utiliser cette implémentation ou ils peuvent utiliser : soit une autre implémentation selon l'API de service de stockage des métadonnées, soit une implémentation complètement personnalisée qui stocke des métadonnées dans un magasin séparé ou dans le magasin de données. Pour plus d'informations, consultez Gestion des métadonnées pour les fournisseurs standard.

Fournisseur simple ou fournisseur standard

Dans la plupart des cas nous recommandons d'utiliser un fournisseur simple, mais vous devez d'abord comprendre les hypothèses qui ont été avancées dans la conception de l'API de fournisseur simple :

• Les magasins de données à synchroniser ne prennent en charge aucun type de suivi des modifications, ou prennent uniquement en charge le suivi des modifications par ancrage.

  Une ancre est un objet qui indique quels éléments dans un magasin de données ont changé depuis la dernière session de synchronisation. Dans les magasins qui ne disposent d'aucun suivi des modifications ou du seul suivi des modifications par ancrage, les mises à jour de la connaissance de synchronisation interviennent pendant la session de synchronisation (de façon asynchrone), plutôt que lors de la modification dans le magasin (de façon synchrone). Si de nombreuses sessions de synchronisation se produisent simultanément sur un réplica particulier, la performance peut être affectée. Par conséquent, si une application requiert une forte concurrence et que chaque magasin de données prend en charge des mises à jour synchrones de la connaissance de synchronisation, utilisez un fournisseur standard.

• Le réplica requiert un seul type d'élément à synchroniser.

• En raison de limitations du magasin de données ou des spécifications de l'application, les métadonnées doivent être stockées à l'extérieur du magasin de données.

  Les fournisseurs simples stockent des métadonnées à l'aide de l'implémentation du service de stockage des métadonnées inclus avec Sync Framework. Les métadonnées sont stockées séparément des données qu'elles décrivent, ce qui présente deux problèmes potentiels :

  • Si les métadonnées sont stockées à distance, elles peuvent être complètement indisponibles pendant une session de synchronisation. Par exemple, la connexion réseau entre les deux réplicas à synchroniser est disponible, mais la connexion au serveur qui héberge les métadonnées ne l'est pas.

  • La cohérence transactionnelle entre les données et les métadonnées ne sont pas garanties. Le stockage des métadonnées sur le même ordinateur que les données est recommandé, mais la prise en charge transactionnelle n'est pas disponible à moins que vous utilisiez un fournisseur standard et des métadonnées de stockage dans le magasin de données (ou une transaction distribuée pour mettre à jour les deux magasins). Notez que les fournisseurs standard peuvent également utiliser le service de stockage des métadonnées, mais ils ne sont pas obligatoires comme dans le cas des fournisseurs simples.

Si les spécifications de votre application sont cohérentes avec ces hypothèses, nous vous recommandons d'utiliser des fournisseurs simples. Pour plus d'informations sur les fournisseurs simples, consultez Implémentation d'un fournisseur personnalisé simple. Pour plus d'informations sur les fournisseurs standard, consultez Implémentation d'un fournisseur personnalisé standard.

Présentation des types de participants de Sync Framework

Sync Framework peut être utilisé pour synchroniser des données entre des participants de différentes fonctionnalités. Un participant est un périphérique ou un service qui peut être synchronisé avec d'autres systèmes qui exécutent Sync Framework.

Sync Framework prend en charge les types de participants suivants :

• Participant complet

• Participant proxy

• Participant partiel

• Participant simple

Participant complet

Un participant complet héberge localement le runtime et stocke les métadonnées. Les participants complets peuvent participer aux scénarios de synchronisation d'égal à égal car les deux participants peuvent démarrer la synchronisation.

Deux participants complets dans la synchronisation d'égal à égal

Participant partiel

Un participant partiel peut stocker les métadonnées de synchronisation mais ne peut pas les traiter. Un participant partiel compte sur plusieurs participants complets pour héberger le runtime et démarrer la synchronisation. Les données peuvent circuler entre ces participants car ils peuvent porter les métadonnées de synchronisation à plusieurs maîtres et communiquer ces métadonnées à n'importe quel autre participant complet. Les participants partiels ne peuvent pas participer aux scénarios d'égal à égal, car ils ne sont pas en mesure de traiter les métadonnées ou d'héberger le runtime. Les clés USB et les téléphones portables qui ont des capacités de stockage sont des exemples de participants partiels.

L'illustration suivante montre comment un participant complet, tel qu'un ordinateur, est synchronisé avec un participant partiel, tel qu'un téléphone mobile. Le participant complet énumère ou filtre les modifications pour le participant partiel et stocke les métadonnées sur le participant partiel. Cela permet à un autre participant complet de synchroniser ce participant partiel.

Synchronisation d'un participant complet avec un participant partiel

Participant simple

Un participant simple ne stocke pas les métadonnées, ne peut pas héberger le runtime et peut ne pas utiliser le suivi des modifications. Un participant simple compte sur un participant complet unique pour tout faire en ce qui concerne l'énumération des modifications, l'application des modifications et la manipulation et le stockage des métadonnées. Dans la mesure où un participant simple ne peut pas stocker de métadonnées, il peut agir uniquement en tant que nœud terminal partenaire avec un participant complet unique qui transfère les données de et vers d'autres participants.

L'illustration suivante montre un participant complet qui utilise le service de stockage des métadonnées pour stocker les métadonnées pour un participant simple et qui exécute tous les aspects de la synchronisation pour le participant simple. Le magasin des métadonnées est utilisé pour effectuer le suivi des modifications liées au participant simple, mais est stocké sur le participant complet en raison des limitations de stockage du participant simple.

Participant complet qui utilise le service de stockage des métadonnées pour synchroniser un participant simple

Participant proxy

Un participant proxy démarre la synchronisation pour un fournisseur distant en gérant les appels localement et en les transférant au fournisseur distant, tel qu'une base de données stockée sur un serveur.

Sécurité Remarque
Sync Framework n'assure ni l'authentification ni le chiffrement entre le fournisseur proxy et le fournisseur distant. Pour éviter tout accès non autorisé ou toute falsification, le canal de communication entre le fournisseur proxy et le fournisseur distant doit être sécurisé à l'aide d'un mécanisme de chiffrement et d'authentification mutuelle approprié, tel que SSL (Secure Sockets Layer).

L'illustration suivante montre la synchronisation d'un fournisseur de participant complet avec fournisseur proxy. Remarquez que le fournisseur proxy se contente d'envoyer des commandes et des métadonnées sur le réseau au fournisseur distant. Le fournisseur distant existe sur le serveur de base de données et implémente la logique réelle utilisée pour la synchronisation. La ligne rouge en pointillé représente une limite d'ordinateur.

Synchronisation d'un participant complet avec un participant proxy

L'illustration suivante montre comment Sync Framework peut être utilisé pour synchroniser des fournisseurs distants de l'application qui démarre la synchronisation. L'application de contrôle peut connecter deux services Web ou appareils Smart Device qui doivent être synchronisés. Remarquez que les deux fournisseurs locaux sont des fournisseurs proxy pour les fournisseurs distants. Les lignes rouges en pointillé représentent des limites d'ordinateurs.

Application centrale qui synchronise deux participants proxy

Voir aussi

Concepts

Sélection des composants de Sync Framework appropriés
Implémentation d'un fournisseur personnalisé simple
Implémentation d'un fournisseur personnalisé standard
Implémentation d'une application de synchronisation
Exemples Sync Framework