SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2025) mailto:[email protected] ou mailto:[email protected] mickael-baron.fr mickaelbaron Savoir communiquer via des flux et par messages 

Streaming et Messages - M. Baron - Page 2 Creative Commons Contrat Paternité Partage des Conditions Initiales à l'Identique 2.0 France creativecommons.org/licenses/by-sa/2.0/fr Licence 

Streaming et Messages - M. Baron - Page 3 À propos de l’auteur … † Mickaël BARON † Ingénieur de Recherche au LIAS † https://www.lias-lab.fr † Equipe : Ingénierie des Données et des Modèles † Responsable des plateformes logicielles, « coach » technique † Ancien responsable Java de Developpez.com (2011-2021) † Communauté Francophone dédiée au développement informatique † https://java.developpez.com † 4 millions de visiteurs uniques et 12 millions de pages vues par mois † 750 00 membres, 2000 forums et jusqu'à 5000 messages par jour mickael-baron.fr mickaelbaron 

Streaming et Messages - M. Baron - Page 4 Déroulement du cours † Pédagogie du cours † Des bulles d’aide tout au long du cours † Survol des principaux concepts en évitant une présentation exhaustive † Logiciels utilisés † Navigateur Web † Pré-requis † Service web REST † Protocole HTTP 

Streaming et Messages - M. Baron - Page 5 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push † WebSocket † SSE † gRPC † WebRTC †Technologies basées sur l’envoi de messages † AMQP 

Streaming et Messages - M. Baron - Page Problématique : retourner de la donnée en continue 6 Réception de messages via les réseaux sociaux (Discord) Afficher les informations des capteurs d’un drone : altimètre, GPS, vidéo (Mission Planner) Dialoguer avec de l’audio et de la vidéo (Zoom, Teams, etc.) 

Streaming et Messages - M. Baron - Page Problématique : pourquoi c’est important ? 7 † Une application doit donner l’impression d’être vivante sans quoi l’utilisateur peut penser qu’il y a un problème † Retourner l’information la plus « fraîche » du serveur pour des applications critiques (capteurs, valeurs boursières, etc.) † Avec les dispositifs mobiles, l’ère de la notification à outrance pour éviter le fameux « Fear of Missing Out » † Éviter de solliciter le serveur inutilement pour éviter une consommation d’énergie inutile 

Streaming et Messages - M. Baron - Page Contexte : se poser les bonnes questions ? 8 † À quelle fréquence de rafraichissement ? † Dès que possible ? Une fois par heure ? Une fois l’an ? † Aucune idée ? † Est-ce important de consommer la donnée tout de suite ? † Est-ce pour de l’affichage immédiat (station sol pour un drone) ? † Est-ce pour l’intégrer dans une chaîne de traitement (workflow) ? † Qui est responsable de la mise à jour de la donnée ? † Le responsable de l’affichage (Polling) ? † Celui qui possède l’information (Push) ? † Quelle technologie choisir ? † Une technologie énergivore (CPU, réseau, etc.) ? 

Streaming et Messages - M. Baron - Page Contexte : actuellement pour mettre à jour ? 9 † La technique dite de Polling (tirer l’information) est la plus classique (celle utilisée par les services web) † Mise en œuvre † Appuyer sur le bouton « Refresh » du navigateur (web) † Lancer un processus qui toutes les n sec. invoque un service web † Variante † Long Polling 

Streaming et Messages - M. Baron - Page Contexte : Polling (XHR-Polling) 10 Client † Principe : client sollicite le serveur même s’il n’y pas de nouvelles données Serveur Temps Temps Requête AJAX Réponse (vide) Réponse (vide) Requête AJAX Nouvelles informations Délai avant prochaine requête (généralement fixé) Réponse (non vide) Requête AJAX L’accès aux nouvelles données ne pourra se faire qu’à la prochaine itération Requête AJAX † Inconvénients † Nombreuses requêtes inutiles † Le délai entre chaque requête difficile à prévoir † Au minimum une requête pour chaque nouvelle information du serveur † Peu devenir lent s’il y a beaucoup de clients 

