Architecture

Un système basé évènement est un paradigme de communication distribué qui est formé par un ensemble de composants : les serveurs d’évènements qui forment eux-mêmes le ser-vice d’évènements et les utilisateurs (consommateurs ou producteurs). L’architecture d’un

système publier/souscrire dépend donc de la relation entre ces composants. Nous retrouvons principalement deux classes d’architectures : le modèle client-serveur et le modèle pair-à-pair.

1. Modèle client-serveur

Suivant ce modèle, un composant peut servir comme un serveur d’évènements ou un utilisateur. Un serveur d’évènements reçoit les évènements, les mémorise et les diffuse. Un serveur d’évènements collabore avec les autres serveurs d’évènements pour atteindre quelques propriétés, telles que la scalabilité. Un utilisateur agit comme producteur, consommateur ou les deux à la fois. Nous retrouvons quatre types de topologies décrivant la connexion entre les serveurs d’évènements [52] :

– topologie en étoile (serveur centralisé) ; – topologie hiérarchique ;

– topologie en anneau ;

– topologie de polygone irrégulier. a. Topologie en étoile

Suivant cette topologie, le service d’évènements repose sur une entité unique nommée broker. Cette entité est responsable de mémoriser les souscriptions provenant des consom-mateurs et de notifier les consomconsom-mateurs selon leurs souscriptions. Cette topologie permet l’échange d’évènements entre les producteurs et les consommateurs de manière asynchrone.

Comme le montre la Figure 2.4, quatre producteurs, de P1 à P4, publient des évènements

pour être reçus par les souscrits de A1 à A4. Un souscrit peut recevoir des évènements de

l’un des fournisseurs. La notion clé est l’existence d’un seul serveur qui agit en médiateur entre les producteurs et les souscrits (consommateurs) [52].

Cette topologie est assez simple mais elle a l’inconvénient qu’une panne affectant un broker du service d’évènements cause la panne de tout le système. De plus, un système publier/souscrire avec cette topologie souffre du problème de scalabilité puisqu’elle ne permet pas de supporter un grand nombre d’utilisateurs et de gérer un grand nombre d’évènements.

Chapitre 2

Figure ^{2.4 – Topologie centralisée d’un système publier/souscrire}

b. Topologie hiérarchique

La topologie hiérarchique est distinguée par la relation hiérarchique entre les serveurs

d’évènements. Comme le montre la Figure 2.5, chaque serveur, identifié de B1 à B5, sert

un certain nombre d’utilisateurs, C1 à C6. Les utilisateurs peuvent être soit des souscrits ou des producteurs. Les serveurs d’évènements se connectent à un serveur parent (root). Dans cette topologie, la communication entre serveur-serveur et client-serveur suit le même protocole. Ainsi, un serveur ne distingue pas entre les autres serveurs et ses clients. Le but de l’organisation hiérarchique est la scalabilité. Le serveur parent reçoit les évènements publiés et les souscriptions émises de l’ensemble de ses utilisateurs, mais transmet à son sous-arbre uniquement les évènements destinés à lui. Le serveur parent agit comme un contrôleur d’accès en maintenant le trafic de son sous-arbre [52].

Figure ^{2.5 – Topologie hiérarchique d’un système publier/souscrire}

Nous notons pour cette topologie qu’une panne affectant un serveur de l’arbre cause la panne de tous les serveurs qui lui sont connectés (au dessous de lui dans la hiérarchie).

c. Topologie en anneau

Comme montré par la Figure 2.6, la relation entre les serveurs d’évènements est bidirec-tionnelle. Le graphe de connexion entre les serveurs d’évènements est un anneau. La com-munication entre les serveurs se fait selon un protocole de comcom-munication bidirectionnelle pour échanger les souscriptions et les publications. Le protocole serveur-serveur est différent du protocole client-serveur dans le type et dans la quantité des informations échangées. Pour une communication serveur-serveur, les deux nœuds d’extrémité maintiennent des informa-tions l’un pour l’autre. Mais pour une connexion client-serveur, le client peut générer une souscription et être aussi le destinataire final d’une publication, et de l’autre côté, le serveur

sert comme un point d’accès ou un routeur pour transmettre des messages [52].

Le protocole de routage pour cette topologie est assez compliqué surtout pour détecter les mailles et le plus court chemin pour l’acheminement des évènements entre les serveurs.

Chapitre 2

Figure ^{2.6 – Topologie en anneau d’un système publier/souscrire}

d. Topologie de polygone irrégulier

La topologie de polygone irrégulier est une topologie en anneau générique. Ainsi, le graphe du réseau est un graphe générique (voir la Figure 2.7) où il peut exister plusieurs chemins entre deux serveurs. Semblablement à la topologie en anneau, cette topologie permet des communications bidirectionnelles entre deux serveurs.

C1 C4 Protocole serveur-serveur C5 C6 B1 B2 B5 C1 C2 C3 Protocole serveur-serveur B1 B2 B3 B4 C9 C8 C7 Protocole client-serveur

Figure ^{2.7 – Topologie de polygone irrégulier d’un système publier/souscrire}

Comme la topologie en anneau, le protocole de routage sur cette topologie est assez compliqué pour la détection du chemin le plus court vu l’existence d’anneaux.

2. Modèle Pair-à-Pair

Dans le modèle pair-à-pair, tous les nœuds sont égaux comme présenté dans la Figure

2.8. Il n’y a ni nœuds serveurs, ni nœuds clients dans ce modèle. Ainsi, chaque nœud peut

agir comme un producteur, un consommateur (souscrit), une racine d’un arbre de multicast, un nœud interne d’un arbre de multicast, ou une combinaison raisonnable de ceux-ci.

Figure ^{2.8 – Le modèle pair-à-pair}

Cette topologie évite le recours à des serveurs externes pour développer le service d’évè-nements. En effet, les terminaux des utilisateurs du système publier/souscrire peuvent être utilisés comme des serveurs d’évènements. Ceci minimise le coût de développement d’une plateforme fondée sur un système publier/souscrire de topologie P2P.