Comment concevoir un protocole d'application de haut niveau et un format de données pour la synchronisation des métadonnées entre les périphériques et le serveur?

Question

Je cherche des conseils sur la meilleure façon de concevoir un protocole d'application de haut niveau pour synchroniser les métadonnées entre les périphériques des utilisateurs finaux et un serveur.

Mon objectif: l'utilisateur peut interagir avec les données de l'application sur n'importe quel appareil, ou sur le web. Le but de ce protocole est de communiquer les modifications apportées à un noeud final à d'autres points de terminaison via le serveur et de s'assurer que tous les périphériques conservent une image cohérente des données de l'application. Si l'utilisateur effectue des modifications sur un périphérique ou sur le Web, le protocole envoie les données vers le référentiel central, d'où les autres périphériques peuvent les extraire.

D'autres idées de conception:

• Je l'appelle « métadonnées en cours de synchronisation » parce que les charges utiles sont très petits, sous la forme d'ID d'objet et de petites métadonnées relatives à ces ID. Lorsque les terminaux client récupèrent de nouvelles métadonnées via ce protocole, ils extraient les données d'objet réelles d'une source externe basée sur ces métadonnées. Récupérer les "vraies" données de l'objet est hors de portée, je parle seulement de la synchronisation des métadonnées ici.
• Utilisation de HTTP pour le transport et JSON pour le conteneur de charge utile. La question est essentiellement de savoir comment concevoir au mieux le schéma de charge utile JSON. Je veux que ce soit facile à mettre en œuvre et à maintenir sur le Web et à travers les ordinateurs de bureau et les appareils mobiles. La meilleure approche semble être une requête/réponse HTTP simple basée sur un timer ou un événement sans aucun canal persistant. De plus, vous ne devriez pas avoir un doctorat pour le lire, et je veux que ma spécification soit sur 2 pages, pas 200.
• L'authentification et la sécurité sont hors de portée pour cette question: supposons que les demandes sont sécurisées et authentifiées.
• L'objectif est la cohérence éventuelle des données sur les appareils, ce n'est pas entièrement en temps réel. Par exemple, l'utilisateur peut effectuer des modifications sur un périphérique en étant hors ligne. Lors d'une nouvelle mise en ligne, l'utilisateur effectue une opération de "synchronisation" pour pousser les changements locaux et récupérer les changements à distance.
• Cela dit, le protocole devrait soutenir ces deux modes de fonctionnement:
  • A partir de zéro sur un appareil, devrait être en mesure de tirer le tableau d'ensemble de métadonnées
  • « synchronisation que vous allez ». Lorsque vous regardez les données de deux périphériques côte à côte et que vous effectuez des modifications, il est facile de les transformer en messages individuels courts que l'autre appareil peut recevoir en temps réel (sous réserve de la décision de contacter le serveur pour la synchronisation).

Comme exemple concret, vous pouvez penser à Dropbox (ce n'est pas ce que je travaille, mais il aide à comprendre le modèle): sur une gamme d'appareils, l'utilisateur peut gérer un Fichiers et dossiers: déplacez-les, créez-en d'autres, supprimez-en d'anciens, etc. Et dans mon contexte, les «métadonnées» sont la structure des fichiers et des dossiers, mais pas le contenu réel du fichier. Et les champs de métadonnées seraient quelque chose comme le nom du fichier/dossier et l'heure de la modification (tous les appareils devraient voir le même temps de modification).

Un autre exemple est IMAP. Je n'ai pas lu le protocole, mais mes objectifs (moins les corps de messages réels) sont les mêmes.

Se sent comme il y a deux grandes approches comment cela se fait:

• messages transactionnels. Chaque changement dans le système est exprimé en delta et les extrémités communiquent avec ces deltas.Exemple: changesets DVCS. REST: communication du graphe d'objet en entier ou en partie, sans trop se soucier des changements atomiques individuels.

EDIT: quelques-unes des réponses disent à juste titre qu'il ya d'information ne suffit pas à propos de l'application pour offrir des suggestions assez bon. La nature exacte de l'application peut être gênante, mais une application de lecture de RSS très basique est une assez bonne approximation. Donc, disons que la spécification de l'application est la suivante:

• Il existe deux classes: alimentations et articles.
• Je peux ajouter, renommer et supprimer des flux. L'ajout d'un flux s'y abonne et commence à recevoir des éléments pour ce flux. Je peux également réorganiser l'ordre d'affichage des flux dans l'interface utilisateur.
• En lisant les éléments, ils sont marqués comme lus. Je ne peux pas les marquer non lus ou faire autre chose avec eux.
• Sur la base de ce qui précède, le modèle d'objet est:
  • « nourrir » a des attributs « url », « Sélectionnez » et « displayorder » (displayorder est l'indice d'aliments pour animaux dans la liste des aliments de l'interface utilisateur; réordonnancement se nourrit change localement le displayOrder de tous les flux de sorte que les index restent uniques et séquentiels). "Item" a les attributs "url" et "non-lu", et plusieurs-à-un "feed" (chaque élément appartient à un flux). "url" se comporte également comme GUID pour l'élément.
  • Le contenu de l'élément réel est téléchargé localement sur chaque périphérique et ne fait pas partie de la synchronisation.

Sur la base de cette conception, je peux configurer mon application sur un seul appareil: ajouter un tas d'aliments, de renommer et de les réorganiser et lire quelques articles sur eux, qui sont ensuite marqués comme non lus. Lorsque je change de périphérique, l'autre périphérique peut synchroniser la configuration et afficher la même liste de flux avec les mêmes noms, ordres et mêmes états lus/non lus.

(modifier final)

Ce que je voudrais dans les réponses:

• Y at-il quelque chose d'important je suis parti au-dessus? Contraintes, objectifs?
• Quelle est la bonne lecture d'arrière-plan à ce sujet? (Je me rends compte que c'est ce que beaucoup de cours d'informatique discutent avec beaucoup de longueur et de détail ... j'espère court-circuiter en regardant un cours intensif ou des pépites.)
• Quels sont de bons exemples de tels protocoles Je pourrais modéliser après, ou même utiliser hors de la boîte? (Je parle Dropbox et IMAP ci-dessus ... Je devrais probablement lire la RFC IMAP.)

Answer 1

Quelques pensées:

1). Quelles hypothèses pouvez-vous faire concernant la fiabilité de la diffusion des notifications de modification? Et la fiabilité de la commande de ces notifications? Mon instinct est qu'il est préférable de tolérer la perte et l'ordre erroné en revenant à demander la livraison complète des métadonnées.