Streaming et Messages - M. Baron - Page Contexte : Long Polling 11 † Principe : la requête est interrompue côté serveur jusqu’à l’arrivée d’une nouvelle donnée puis, envoi de la réponse Client Serveur Temps Temps Requête AJAX Réponse Nouvelles informations Requête Longue durée Réponse Longue durée (non vide) Nouvelles informations Réponse Longue durée (non vide) Requête Longue durée Requête longue durée suspendue jusqu’à la présence d’une nouvelle donnée La réponse longue durée est retournée uniquement s’il y a un résultat † Inconvénients † Une fois la nouvelle donnée reçue réitérer l’opération † Au minimum une requête pour chaque nouvelle donnée † Comet ? † Collection de techniques avant HTML5 pour faire du Long Polling 

Streaming et Messages - M. Baron - Page Solutions existantes pour faire du Streaming d’API 12 † Utilisation de technologies basées sur une communication de type « Push Serveur » † Le dialogue est lancé par le serveur et notifie les clients † Quelles sont les technologies disponibles ? † Basées sur les technologies Push † Comet, WebHooks, WebSocket* et Server Sent Event (SSE)* † gRPC** † WebRTC** † Basées sur l’envoi de messages † AMQP* * Etudiées dans la suite ** Arrive très prochainement 

SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2025) mailto:[email protected] ou mailto:[email protected] mickael-baron.fr mickaelbaron WebSocket, SSE, gRPC et WebRTC 

Streaming et Messages - M. Baron - Page 14 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push † Comprendre WebSocket, SSE et WebRTC † Support des navigateurs † Performances † À l’heure du choix ? † Implémentations disponibles † Technologies basées sur l’envoi de messages 

Streaming et Messages - M. Baron - Page WebSocket : généralités 15 † WebSocket est à la fois un protocole de communication et une API (premiers travaux 2008) † Protocole de communication † Full-duplex (bidirectionnel) sur TCP † Standardisé par IETF en 2011 : tools.ietf.org/html/rfc6455 † Interface de programmation (API) † Standardisé par W3C en 2012 : www.w3.org/TR/websockets Client Serveur Client Serveur Ou Half Duplex Client Serveur Full Duplex Et 

