$30 off During Our Annual Pro Sale. View Details »

Streaming HTTP : savoir communiquer via des flux

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.

Mickael BARON

November 19, 2020
Tweet

More Decks by Mickael BARON

Other Decks in Programming

Transcript

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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…)

    View Slide

  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

    View Slide

  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…) ?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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 » ?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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 »

    View Slide

  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

    View Slide

  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 TO WHERE

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide