Streaming HTTP : savoir communiquer via des flux

Ce support de cours est une introduction aux technologies HTTP pour savoir communiquer via des flux et réaliser des communications de type "Push Serveur". Après avoir dressé les besoins de ce type de technologies, une présentation détaillée est donnée sur WebSocket et Server-Sent Event.

Transcript

1. SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2023) mailto:baron.mickael@gmail.com ou mailto:baron@ensma.fr mickael-baron.fr mickaelbaron Savoir communiquer via des flux et par messages
2. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 2 Creative Commons Contrat Paternité Partage des Conditions Initiales à l'Identique 2.0 France creativecommons.org/licenses/by-sa/2.0/fr Licence
3. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 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, 2 000 forums et jusqu'à 5 000 messages par jour mickael-baron.fr mickaelbaron
4. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 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
5. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 5 Ressources : liens sur le Web † Articles, rapports et billets de blog † www.diva-portal.se/smash/get/diva2:1133465/FULLTEXT01.pdf † nordsecmob.aalto.fi/en/publications/theses2013/thesis_estep † aquil.io/articles/a-comparison-between-websockets-server-sent-events-and-polling † www.baeldung.com/java-websockets † www.baeldung.com/rest-vs-websockets † codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9 † golb.hplar.ch/2018/02/Access-Server-Sent-Events-from-Java.html † Github † github.com/KeKsBoTer/websocket-vs-sse † Conférences vidéos † www.youtube.com/watch?v=MmVRkkZ7qHk&t=357s † Présentations † fr.slideshare.net/aneveu/le-streaming-dapi-pourquoi-et-comment-transformer-vos-apis- statiques-en-donnes-temps-rel † fr.slideshare.net/arungupta1/nuts-and-bolts-of-websocket-devoxx-2014
6. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 6 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push via HTTP/1, HTTP/2 et HTML5 † WebSocket † SSE † gRPC †Technologies basées sur l’envoi de messages † AMQP
7. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Problématique : retourner de la donnée en continue 7 Réception de messages via les réseaux sociaux (Twitter) 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, Discord…)
8. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Problématique : pourquoi c’est important ? 8 † 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
9. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Contexte : se poser les bonnes questions ? 9 † À 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…) ?
10. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Contexte : actuellement pour mettre à jour ? 10 † 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
11. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Contexte : Polling (XHR-Polling) 11 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
12. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Contexte : Long Polling 12 † 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
13. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Solutions existantes pour faire du Streaming d’API 13 † 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 HTTP/1 et HTML5 † Comet, WebHooks, WebSocket* et Server Sent Event (SSE)* † Basée sur HTTP/2 † gRPC* † Basées sur l’envoi de messages † AMQP* * Etudiées dans la suite
14. SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2023) mailto:baron.mickael@gmail.com ou mailto:baron@ensma.fr mickael-baron.fr mickaelbaron WebSocket, SSE et gRPC
15. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 15 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push via HTTP/HTML5 et HTTP/2 † Comprendre WebSocket et SSE † Support des navigateurs † Performances † À l’heure du choix ? † Implémentations disponibles † Technologies basées sur l’envoi de messages
16. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket : généralités 16 † 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
17. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket : en détail 17 † 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)
18. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket : en détail 18 † 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
19. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket : en détail 19 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 † Principe : dès l’ouverture de la connexion WebSocket communication bidirectionnelle depuis le client et le serveur Communication full-duplex. 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)
20. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket : en détail 20 † Support des navigateurs web † Source : caniuse.com/#search=websocket Les navigateurs mobiles prennent également en charge WebSocket excepté Opera Mini Les WebSockets sont pris en compte par tous les navigateurs « desktop » Un client WebSocket n’est pas forcément un navigateur web
21. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Server-Sent Event : généralités 21 † 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
22. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 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} †emojitracker.com : utilisation des Emojis sur Twitter † emojitrack-gostreamer.herokuapp.com/subscribe/eps † À compléter … $ curl -H "Accept:text/event-stream" \ https://stream.wikimedia.org/v2/stream/mediawiki.page-create
23. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 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
24. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 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 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
25. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Server-Sent Event : en détail 25 † Principe : dès l’ouverture de la connexion Server-Sent Event 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
26. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Server-Sent Event : en détail 26 † Support des navigateurs web † Source : caniuse.com/#search=server%20sent%20event Server-Sent Event sont presque pris en compte par tous les navigateurs exceptés ceux de Microsoft IE et Edge Les navigateurs mobiles prennent également en charge SSE excepté Opera Mini Possibilité d’utiliser des Polyfills qui sont des fonctions permettant de simuler des fonctionnalités non prises en compte par les anciens navigateurs web
27. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron gRPC : généralités 27
28. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket et Server-Sent Event : performances 29 † 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 † nordsecmob.aalto.fi/en/publications/theses2013/thesis_estep † Expérimentations disponibles † blog.arungupta.me/rest-vs-websocket-comparison-benchmarks † matthiasnehlsen.com/blog/2013/05/01/server-sent-events-vs- websockets † github.com/KeKsBoTer/websocket-vs-sse
29. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket et Server-Sent Event : performances 30 † 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
30. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket et Server-Sent Event : performances 31 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)
31. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket et Server-Sent Event : performances 32 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)
32. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron WebSocket et SSEvent : à l’heure du choix 33 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
33. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Implémentations 34 † La grande majorité des plateformes de développements fournissent le support de WebSocket et SSE † 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
34. SOA – Streaming et Messages Mickaël BARON – Février 2019 (Rév. Novembre 2023) mailto:baron.mickael@gmail.com ou mailto:baron@ensma.fr mickael-baron.fr mickaelbaron Envoi de messages : AMQP
35. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron 36 Plan du cours † Problématique et contexte † Solutions existantes pour communiquer via des flux † Technologies Push via HTTP/HTML5 et HTTP/2 † WebSocket † SSE † gRCP † Technologies basées sur l’envoi de messages † AMQP
36. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages : pourquoi ? 37 † 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
37. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages : principaux concepts 38 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 » ?
38. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages : standards et produits 39 † 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
39. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : généralités 40 † 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
40. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : concept message 41 † 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
41. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : concepts 42 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 » † 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) Router Conditions de routage « Bindings »
42. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : comparaison avec les emails 43 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
43. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : Exchanges en détail 44 † 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 <queue> TO <exchange> WHERE <condition>
44. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Queue.Bind Queue1 TO amq.direct WHERE Routing-Key = value1 Envoi de messages AMQP : Type d’Exchanges (partie 1) 45 † Direct : délivre le message si Routing-Key matche une valeur « Echange » Direct « Queue » Queue1 « Queue » Queue2 Routing-Key = value1 « Queue » Queue3 Queue.Bind Queue2 TO amq.direct WHERE Routing-Key = value1 † Fanout : délivre le message à toutes les queues « bindées » « 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
45. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : Type d’Exchanges (partie 2) 46 † Topic : délivre le message si Routing-Key matche 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 = # † Headers : délivre le message si les en-têtes matchent un pattern « 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
46. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : consommateur 47 † 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
47. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages AMQP : patron de conception 48 † 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
48. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Modèle de communication AMQP : Competing Consumers 49 † 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 1 2 3 Une seule file d’attente Une tâche décrite par un ensemble de messages † Exemple : compresser des vidéos Producteur N consommateurs (basé sur le même code client) Messages envoyés de manière séquentielle (round-robin) « Echange » Direct
49. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Modèle de communication AMQP : Pub/Sub 50 † Quand ? Avertir en même temps plusieurs consommateurs † Favorise des traitements différents d’une même tâche 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 † Exemple : gestion de logs avec des adapters différents « Echange » Fanout
50. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Modèle de communication AMQP : Topics 51 † Quand ? Avertir des consommateurs en fonction de sujets † Permet au producteur de cibler indirectement des consommateurs 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 † Exemples † messagerie instantanée via un abonnement par sujet † Internet Of Thing (IOT) *.bricolage
51. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Modèle de communication AMQP : Request/Reply 52 † Quand ? Être averti qu’un consommateur à traiter la tâche † Permet au consommateur de communiquer avec le producteur 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) † Exemples † gestion d’une transaction † dans une chaîne de traitement
52. Streaming et Messages - M. Baron - Page mickael-baron.fr mickaelbaron Envoi de messages : bilan 53 † 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)