2). En effet, vous avez un flux de méta-données et aussi un flux de données. Quelles hypothèses pouvez-vous faire au sujet de leur ordre relatif. Pouvez-vous recevoir des données nouvellement versionnées avant l'arrivée des métadonnées? Devinant encore, je soupçonne que cela peut arriver.Je suppose que les données utiles doivent contenir des informations sur les métadonnées. Les clients pourraient donc actualiser leurs méta-données quand ils en ont besoin?

3). Est-il possible que des données correspondant à deux versions différentes des métadonnées arrivent sur le périphérique? Je suspecte "oui". Avec quelle rapidité un client peut-il gérer cela?

4). Les métadonnées peuvent devoir inclure des informations de présentation ou de validation.

Answer 2

Les métadonnées que vous avez décrites sont représentées graphiquement. Cependant, le passage à la piste OWL/RDF peut être tout à fait un changement. Fondamentalement, vous avez juste besoin d'avoir des propriétés sur des objets qui peuvent être liés (par exemple, des fichiers alignés dans la hiérarchie). De ce point de vue, JSON est un choix très naturel pour l'accès aux propriétés, s'il est combiné avec l'API REST. Si cette approche est choisie, je recommande d'abord d'étudier le Open Data Protocol. Par ailleurs, pourquoi ne pas simplement utiliser un système de contrôle de version, par ex. Git, et ont les propriétés en tant qu'objets JSON dans les fichiers texte dans le système? Si chaque objet a ses métadonnées stockées dans un très petit morceau JSON dans un fichier séparé, le système sera automatiquement capable de faire la plupart des mises à jour et la résolution automatique des conflits. La plupart des systèmes de contrôle de version fournissent de bons APIS pour ce type de but.

Answer 3

Si je voulais le faire rapidement sans trop de temps de développement, j'utiliserais simplement WebDAV sur le (s) fichier (s) de métadonnées et ferais. OMI, cela devrait couvrir la plupart de vos besoins. En outre, l'utilisation d'un protocole existant présente des avantages par rapport aux protocoles personnalisés dans les bibliothèques existantes et ne passe pas du temps à réinventer le code d'implémentation du protocole de roue et de débogage.

EDIT: Si vous rendez le fichier de configuration facile à fusionner en tant que fichier, il vous suffit de conserver 2 versions du fichier de configuration. Une version de base, comment la config a regardé la dernière fois que nous avons synchronisé. Une version actuelle des métadonnées, puis vous obtenez la version des métadonnées de votre homologue. Avec ces 3 fichiers, vous effectuez une simple fusion à trois, vous décidez automatiquement des conflits pour la version la plus récente et c'est tout. Garder la version de base est important. Maintenant, si vous fusionnez avec plusieurs clients, vous pouvez fusionner à différents points et donc exiger une version différente de votre fichier de configuration comme base. Conservez simplement tous les résultats d'une synchronisation, jusqu'à ce que vous l'écrasiez avec une nouvelle synchronisation de ce client homologue. En théorie, vous pouvez avoir des fichiers de configuration XML, mais la fusion à trois voies de fichiers XML est juste douloureuse et les outils ne sont pas encore là, à mon humble avis. Le format spécifique ou le type d'application n'a pas vraiment d'importance.

Answer 4

Jetez un oeil à cette spécification de la proposition de protocole

SLEEP - SYNCABLE LIGHTWEIGHT EVENT EMITTING PERSISTENCE