Tout sur PubSub

Cet article est une traduction de « All About PubSub », écrit Gaston Dombiak et Matt Tucker, publié le 17 avril 2006. avec leur autorisation.

Tout sur PubSub

Publish-subscribe (pubsub) est une puissante extension au protocole XMPP. Il peut être vu comme le RSS de la messagerie instantanée ; les utilisateurs souscrivent à un élément et reçoivent les notifications lorsque celui-ci est mis à jour. Le principe général de la notification sur lequel se base le procotole peut être trouvé à sur le web.

Quelques exemples :

  • Google Alerts : entrez une requête ou choisissez un sujet, le service Google Alerts vous enverra alors par e-mail les derniers événement en rapport trouvés par Google (web, news, etc.).
  • Forums watches : les membres de la communauté de igniterealtime.org sont familiers avec les fonctionnalités de surveillance, qui les notifie par e-mail lorsqu’un nouveau post a été effectué dans une catégorie, un forum ou un fil de discussion.

Dans cet article, nous couvrirons le protocole pubsub en détail puis discuterons de ses applications possibles.

Détails du protocole

Collection et noeuds racine

Collection et noeuds racine (image)

La spécification pubsub est définie par la XEP-0060 et est pleinement implémentée dans Wildfire 2.6 et supérieure. Les objets primaires dans un service pubsub sont appelés « noeuds », auxquels les utilisateurs souscrivent et et sur lesquels ils publient. Les noeuds sont hiérarchiques (structure en arbre) et ont deux types :

  • Feuille : un noeud qui contient des éléments publiés.
  • Noeud : un noeud qui contient les autres noeuds.

Lorsqu’un utilisateur souscrit à un noeud, ce noeud est soit :

  • Une feuille et les notifications sont envoyées quand de nouveaux éléments sont publiés dessus.
  • Un noeud et les notifications sont faites lors des additions/effacements des noeuds enfants ou lorsque de nouveaux éléments sont publiés sur les noeuds enfants.

Le diagramme de droite montre à la fois des noeuds et des feuille. Il y a toujours un noeud racine. Dans ce cas, nous avons des noeuds enfants « musique » et « films ». Le noeud musique contient les groupes « cure » et « depeche mode ».

Modèles d’accès et de publication

Pubsub fournit un cadre riche de permissions. Les noeuds peuvent avoir différents modèles d’accès et de publication. Un modèle d’accès définit qui est autorisé à souscrire et récupérer les éléments tandis qu’un modèle de publication définit qui est autorisé à publier des éléments sur le noeud.

Les options de modèles d’accès sont :

  • Ouvert : tout le monde peut souscrire et récupérer des éléments.
  • Autorise : les requêtes de souscription doivent être approuvées par un propriétaire et seuls les souscripteurs peuvent récupérer les éléments.
  • Liste blanche (whitelist) : seuls ceux présents sur une liste blanche peuvent souscrire et récuperer les éléments.
  • Présence : les entités qui ont souscrit à la présence du propriétaire du noeud peuvent souscrire au noeud et récupérer les éléments du noeud.
  • Roster : les entités qui ont souscrit à la présence du propriétaire du noeud et dans le roster de groupe spécifié peuvent souscrire au noeud et récupérer les éléments de ce noeud.

Les options du modèle de publication sont :

  • Ouvert tout le monde peut publier des éléments sur le noeud.
  • Publieurs : les propriétaires et publieurs sont autorisés à publier des éléments sur le noeud.
  • Souscripteurs : les propriétaires, les publieurs et les souscripteurs sont autorisés à publier des éléments sur le noeud.

Souscrire à des noeuds

Lorsqu’un utilisateur souscrit à un noeud, il spécifie la configuration de la souscription. Les informations de configuration peuvent inclure une date d’expiration, des mots-clefs qui vont être utilisés pour filtrer les notifications ou des préférences sur la date de livraison des notifications. En utilisant l’exemple de modèle pubsub du dessus, un utilisateur pourrait souscrire à tous les évènements de « depeche mode » sur un mois, avec un filtre sur le mot-clef « shows ».

Les utilisateurs peuvent souscrire plusieurs fois à un noeud. Chaque souscription à un noeud peut avoir des informations de configuration différentes telles que le filtrage par mots-clefs et des préférences de notifications. Lorsque l’utilisateur a souscrit plusieurs fois, alors le service pubsub va envoyer une seule notification vers l’utilisateur si plusieurs souscriptions ont été affectées pas le même élément publié. Cette optimisation minimise l’impact de trop nombreux souscripteurs avec plusieurs notifications sur le même élément publié.

Une fois qu’un utilisateur a demandé une souscription à un noeud, la nouvelle souscription est sujette au modèle d’accès mentionné au-dessus. Si le noeud utilise le modèle de permission « autorise », alors les propriétaires du noeud vont recevoir un message demandant d’approuver la nouvelle demande de souscription. Les propriétaires de noeuds peuvent aussi récupérer la liste complète des demandes de souscriptions n’importe quand. Les utilisateurs ne recevront pas les notifications du noeud tant que la souscription n’est pas approuvée. Une fois que l’approbation est donnée, la souscription devient « active » et les utilisateurs vont recevoir les éléments les plus récemment publiés mais aussi les éléments qui seront publiés plus tard.

Propriétaires et souscripteurs

Propriétaires et souscripteurs (image)

Le diagramme au-dessus montre l’exemple précédent de service pubsub, mais avec un propriétaire et un souscripteur. L’utilisateur Joe détient tous les noeuds musique. Sally a souscrit à Depeche Mode et attend que sa souscription au noeud film soit approuvée.

Publication d’évènements

Publication

Publication (image)

Chaque fois qu’un évènement est publié, il contient zéro, un ou plusieurs éléments. Chaque élément peut optionnellement contenir une charge (données). Pour continuer notre exemple, Joe veut publier l’agenda des prochains concerts de Depeche Mode. Chaque représentation pourrait être représentée par un élément individuel, avec les détails de l’information inclus dans la charge de chaque élément.

Les souscripteurs ont aussi la possibilité de demander au service la liste des éléments publiés n’importe quand. En d’autres termes, pubsub prend en charge l’envoi ciblé (« push ») et la demande (« pull ») dans la notification d’évènements.

Conclusion

Nous avons couvert les bases du protocole pubsub et comment il peut être utilisé en tant que service de publication et de souscription. Mais pubsub ne sert pas seulement aux notifications d’évènements ; le framework est assez puissant pour prendre en charge un certain nombre de cas d’usages de collaboration intéressants&nsbp;:

  • * Stockage et partage de fichiers : les utilisateurs pourraient partager des fichiers en des endroits communs et être notifiés lorsque des fichiers sont ajoutés, effacés ou mis à jour. Les permissions pubsub pourraient être utilisées pour un contrôle riche sur qui est autorisé à créer et lire des fichiers.
  • Tableaux blancs (whiteboards) : un tableau blanc pourrait être représenté comme un noeud. Les utilisateurs pourraient collaborativement modifier le tableau et voir les changements refletés en temps-réel.
  • Systèmes de ventes et ventes aux enchères : pubsub pourrait être utilisé pour distribuer les prix changeants des pièces aux parties intéressées.

Avez-vous votre propre idée sur la manière dont pubsub pourrait être utilisé ? Nous vous attendons de pied ferme !