Ce rapport représente l'un des modéles d'exécution des systèmes répartis

1. Universit´e d’Oran 1 Ahmed Ben Bella
Facult´e des sciences exactes et appliqu´ees
D´epartement d’informatique
Le mod`ele de communication par ´ev´enement
(Publish-Subscribe)
R´ealis´e par
Khadidja BOUKREDIMI
Responsable du module
Mme Fatima Zohra
BELLOUNAR
sp´ecialit´e : RESIN
Niveau : Master 2
Ann´ee scolaire : 2017-2018

2. Table des Mati`eres
1 Introduction 3
2 Mod`ele de communication par ´ev´enement (publish-subscribe) 3
3 Entit´es du syst`eme publish-subscribe 3
4 Types d’architectures 4
5 S´emantique de consultation des boites aux lettres 5
6 Diff´erents types de publish-subscribe 5
7 Qualit´e de service dans un syst`eme publish-subscribe 6
8 Domaines d’application 7
9 Conclusion 7
1

3. Liste des figures
1 Infrastructure de communication. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Architecture du service d’´ev´enement centralis´e. . . . . . . . . . . . . . . . . . . . 4
3 Architecture du service d’´ev´enement r´epartis. . . . . . . . . . . . . . . . . . . . 4
4 Architecture du service d’´ev´enement `a bus de message. . . . . . . . . . . . . . . 5
5 Le mod`ele bas´e sur sujet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6 Le mod`ele hi´erarchique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2