Streaming et Messages - M. Baron - Page WebSocket : en détail 16 † Nature des messages † Texte ou binaire (pour texte possibilité d’utiliser le format JSON) † Protocole † HTTP (le plus courant pour les navigateurs) † Autres protocoles supportés † Terminologie † WebSocket client † qui se connecte à un unique WebSocket serveur (l’URL via le schème ws:// ou wss://) † ne peut envoyer un message qu’à un seul WebSocket serveur † WebSocket serveur † qui reçoit plusieurs connexions de WebSocket client † qui peut envoyer un message à un ou plusieurs WebSocket client (broadcast) 

Streaming et Messages - M. Baron - Page WebSocket : en détail 17 † Requête et réponse HTTP † Cycle de vie (client et serveur) définie dans le standard W3C † onOpen : quand la connexion avec un WebSocket est réalisée † onMessage : quand un message est envoyé d’un WebSocket † onError : quand une erreur est provoquée † onClose : quand la connexion est fermée (par le client ou serveur) † Ne peut se reconnecter automatiquement GET ws://localhost:8026/chatwebsocket/chat HTTP/1.1 Host: localhost:8026 Connection: Upgrade Upgrade: websocket Origin: http://localhost:8026 Sec-WebSocket-Version: 13 Sec-WebSocket-Key: 2BmJzxYsb/ZfR3/ZAITKjA== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits HTTP/1.1 101 Web Socket Protocol Handshake Connection: Upgrade Sec-WebSocket-Accept: wonfz9jNMdz7L2HK9RewAt+QFvk= Upgrade: websocket Requête HTTP Réponse HTTP 

Streaming et Messages - M. Baron - Page WebSocket : principe 18 Client Serveur Temps Temps onOpen (serveur) onOpen (client) Nouvelles informations onMessage (client) Nouvelles informations onMessage (serveur) Nouvelles informations onMessage (serveur) Nouvelles informations onMessage (serveur) Nouvelles informations onMessage (client) onClose (serveur) onClose (client) Ouverture d’une connexion entre un WebSocket client et un WebSocket serveur † Dès l’ouverture de la connexion WebSocket, communication bidirectionnelle depuis le client et le serveur Communication bidirectionnelle. Possibilité d’envoyer et recevoir en même temps des messages Possibilité d’envoyer ou de recevoir des messages de manière exclusive La fin d’une connexion (peut être décidée par le WebSocket client ou serveur) 

Streaming et Messages - M. Baron - Page WebSocket : support des navigateurs web 19 † Source : caniuse.com/websockets Les navigateurs mobiles prennent également en charge WebSocket excepté Opera Mini Les WebSockets sont pris en compte par tous les navigateurs bureaux récents Un client WebSocket n’est pas forcément un navigateur web 

Streaming et Messages - M. Baron - Page Server-Sent Event : généralités 20 † Server-Sent Event (SSE) est une technologie unidirectionnelle proposée initialement par WHATWG en 2006 † WHATWG : Web Hypertext Application Technology Working Group † Collaboration non officielle des développeurs de navigateurs web † Protocole de communication † HTTP (pas de protocole spécifique) † Uniquement serveur vers le client (exemple : navigateur web) † Interface de programmation (API) † Standardisé au W3C en 2015 : www.w3.org/TR/eventsource 

Streaming et Messages - M. Baron - Page Server-Sent Event : généralités 21 

Streaming et Messages - M. Baron - Page Server-Sent Event : où trouver des accès SSE 22 † stream.wikimedia.org : flux sur les données de Wikimedia † stream.wikimedia.org/v2/stream/{stream} † Un serveur accessible gratuitement ? † Merci de m’avertir par email à [email protected] $ curl -H "Accept:text/event-stream" \ https://stream.wikimedia.org/v2/stream/mediawiki.page-create 

Streaming et Messages - M. Baron - Page Server-Sent Event : en détail 23 † Description d’un événement † event : le type d’événement (ex : add, remove…) † data : le contenu du message envoyé par le serveur (ex : « Hello ») † id : un identifiant (utile en cas de reprise déconnexion pour savoir quel était le dernier événement envoyé) † retry : temps en millisecondes pour une reconnexion du client vers le serveur (en cas de panne) † ‘:’ : commentaire † Nature de l’attribut data † Texte (possibilité d’utiliser le format JSON pour faire du binding) † Peut se reconnecter automatiquement via l’option retry retournée par le dernier événement 

Streaming et Messages - M. Baron - Page Server-Sent Event : en détail 24 † Requête et réponse HTTP † Cycle de vie (client uniquement) défini par le standard W3C † onOpen : quand une connexion au serveur est réalisée † onMessage : quand un message (événement) est reçu † onError : quand une erreur est déclenchée † onClose : quand la connexion est terminée GET /api/sse HTTP/1.1 Host: localhost:9992 Accept: text/event-stream HTTP/1.1 200 OK Content-Type: text/event-stream Transfer-Encoding: chunked : This is a new HelloWorld message and continue the communication. event: add-message id: 123 retry: 1000 data: HelloWorld Requête HTTP Réponse HTTP 

Streaming et Messages - M. Baron - Page Server-Sent Event : principe 25 † Dès l’ouverture de la connexion SSE, communication unidirectionnelle vers le client Client Serveur Temps Temps Requête (Accept: text/eventStream) Nouvelles informations onOpen (client) (ContentType: text/eventStream) onMessage (client) Nouvelles informations onMessage (client) Nouvelles informations onMessage (client) onClose (client) Ouverture d’une connexion entre le client et le serveur Nécessite d’utiliser un MediaType particulier : text/eventStream Communication unidirectionnelle. Envoi de messages uniquement du serveur vers le client La fin de la connexion peut être décidé par le client ou le serveur 

Streaming et Messages - M. Baron - Page Server-Sent Event : support des navigateurs web 26 † Source : caniuse.com/eventsource Server-Sent Event sont pris en compte par tous les navigateurs bureaux récents Les navigateurs mobiles prennent également en charge SSE excepté Opera Mini Les polyfills permettent de simuler des fonctionnalités absentes des anciens navigateurs 

Streaming et Messages - M. Baron - Page gRPC : généralités 27 

Streaming et Messages - M. Baron - Page WebRTC : généralités 29 † WebRTC permet de négocier une communication temps-réel et bidirectionnelle entre deux clients en mode point à point † Dédié principalement à la transmission de données vidéos, audios et aussi des données † WebRTC (comme WebSocket) est à la fois un protocole de communication et une API (premiers travaux 2011) † Protocole de communication : datatracker.ietf.org/wg/rtcweb † API de programmation : www.w3.org/TR/webrtc † Basé sur de nombreux protocoles déjà existants † SDP † ICE, STUN, TURN † SRTP (vidéos/audios), SCTP (données) 

Streaming et Messages - M. Baron - Page WebRTC : principe 30 Client (Point 1) Serveur Signalisation Signalisation Client (Point 2) Signalisation Médias (audio, vidéo et données) Interactive Connectivity Establishment (ICE) Direct / STUN / TURN 1 1 1 2 3 NAT NAT 

Streaming et Messages - M. Baron - Page WebRTC : mettre en relation les points d’accès 31 † Problématique : fournir un intermédiaire (signalisation) qui permet aux points d’accès de se découvrir † Comment accéder à un point d’accès (problématique du NAT) ? † Quels sont les codecs, les protocoles de transport et les médias ? † Utilisation d’un protocole de données appelé SDP (Session Description Protocol) basé sur un système clé / valeur † WebRTC ne définit pas de mécanisme de transport pour la signalisation, à vous de l’implémenter † Exemple : WebSocket (le plus courant) † Une fois le processus de signalisation terminée, l’intermédiaire ne sert plus 1 

Streaming et Messages - M. Baron - Page WebRTC : rechercher le meilleur chemin réseau 32 2 † Problématique : trouver un chemin réseau pour accéder à un point † Eléments de blocage (non exhaustifs) † NAT : partager une même adresse publique depuis un réseau local † Règles de pare-feu † Solutions † localhost : chemin direct, parfait pour les tests (mais pas pour la prod) † Serveur STUN : permet de connaitre l’IP publique et le port de sortie † Serveur TURN : joue le rôle de passe plat entre les points d’accès † Possibilité d’utiliser des serveurs publics STUN/TURN ou de déployer ses propres serveurs 

Streaming et Messages - M. Baron - Page WebRTC : transmettre les informations 33 3 † Problématique : quels protocoles de transport à utiliser en fonction du média (basés sur UDP) † Vidéo/Audio † SRTP (Secure RealTime Transport Protocol) † Tolérance à la perte † Données † SCTP (Stream Control Transmission Protocol) † Possibilité d’avoir plusieurs flux de données indépendants † Toutes les communications WebRTC sont chiffrées excepté pour un test en localhost 

Streaming et Messages - M. Baron - Page WebRTC : API en détail 34 † API détaillée dans ce document : www.w3.org/TR/webrtc † Principales interfaces de l’API † RTCPeerConnection : connexion entre 2 pairs † RTCDataChannel : gestion de la transmission de données † onOpen : quand une connexion au serveur est réalisée † onMessage : quand un message (événement) est reçu † onError : quand une erreur est déclenchée † MediaDevices : accès aux médias (caméra, micro, partage d’écran, vidéo) † MediaStreamTrack : piste audio ou vidéo à transmettre 

Streaming et Messages - M. Baron - Page WebRTC : en détail (uniquement données) 35 Client 1 Serveur Signalisation Temps Temps † Dès l’ouverture de la connexion WebRTC, communication bidirectionnelle entre les clients Client 2 Temps Processus de Signalisation Processus de Signalisation onOpen (client 2) onOpen (client 1) Nouvelles informations onMessage (client 2) Nouvelles informations onMessage (client 1) Nouvelles informations onMessage (client 2) Nouvelles informations onMessage (client 1) onClose (client 1) onClose (client 2) Communication bidirectionnelle. Possibilité d’envoyer et recevoir en même temps des messages La fin d’une connexion (peut être décidée par le client1 ou le client2) La signalisation permet de mettre en relation le client 1 et le client 2. Après la signalisation, la communication avec le serveur peut être interrompue 

Streaming et Messages - M. Baron - Page WebRTC : support des navigateurs web 36 WebRTC est pris en compte par tous les navigateurs, mais plus tardivement que WebSocket et SSE (standard plus récent) Les navigateurs mobiles prennent également en charge WebRTC † Source : caniuse.com/rtcpeerconnection 

Streaming et Messages - M. Baron - Page WebSocket et Server-Sent Event : performances 37 † Fournir des métriques de performance pour choisir la technologie la plus adaptée selon un contexte donné † Différentes études sur les performances WebSocket et SSE † www.diva-portal.se/smash/get/diva2:1133465/FULLTEXT01.pdf † www.timeplus.com/post/websocket-vs-sse † www.freecodecamp.org/news/server-sent-events-vs-websockets † Expérimentations disponibles † blog.arungupta.me/rest-vs-websocket-comparison-benchmarks † github.com/KeKsBoTer/websocket-vs-sse † github.com/Sh3b0/realtime-web 

Streaming et Messages - M. Baron - Page WebSocket et Server-Sent Event : performances 38 † Métrique étudiée † Temps total pour envoyer les messages † Comparatif (ce qui est comparable) † WebSocket client et serveur VS service web REST † WebSocket serveur VS Server-Sent Event † Protocole d’expérimentation † Varier le nombre de requête par client ou serveur (push) † Varier la valeur pour le « payload » † Mise en place de l’expérimentation † Code source : « coming soon » † Codes clients développés HTML/JS (version Java en préparation) † Codes serveurs développés en Java 

Streaming et Messages - M. Baron - Page WebSocket et Server-Sent Event : performances 39 0,00 1,00 2,00 3,00 4,00 5,00 6,00 7,00 8,00 9,00 10 100 500 1000 5000 10000 Temps (s) Number of requests (Payload = 1024 bytes) REST(Chrome) WebSocket (Chrome) 0,00 0,20 0,40 0,60 0,80 1,00 10 100 500 1000 5000 10000 Temps (s) Payload en bytes (Number of requests = 1000) REST(Chrome) WebSocket (Chrome) † REST Versus WebSocket (envoi et réception) 

Streaming et Messages - M. Baron - Page WebSocket et Server-Sent Event : performances 40 0,00 0,05 0,10 0,15 0,20 10 100 500 1000 5000 10000 Temps (s) Payload en bytes (Number of requests = 1000) REST (Chrome) SSE (Chrome) 0,00 0,05 0,10 0,15 0,20 0,25 0,30 0,35 0,40 0,45 10 100 500 1000 5000 10000 Temps (s) Number of requests (Payload = 1024 bytes) WebSocket (Chrome) SSE (Chrome) † WebSocket Versus SSE (serveur vers client en mode PUSH) 

Streaming et Messages - M. Baron - Page WebSocket et SSEvent : à l’heure du choix 41 Caractéristiques Web Socket Server-Sent Event Année de création 2008 2006 Nature du contenu Texte + Binaire Texte Protocole TCP/HTTP (navigateur) Autres protocoles supportés HTTP Communication Bidirectionnelle Serveur <=> Client Unidirectionnelle Serveur => Client Reprise à la connexion Non Oui Support des navigateurs web Complète Ne supporte pas IE et Edge Usages Chat de discussions, Outils collaboratifs Flux réseaux sociaux, valeurs boursières, notifications Performance (à relativiser …) Plus performant que SSE Moins performant que WebSocket Spécification du standard www.w3.org/TR/websockets www.w3.org/TR/eventsource 

Streaming et Messages - M. Baron - Page Implémentations 42 † La grande majorité des plateformes de développements fournissent le support de WebSocket, SSE et WebRTC † Plateforme .NET † Plateforme Java † Plateforme PHP † Les API permettent de † Développer la partie serveur (WebSocket et SSE) † Développer la partie cliente † Mapping Objet / Classe (Marshall, Unmarshall) † Accéder à la couche HTTP † Dans le cours suivant, nous utiliserons la plateforme Java † Outillée, gratuite, accessible, légère, respect des standards 

SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2025) mailto:[email protected] ou mailto:[email protected] mickael-baron.fr mickaelbaron Envoi de messages : AMQP 

