EA2014-Publish-Subscribe



= Présentation =


 * Enseignants : Georges-Pierre Bonneau, Didier Donsez (EA2014)
 * Sujet : Publish-Subscribe
 * Date : 14 Novembre 2014
 * Auteur : Tianming GUO

Mots Clés
Notification d'événement, MQTT, Multicast, Content-based classification, Architecture Middleware avec Patterns et Frameworks

= Synthèse =

Introduction
Le publish-subscribe est un modèle de messagerie où les expéditeurs de messages qui s'appelés publishers, ne programmez pas les messages à envoyer directement à des récepteurs spécifiques qui s'appelés subscribers.


 * Publisher: Envoie des événements ou des messages relatifs à un "Topic"(class d'évenement, resource URL, etc) spécifique.


 * Subscriber: Exprime son intérêt dans un ou plusieurs "Topic" et reçoit tous les messages appartenant à ces "Topic".


 * Mediator(optionnel): Registrer l'abonnement de publisher, recevoir notification d''événement de publisher, filtrer l'événement, routing vers subscriber



Les messages sont classés par catégories (ou classes de messages) auxquelles les récepteurs s'abonnent (subscribe).



Ce mécanisme peut, entre autres, permettre de mettre en place des publications de brèves et articles, des abonnements à des flux d'information, des tuples, des marque-pages partagés, des systèmes d’enchères et d’échanges, des catalogues en ligne, des systèmes de workflow ou encore des notifications événements.

Le modèle publish-subscribe a le potentiel d'atteindre le découplage des activités de coopération: en raison du régime d'interaction indirecte, les activités ne connaissent pas les uns les autres; ils ne pas interagir directement pour la synchronisation, et ne doivent pas être activés en même temps; ils peuvent être créées dynamiquement et enlevés, et peuvent librement entrer ou sortir de l'application.

En raison du mécanisme de filtrage des événements, le nombre de notifications est réduite: une activité est seulement informé des événements qu'il estime pertinentes; le filtrage basé sur le contenu permet cette sélection soit dynamique.

Avantages
Absolument, le plus grand avantage d'utiliser publish-subcribe est la capacité de briser nos applications en petits modules, plus faiblement couplés, qui peut également améliorer la gestion générale.

Publish-subscribe est aussi un modèle qui nous incite à réfléchir sur les relations entre les différentes parties de votre application, identifier ce que les couches doivent observer ou écouter de comportement et qui doivent pousser les notifications concernant le comportement survenant dans d'autres parties de nos applications.

Inconvénients
Par conséquent, certains des problèmes avec le modèle publish-subscribe fait découlent de son principal avantage. En découplant les éditeurs des abonnés, il peut parfois être difficile d'obtenir des garanties que certaines parties des applications fonctionnent comme on espére.

Par exemple, les publishers peuvent faire l'hypothèse que un ou plusieurs subscribers sont à leur écoute. Dire que nous sommes en utilisant une telle hypothèse se connecter ou erreurs de sortie en ce qui concerne certains processus de demande. Si le subscriber d'effectuer les accidents d'exploitation (ou pour quelque raison ne parvient pas à fonctionner), le publisher n'aura pas une façon de voir ça en raison de la nature découplé du système.

Utilisation dans les Protocoles et API communs

 * OSGi EventAdmin Service
 * RabbitMQ : Modèle Publish/Subscribe
 * UPnP GENA pour gérer la notification d'événement
 * MQTT : Publisher + serveur + Subscriber
 * PubSubHubBub : PUB + HUB + SUB
 * Real-Time Publish-Subscribe (RTPS) : UDP Multicast
 * Robot Operating System : L'interaction entre les noeuds

PubSub-as-a-Service Providers

 * PubNub
 * Octoblu
 * Google Cloud Pub/Sub
 * Superfeedr