4. 1 Introduction
Les syst`emes r´epartis impliquent maintenant des milliers d’entit´es potentiellement distribu´ees
dans le monde entier dont l’emplacement et les comportements peuvent varier tout au long de
la dur´ee de vie du syst`eme. Ces contraintes motivent la demande de mod`eles et de syst`emes
de communication plus flexibles, ce qui refl`ete la nature dynamique et d´ecoupl´ee des applica-
tions. La communication synchrone Peer to Peer conduit `a des applications rigides et statiques.
Le mod`ele de communication Publish-Subscribe pr´econise une forme d’interaction faiblement
coupl´ee requise dans les syst`emes ´evolutifs. C’est un style d’interaction bas´e sur les ´ev´enements
qui fournit un d´ecouplage fort dans le temps, l’espace et la synchronisation.
2 Mod`ele de communication par ´ev´enement (publish-
subscribe)
Un syst`eme publish-subscribe est constitu´e par un ensemble de noeuds (appel´es courtiers, en
anglais brokers) connect´es par un r´eseau, qui se coordonnent entre eux afin d’envoyer les
´ev´enements publi´es `a tous (et ´eventuellement seulement) aux abonn´es int´eress´es. Chaque
participant `a un syst`eme de communication publish-subscribe peut jouer le rˆole d’un pro-
ducteur (publisher) ou d’un abonn´e (subscriber) d’informations. Les producteurs produisent
des informations sous la forme d’´ev´enements, qui sont ensuite consomm´es par les consomma-
teurs. Les consommateurs ne sont pas directement connus par les producteurs, mais ils sont
indirectement adress´es en fonction du contenu des ´ev´enements. Cette forme d’anonymat dis-
socie compl`etement les producteurs des consommateurs, permettant ainsi ´eventuellement des
d´eploiements `a grande ´echelle. Le paradigme publish-subscribe est un paradigme de messagerie
asynchrone.
Figure 1: Infrastructure de communication.
3 Entit´es du syst`eme publish-subscribe
Les clients de ce syst`eme sont divis´es en fonction de leur rˆole en ´editeurs (publishers), qui
agissent comme producteurs d’informations, et les abonn´es (subscribers), qui agissent comme
consommateurs d’informations.
Sur le plan op´erationnel, l’interaction entre les noeuds clients et le syst`eme publish/subscribe
s’effectue au moyen d’un ensemble d’op´eration de base ex´ecut´ees par les clients sur le syst`eme
et vice-versa. L’´editeur soumet une information e (c’est-`a-dire un ´ev´enement) au syst`eme pub-
lish/subscribe en ex´ecutant l’op´eration publish(e). G´en´eralement, un ´ev´enement est structur´e
3

5. comme un ensemble de paires attribut-valeur. Chaque attribut a un nom, une chaˆıne de car-
act`ere simple et un type. Le type est g´en´eralement l’un des types de donn´ees primitifs d´efinis
dans les langages de programmation ou les langages de requˆete (par exemple : entier, r´eel, chaˆıne
de caract`ere, etc.). Du cot´e des abonn´es, l’int´erˆet aux ´ev´enements sp´ecifiques est exprim´e par
des abonnements (subscriptions). Un abonnement σ est un filtre sur une partie du contenu de
l’´ev´enement (ou l’ensemble de celui-ci), exprim´e par un ensemble de contraintes qui d´ependent
de la langue d’abonnement. Un abonn´e installe et supprime un abonnement σ du syst`eme
pub/sub en ex´ecutant respectivement les op´erations subscribe(σ) et unsubscribe(σ).
Un ´ev´enement e correspond (matches) `a un abonnement σ s’il satisfait toutes les contraintes
d´eclar´ees sur les attributs correspondant. la tˆache qui v´erifie `a chaque fois qu’un ´ev´enement e
correspond `a un abonnement σ est appel´ee matching.
4 Types d’architectures
• Architecture du service d’´ev´enement centralis´e : (Hub and spoke) c’est une ar-
chitecture en ´etoile dont le centre est le broker. Le service centralis´e de gestion des
´ev´enements dialogue en point `a point avec les clients producteurs ou consommateurs.
Figure 2: Architecture du service d’´ev´enement centralis´e.
• Architecture du service d’´ev´enement r´eparti : (Snowflake) dans ce mod`ele d’architecture
les courtiers coop`erent pour offrir un service r´eparti de gestion d’´ev´enements.
Figure 3: Architecture du service d’´ev´enement r´epartis.
• Architecture du service d’´ev´enement `a bus de message : les courtiers coop`erent
au moyen d’un protocole `a diffusion des ´ev´enements par exemple : le protocole multicast.
4

6. Figure 4: Architecture du service d’´ev´enement `a bus de message.
5 S´emantique de consultation des boites aux lettres
Il y a deux modes de consultation des boites `a letter :
• Mode Pull : le consommateur consulte sa boite pour traiter les ´ev´enements en attente.
• Mode Push : le consommateur attache une m´ethode `a chaque type d’´ev´enement.
L’occurrence d’un ´ev´enement d´eclenche automatiquement le traitement associ´e.
6 Diff´erents types de publish-subscribe
Les diff´erents mod`eles du syst`eme pub/sub sont le mod`ele bas´e sur sujet, le mod`ele hi´erarchique,
le mod`ele bas´e sur contenu, le mod`ele bas´e sur type, le mod`ele bas´e sur concept et le mod`ele
bas´e sur XML .
• Le mod`ele bas´e sur sujet
Les ´ev´enements sont regroup´es en sujets, c’est-`a-dire qu’un consommateur d´eclare son
int´erˆet pour un sujet particulier pour recevoir tous les ´ev´enements se rapportant `a ce
sujet. Chaque sujet correspond `a un canal logique reliant chaque producteur `a tous les
consommateur int´eress´es. Le principal inconv´enient de ce mod`ele est lorsque un consom-
mateur s’int´eresse `a un sous-ensemble d’´ev´enements li´es `a un sujet sp´ecifique, il re¸coit
´egalement tous les autres ´ev´enements appartenant au mˆeme sujet.
Figure 5: Le mod`ele bas´e sur sujet.
• Le mod`ele hi´erarchique
Contrairement au mod`ele pr´ec´edent, les sujets sont organis´es en une structure hi´erarchique.
Chaque ´ev´enement est ´etiquet´e par le sujet dans lequel il est publi´e. Les consommateurs
5

7. ´emettent des souscriptions contenant les sujets qui les int´eressent. Lorsqu’un consomma-
teur souscrit un sujet, il recevra tous les ´ev´enements publi´es dans ce sujet ainsi que dans
tous les sujets pr´esent dans le sous-arbre correspondant.
Figure 6: Le mod`ele hi´erarchique.
• Le mod`ele bas´e sur contenu
Les consommateurs expriment leur int´erˆet en sp´ecifiant des conditions sur le contenu des
´ev´enements qu’il souhaitent recevoir. En d’autres termes, une souscription est une requˆete
form´ee d’un ensemble de contraintes compos´ees par des op´erateurs de disjonction ou de
conjonction. Le service de notification d’´ev´enements filtre les ´ev´enements inutiles avant
de notifier un consommateur. L’avantage du syst`eme bas´e sur le contenu est sa flexibilit´e.
Il fournit au consommateur seulement l’information dont il a besoin.
7 Qualit´e de service dans un syst`eme publish-subscribe
L’absence d’une relation directe entre le producteur et le consommateur rend tr`es difficile la
d´efinition et l’application de toute politique de qualit´e de service de bout en bout. Le d´ecouplage
peut introduire dans plusieurs sens un comportement non d´eterministe, ce qui signifie que le
comportement exact du syst`eme est difficile `a sp´ecifier, `a appliquer et `a contrˆoler.
Le non-d´eterminisme peut agir sur trois aspects fondamentaux de la qualit´e de service et de la
s´ecurit´e, qui sont :
1. Livraison fiable
La livraison fiable d’un ´ev´enement signifie la d´etermination des consommateurs qui doivent
recevoir un ´ev´enement publi´e. Dans l’infrastructure pub/sub, l’´ev´enement se d´eplace en
traversant plusieurs sauts du r´eseau. Chaque saut de routage peut ˆetre une source de non-
d´eterminisme dˆu aux transmission sur des canaux WAN asynchrones ou `a une surcharge
de nœud temporaire. Cela peut mener `a la perte de notification qui doit ˆetre remise aux
consommateurs pr´evus. La retransmission d’´ev´enements peut contribuer `a r´eduire le com-
portement non-d´eterministe ainsi que l’augmentation de la probabilit´e qu’un r´ecepteur
pr´evus obtienne l’information.
2. Livraison `a temps (rapidit´e)
Les applications en temps r´eel n´ecessitent souvent un contrˆole strict sur le temps ´ecoul´e par
une information pour atteindre tous ses consommateurs. Ils sont d´eploy´es sur une infras-
tructure d´edi´ee qui assure la livraison synchrone de messages. Une infrastructure pub/sub
qui s´epare les producteurs et les consommateurs peut introduire un non-d´eterminisme `a
travers des anomalies de routage et des retards de traitement impr´evisibles `a chaque
nœud. Pour atteindre la rapidit´e, le syst`eme pub/sub devrait privil´egier les communica-
tions point `a point o`u le d´ecouplage est limit´e ou totalement absent.
6

8. 3. S´ecurit´e et confiance
Les probl`emes de s´ecurit´e repr´esentent un probl`eme majeur dans les syst`emes pub/sub.
Le consommateur souhaite faire confiance `a l’authenticit´e des ´ev´enements qu’il re¸coit du
syst`eme, c’est-`a-dire qu’il a ´et´e g´en´er´e par un producteur fiable et que les informations
qu’il contient n’ont pas ´et´e corrompues. Ainsi que les consommateurs doivent ˆetre fiables
pour ce qui concerne les souscriptions qu’ils ´emettent.
Concevoir des mesures de confiance implique de connaˆıtre avec certitude l’identit´e des
autres participants et ceci est clairement en contraste avec l’anonymat qui est `a la base
de pub/sub lui mˆeme.
8 Domaines d’application
Les domaines d’application qui b´en´eficient de l’architecture de pub/sub incluent la gestion de
la chaˆıne logistique, les applications financi`eres, les applications de e-commerce, les syst`emes
de workflow (KoalaBus) et le g´enie logiciel (coop´eration entre outils de d´eveloppement, par
exemple : SoftBench, ToolTalk, DecFuse).
9 Conclusion
Ce rapport comprend une ´etude de l’un des mod`eles d’ex´ecution des syst`emes r´epartis, qui
est le mod`ele de communication par ´ev´enement (publish/subscribe). Ce syst`eme achemine
de mani`ere dynamique les ´ev´enements depuis les sources vers les utilisateurs int´eress´es, et il
constitue un service de communication extrˆemement utile lorsqu’il n’est pas clair `a l’avance qui
a besoin de quelle information.Nous avons montr´e les diff´erents types de son architecture et les
diff´erents mod`eles de ce syst`eme. Nous avons ainsi donn´e des exemples de la fa¸cons dont le
non-d´eterminisme peut agir sur la qualit´e de service et la s´ecurit´e. A la fin, nous avons illustr´e
quelques domaines qui utilisent l’architecture du syst`eme pub/sub.
References
[1] Leonardo Querzoni, Sirio Scipioni, Sara Tucci-Piergiovanni, Antonino Virgillito. Quality of
Service in Publish/Subscribe Middleware. Universit´a di Roma La “Sapienza”, 2006.
[2] Ying Liu, Beth Plale. Survey of Publish Subscribe Event Systems. Indiana University, Bloom-
ington, IN 47405-7104.
[3] Nitesh Agarwal. Publish-Subscribe based communication model. National Institute of Tech-
nology, Rourkela, Orissa-769008, May-2014.
7