Streaming et Messages - M. Baron - Page 44 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push † WebSocket † SSE † gRPC † WebRTC †Technologies basées sur l’envoi de messages † AMQP 

Streaming et Messages - M. Baron - Page Envoi de messages : pourquoi ? 45 † Postulats sur les technologies étudiées (REST, WS, SSE, etc.) † Le composant appelé existe et est disponible † Le réseau fonctionne et n’échoue pas à envoyer les messages † Intérêt d’une technologie basée sur l’envoi de message ? † Transmettre un message de manière répétée jusqu’à la réussite † Le composant émetteur ne se soucie pas du récepteur (asynchrone) † Communication asynchrone entre composants † Architecture à faible couplage † Favorise la montée en charge horizontale Horizontale Verticale 

Streaming et Messages - M. Baron - Page Envoi de messages : principaux concepts 46 Producteur Diffuseur Éditeur Consommateur Destinataire Abonné Technologies basées sur l’envoi de messages « Broker » de Messages Message Message Publier Consommer ? † Stratégie de choix d’un consommateur « Routage » ? † Gestion de la file d’attente « Queue » ? 

Streaming et Messages - M. Baron - Page Envoi de messages : standards et produits 47 † Nombreux standards ou produits (définissent leur propre protocole) pour définir un système d’envoi de messages † Standards existants (non exhaustif et en vrac) † AMQP : Advanced Message Queuing Protocol † JMS : Jarkarta Messaging API † STOMP : Streaming Text Oriented Messaging Protocol † XMPP : Extensible Messaging and Presence Protocol † MQTT : Message Queuing Telemetry Protocol 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : généralités 48 † AMQP est l’acronyme de Advanced Message Queuing Protocol † Standardisé à partir de 2003 au sein de l’organisme OASIS † Site web : www.amqp.org † Version courante : 1.0, mais la version la plus utilisée et complète est la 0.9.1 † Pourquoi AMQP ? † Le plus largement supporté par les outils † Le plus complet 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : concept message 49 † Un message est composé des informations suivantes † Des champs d’en-tête † La charge utile (payload) † Une clé de routage (Routing Key) † Les informations du message sont importantes pour aider à connaître le(s) consommateur(s) en fonction de la stratégie employée 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : concepts 50 † Un producteur publie un message dans un Exchange (routeur de messages) † En se basant sur des bindings (conditions de routage) le message est routé vers une file d'attente † Un consommateur récupère un message d'une Queue (file d’attente) Producteur Consommateur Message Message Publier Consommer « Broker » de Messages respectant le standard AMQP Routeur de message « Echange » File d’attente « Queue » File d’attente « Queue » File d’attente « Queue » Router Conditions de routage « Bindings » 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : comparaison avec les emails 51 Message ✉ AMQP File d’attente (Queue) Consommateur Routeur de ✉ (Exchange) Clé de routage Message Email Boite de messagerie Client d’email (Thunderbird) Mail Transfert Agent (MTA) To, Cc, Bcc 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : Exchanges en détail 52 † Les messages sont publiés dans un Exchange (routeur de messages) † La déclaration d’un Exchange se fait via une condition de routage (Binding) et trois informations sont nécessaires † Nom de la file d’attente (Queue) † Type (Direct, Fanout, Topic ou Headers) † Condition qui peut être fonction de la clé de routage du message Queue.Bind TO WHERE 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : Type d’Exchanges (partie 1) 53 † Direct : délivre le message si Routing-Key matche une valeur † Fanout : délivre le message à toutes les queues « bindées » Queue.Bind Queue1 TO amq.direct WHERE Routing-Key = value1 « Echange » Direct « Queue » Queue1 « Queue » Queue2 Routing-Key = value1 « Queue » Queue3 Queue.Bind Queue2 TO amq.direct WHERE Routing-Key = value1 « Echange » Fanout « Queue » Queue1 « Queue » Queue2 « Queue » Queue3 Queue.Bind Queue1 TO amq.fanout Queue.Bind Queue2 TO amq.fanout Routing-Key si présente non utilisée 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : Type d’Exchanges (partie 2) 54 † Topic : délivre le message si Routing-Key matche un pattern † Headers : délivre le message si les en-têtes matchent un pattern Queue.Bind Queue1 TO amq.topic WHERE Routing-Key = foo.* « Echange » Topic « Queue » Queue1 « Queue » Queue2 Routing-Key = foo.bar « Queue » Queue3 Queue.Bind Queue2 TO amq.topic WHERE Routing-Key = # « Echange » Headers « Queue » Queue1 « Queue » Queue2 Headers : format=pdf type=report « Queue » Queue3 Queue.Bind Queue2 TO amq.match WHERE format=pdf type=report x-match=all 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : consommateur 55 † Un consommateur est une connexion à une file d’attente † Une application cliente peut créer plusieurs consommateurs † Un consommateur est relié à une seule file d’attente † Plusieurs consommateurs peuvent être reliés à une file d'attente, mais un seul message est délivré † Si plusieurs messages à délivrer, c'est en mode « chacun son tour » (round- robin) † Pour avoir plusieurs consommateurs qui reçoivent un message en même temps il faut plusieurs files d’attente 

Streaming et Messages - M. Baron - Page Envoi de messages AMQP : patron de conception 56 † L’usage d’une technologie basée sur le standard AMQP à amener à développer des patrons de conception † Ce sont des modèles de communication couramment utilisés dans les architectures logicielles basées sur les services † Competing Consumers (File d’attente de travail) † Pub-Sub (Producteur-Consommateurs) † Topics † Request/Response 

Streaming et Messages - M. Baron - Page Modèle de communication AMQP : Competing Consumers 57 † Quand ? répartir une tâche sur plusieurs consommateurs † Favorise la montée en charge (« à plusieurs on travaille plus vite ») † Evite d’attendre la fin du traitement de la tâche † Exemple : compresser des vidéos 1 2 3 Une seule file d’attente Une tâche décrite par un ensemble de messages Producteur N consommateurs (basé sur le même code client) Messages envoyés de manière séquentielle (round-robin) « Echange » Direct 

Streaming et Messages - M. Baron - Page Modèle de communication AMQP : Pub/Sub 58 † Quand ? Avertir en même temps plusieurs consommateurs † Favorise des traitements différents d’une même tâche † Exemple : gestion de logs avec des adapters différents Autant de file d’attente que de consommateurs Une tâche décrite par un ensemble de messages Producteur N consommateurs (basé sur des codes clients différents) 1 1 « Echange » Fanout 

Streaming et Messages - M. Baron - Page Modèle de communication AMQP : Topics 59 † Quand ? Avertir des consommateurs en fonction de sujets † Permet au producteur de cibler indirectement des consommateurs † Exemples † messagerie instantanée via un abonnement par sujet † Internet Of Thing (IOT) Autant de file d’attente que de consommateurs Une tâche décrite par un ensemble de messages Producteur N consommateurs (basé sur des codes clients différents) 1 2 « Echange » Topic *.cuisine *.bricolage 

Streaming et Messages - M. Baron - Page Modèle de communication AMQP : Request/Reply 60 † Quand ? Être averti qu’un consommateur à traiter la tâche † Permet au consommateur de communiquer avec le producteur † Exemples † gestion d’une transaction † dans une chaîne de traitement Deux files d’attente Producteur et Consommateur « Echange » Direct « Echange » Direct Producteur et Consommateur Message consommé quand le consommateur est disponible (ne traite pas une réponse) 

Streaming et Messages - M. Baron - Page Envoi de messages : bilan 61 † Standards (AMQP) qui définissent un cadre d’utilisation † Modèles de communication qui permettent de construire des architectures en fonction des besoins applicatifs † Des produits qui ne s’appuient pas sur des standards † Kafka, Google Cloud Pub/Sub, Microsoft Azure Service Bus † Beaucoup de choses à traiter † Gestion des erreurs (que se passe-t-il si la file d’attente est saturée ?) † La mise en œuvre (voir cours suivant)