Cet article décrit les différents types de messages et les entités qui participent à une infrastructure de messagerie. Selon les exigences de chaque type de message, l’article recommande les services de messagerie Azure. Les options incluent Azure Service Bus Messaging, Azure Event Grid et Azure Event Hubs. Pour la comparaison des produits, consultez Comparer les services de messagerie.
Au niveau architectural, un message est un datagramme créé par une entité (producteur), afin de distribuer des informations afin que d’autres entités (consommateurs) puissent être conscientes et agir en conséquence. Le producteur et le consommateur peuvent communiquer directement ou éventuellement par le biais d’une entité intermédiaire (courtier de messages). Cet article se concentre sur la messagerie asynchrone à l’aide d’un courtier de messages.
Nous pouvons classifier les messages en deux catégories principales. Si le producteur attend une action du consommateur, ce message est une commande. Si le message informe le consommateur qu’une action a eu lieu, le message est un événement.
Commandes
Le producteur envoie une commande avec l’intention que le ou les consommateurs effectuent une opération dans l’étendue d’une transaction commerciale.
Une commande est un message de valeur élevée et doit être remise au moins une fois. En cas de perte d’une commande, toute la transaction commerciale peut échouer. En outre, une commande ne doit pas être traitée plusieurs fois. Cela peut entraîner une transaction erronée. Un client peut obtenir des commandes en double ou les facturer deux fois.
Les commandes sont souvent utilisées pour gérer le flux de travail d’une transaction d’entreprise à étapes. En fonction de la logique métier, le producteur peut s’attendre à ce que le consommateur accuse réception du message et signale les résultats de l’opération. Sur la base de ce résultat, le producteur peut choisir une action appropriée.
Événements
Un événement est un type de message qu’un producteur déclenche pour annoncer des faits.
Le producteur (connu sous le nom de serveur de publication dans ce contexte) n’attend aucune action.
Le ou les consommateurs intéressés peuvent s’abonner, écouter les événements et prendre des mesures en fonction de leur scénario de consommation. Les événements peuvent avoir plusieurs abonnés ou aucun abonné. Deux abonnés différents peuvent réagir à un événement avec des actions différentes et ne pas être conscients de leurs existences mutuelles.
Le producteur et le consommateur sont faiblement couplés et gérés indépendamment. Le producteur ne s’attend pas à ce que le consommateur accuse réception de l’événement. Un consommateur qui n’est plus intéressé par les événements peut se désabonner, ce qui le supprime du pipeline sans affecter le producteur ou les fonctionnalités globales du système.
Il existe deux catégories d’événements :
Le producteur déclenche des événements pour annoncer des faits discrets. La notification d’événement est un cas d’usage courant. Par exemple, Azure Resource Manager déclenche des événements lorsqu’il crée, modifie ou supprime des ressources. Un abonné de ces événements peut être une application logique qui envoie des messages électroniques d’alerte.
Le producteur déclenche des événements connexes dans une séquence, ou un flux d’événements, sur une période donnée. En règle générale, un flux est consommé pour une évaluation statistique. L’évaluation peut se produire dans une fenêtre temporelle ou à mesure que des événements arrivent. La télémétrie est un cas d’usage courant (par exemple le monitoring de l’intégrité et de la charge d’un système). Un autre cas est la diffusion d’événements à partir d’appareils IoT.
Un modèle courant pour l’implémentation de la messagerie d’événements est le modèle d’abonné-éditeur.
Rôle et avantages d’un courtier de messages
Un courtier de messages intermédiaire fournit les fonctionnalités de déplacement de messages du producteur au consommateur et peut offrir des avantages supplémentaires.
Découplage
Un courtier de messages dissocie le producteur du consommateur dans la logique qui génère et utilise les messages, respectivement. Dans un flux de travail complexe, le répartiteur peut encourager les opérations commerciales à être découplées et aider à coordonner le flux de travail.
Par exemple, une transaction commerciale unique nécessite des opérations distinctes qui sont effectuées dans une séquence de logique métier. Le producteur émet une commande qui signale à un consommateur de démarrer une opération. Le consommateur accuse réception du message dans une file d’attente distincte réservée à l’alignement des réponses pour le producteur. Une fois la réponse reçue, le producteur envoie un nouveau message pour démarrer l’opération suivante dans la séquence. Un consommateur différent traite ce message et envoie un message d’achèvement à la file d’attente de réponses. En utilisant la messagerie, les services coordonnent le flux de travail de la transaction entre eux.
Un courtier de messages fournit un découplage temporel. Le producteur et le consommateur n’ont pas besoin de s’exécuter simultanément. Un producteur peut envoyer un message au courtier de messages, quelle que soit la disponibilité du consommateur. Inversement, le consommateur n’est pas limité par la disponibilité du producteur.
Par exemple, l’interface utilisateur d’une application web génère des messages et utilise une file d’attente comme courtier de messages. Lorsque le consommateur est prêt, il peut récupérer des messages de la file d’attente et effectuer le travail. Le découplage temporel permet à l’interface utilisateur de rester réactive. Elle n’est pas bloquée pendant que le traitement asynchrone des messages.
Certaines opérations peuvent prendre du temps. Après avoir émis une commande, le producteur ne devrait pas avoir à attendre que le consommateur termine l’exécution de celle-ci. Un courtier de messages permet le traitement asynchrone des messages.
Équilibrage de la charge
Les producteurs peuvent poster un grand nombre de messages qui sont servis par de nombreux consommateurs. Utilisez un courtier de messages pour répartir le traitement entre les serveurs et améliorer le débit. Les consommateurs peuvent s’exécuter sur différents serveurs pour répartir la charge. Les consommateurs peuvent être ajoutés de manière dynamique pour faire évoluer le système en cas de nécessité ou de suppression dans le cas contraire.
Le modèle des consommateurs concurrents explique comment traiter simultanément plusieurs messages de façon à optimiser le débit, à améliorer la scalabilité et la disponibilité, et à équilibrer la charge de travail.
Niveau de charge
Le volume de messages générés par le producteur ou un groupe de producteurs peut être variable. Parfois, il peut y avoir un volume important entraînant des pics dans les messages. Au lieu d’ajouter des consommateurs pour gérer ce travail, un courtier de messages peut agir comme une mémoire tampon, et les consommateurs drainent progressivement les messages à leur propre rythme sans incidence sur le système.
Pour plus d’informations, consultez Modèle de nivellement de charge basé sur une file d’attente.
Messagerie fiable
Un courtier de messages permet de s’assurer que les messages ne sont pas perdus même en cas d’échec de la communication entre le producteur et le consommateur. Le producteur peut publier des messages dans le courtier de messages et le consommateur peut les récupérer lorsque la communication est rétablie. Le producteur n’est pas bloqué sauf s’il perd la connectivité avec le courtier de messages.
Messagerie résiliente
Un courtier de messages peut ajouter de la résilience aux consommateurs de votre système. Si un consommateur échoue lors du traitement d’un message, une autre instance du consommateur peut traiter ce message. Le retraitement est possible, car le message persiste dans le répartiteur.
Choix technologiques pour un courtier de messages
Azure fournit plusieurs services de courtier de messages, chacun avec un large éventail de fonctionnalités. Avant de choisir un service, déterminez l’intention et les exigences du message.
Messagerie Azure Service Bus
Les files d’attente de messagerie Azure Service Bus sont bien adaptées au transfert de commandes des producteurs aux consommateurs. Voici quelques éléments à prendre en compte.
Modèle de tirage (pull)
Un consommateur d’une file d’attente Service Bus interroge en permanence Service Bus pour vérifier si de nouveaux messages sont disponibles. Les kits de développement logiciel (SDK) client et le déclencheur Azure Functions pour Service Bus résument ce modèle. Lorsqu’un nouveau message est disponible, le rappel du consommateur est appelé, et le message est envoyé au consommateur.
remise garantie.
Service Bus permet à un consommateur de lire la file d’attente et de verrouiller un message à partir d’autres consommateurs.
Il incombe au consommateur de signaler l’état de traitement du message. Service Bus supprime le message de la file d’attente uniquement lorsque le consommateur a marqué le message comme étant consommé. Si une défaillance, un délai d’attente ou un incident se produit, Service Bus déverrouille le message afin que d’autres consommateurs puissent le récupérer. Ainsi, aucun message n’est perdu lors du transfert.
Un producteur peut envoyer par erreur le même message à deux reprises. Par exemple, une instance de producteur échoue après l’envoi d’un message. Un autre producteur remplace l’instance d’origine et renvoie le message. Les files d’attente Azure Service Bus offrent une fonctionnalité de déduplication intégrée qui détecte et supprime les messages en double. Il y a toujours un risque qu’un message soit remis deux fois. Par exemple, si un consommateur échoue pendant le traitement, le message est retourné à la file d’attente et récupéré par le même consommateur ou un autre consommateur. La logique de traitement des messages dans le consommateur doit être idempotent, de sorte que même si le travail est répété, l’état du système n’est pas modifié.
Classement des messages
Si vous souhaitez que les consommateurs récupèrent les messages dans leur ordre d’envoi, les files d’attente Service Bus garantissent la livraison chronologique des messages (FIFO, First-in-First-Out) à l’aide de sessions. Une session peut avoir un ou plusieurs messages. Les messages sont corrélés à la propriété SessionId. Les messages qui font partie d’une session, n’expirent jamais. Une session peut être verrouillée à un consommateur pour empêcher la gestion de ses messages par un autre consommateur.
Pour plus d’informations, consultez les sessions de messages.
Persistance des messages
Les files d’attente Service Bus prennent en charge le découplage temporel. Même lorsqu’un consommateur n’est pas disponible ou ne peut pas traiter le message, il reste dans la file d’attente.
Créer des points de contrôle pour les transactions de longue durée
Les transactions commerciales peuvent s’exécuter pendant une longue période. Chaque opération de la transaction peut avoir plusieurs messages. Utilisez les points de contrôle pour coordonner le flux de travail et fournir une résilience en cas d’échec d’une transaction.
Les files d’attente Service Bus permettent d’effectuer des points de contrôle via la fonctionnalité d’état de session. Les informations d’état sont enregistrées de manière incrémentielle dans la file d’attente (SetState) pour les messages appartenant à une session. Par exemple, un consommateur peut suivre les progrès en vérifiant l’état (GetState) de temps en temps. En cas de défaillance d’un consommateur, un autre utilisateur peut utiliser les informations d’état pour déterminer le dernier point de contrôle connu pour reprendre la session.
File d’attente de lettres mortes
Une file d’attente de Service Bus a une sous-file d’attente par défaut, appelée file d’attente de lettres mortes (lettres mortes) pour conserver les messages qui n’ont pas pu être remis ou traités. Service Bus ou la logique de traitement des messages dans le consommateur peut ajouter des messages à la fil d’attente de lettres mortes. La file d’attente de lettres mortes conserve les messages jusqu’à ce qu’ils soient récupérés dans la file d’attente.
Voici des exemples lorsqu’un message peut se retrouver dans la file d’attente de lettres mortes :
Un message incohérent est un message qui ne peut pas être géré car il est incorrect ou contient des informations inattendues. Dans les files d’attente Service Bus, vous pouvez détecter les messages incohérents en définissant la propriété MaxDeliveryCount de la file d’attente. Si le nombre de fois où le même message est reçu dépasse la valeur de cette propriété, Service Bus déplace le message vers la file d’attente de lettres mortes.
Il se peut qu’un message ne soit plus pertinent s’il n’est pas traité au cours d’une période donnée. Les files d’attente Service Bus permettent au producteur de publier des messages avec un attribut de durée de vie. Si cette période expire avant la réception du message, celui-ci est placé dans la file d’attente de lettres mortes.
Examinez les messages dans la file d’attente de lettres mortes pour déterminer la raison de l’échec.
Solution hybride
Service Bus fait le lien entre les systèmes locaux et les solutions cloud. Les systèmes locaux sont souvent difficiles à atteindre en raison des restrictions de pare-feu. Le producteur et le consommateur (locaux ou cloud) peuvent utiliser le point de terminaison de file d’attente Service Bus comme emplacement de collecte et de dépose pour les messages.
Le modèle Messaging Bridge est un autre moyen de gérer ces scénarios.
Rubriques et abonnements
Service Bus prend en charge le modèle éditeur-abonné via des rubriques et des abonnements Service Bus.
Cette fonctionnalité permet au producteur de diffuser des messages à plusieurs consommateurs. Quand une rubrique reçoit un message, celui-ci est transféré à tous les consommateurs abonnés. Éventuellement, un abonnement peut comporter des critères de filtre qui permettent au consommateur d’obtenir un sous-ensemble de messages. Chaque consommateur récupère les messages d’un abonnement de la même manière qu’une file d’attente.
Pour plus d’informations, consultez les rubriques Azure Service Bus.
Azure Event Grid
Nous recommandons Azure Event Grid pour les événements discrets. Event Grid suit le modèle éditeur-abonné. Quand les sources d’événements déclenchent des événements, ils sont publiés dans Rubriques Event Grid. Les consommateurs de ces événements créent des abonnements Event Grid en spécifiant les types d’événements et le gestionnaire d’événements qui traiteront les événements. S’il n’y a pas d’abonnés, les événements sont ignorés. Chaque événement peut avoir plusieurs abonnements.
Modèle Push
Event Grid propage les messages aux abonnés dans un modèle d’émission. Supposez que vous avez un abonnement Event Grid avec un webhook. Lorsqu’un nouvel événement arrive, Event Grid publie l’événement sur le point de terminaison webhook.
Intégration à Azure
Choisissez Event Grid si vous souhaitez obtenir des notifications sur les ressources Azure. De nombreux services Azure agissent comme des sources d’événements qui possèdent des rubriques Event Grid intégrées. Event Grid prend également en charge différents services Azure qui peuvent être configurés en tant que gestionnaires d’événements. Il est facile de s’abonner à ces rubriques pour acheminer les événements vers les gestionnaires d’événements de votre choix. Par exemple, vous pouvez utiliser Event Grid pour appeler une fonction Azure Function quand un stockage d’objets blob est créé ou supprimé.
Rubriques personnalisées
Créez des rubriques Event Grid personnalisées si vous souhaitez envoyer des événements à partir de votre application ou d’un service Azure qui n’est pas intégré à Event Grid.
Par exemple, pour afficher la progression d’une transaction commerciale entière, vous souhaitez que les services participants déclenchent des événements au fur et à mesure qu’ils traitent leurs opérations métier individuelles. Une application web affiche ces événements. L’une des manières d’accomplir cette tâche consiste à créer une rubrique personnalisée et à ajouter un abonnement avec votre application web inscrite via un webhook HTTP. À mesure que les services professionnels envoient des événements à la rubrique personnalisée, Event Grid les transmet à votre application web.
Événements filtrés
Vous pouvez spécifier des filtres dans un abonnement pour indiquer à Event Grid de router uniquement un sous-ensemble d’événements vers un gestionnaire d’événements spécifique. Vous spécifiez les filtres dans le schéma d’abonnement. Tout événement envoyé à la rubrique avec des valeurs qui correspondent au filtre est automatiquement transféré à cet abonnement.
Par exemple, le contenu dans différents formats est chargé dans le stockage d’objets blob. Chaque fois qu’un fichier est ajouté, un événement est déclenché et publié sur Event Grid. L’abonnement aux événements peut avoir un filtre qui envoie uniquement des événements pour les images afin qu’un gestionnaire d’événements puisse générer des miniatures.
Pour plus d’informations sur le filtrage, consultez Filtrer des événements pour Event Grid.
Débit élevé
Event Grid peut acheminer 10 millions d’événements par seconde par région. Les 100 000 premières opérations par mois sont gratuites. Pour plus d’informations sur les coûts, consultez Combien coûte Event Grid ?
Livraison résiliente
Même si la réussite des événements n’est pas aussi cruciale que les commandes, vous pouvez souhaiter une certaine garantie selon le type d’événement. Event Grid offre des fonctionnalités que vous pouvez activer et personnaliser, telles que les stratégies de nouvelle tentative, le délai d’expiration et les lettres mortes. Pour plus d’informations, consultez la page Distribution et nouvelle tentative de distribution de messages avec Event Grid.
Le processus de nouvelle tentative de Event Grid peut contribuer à la résilience, mais il n’est pas sécurisé. Dans le processus de nouvelle tentative, Event Grid pouvez remettre le message plusieurs fois, ignorer ou retarder certaines tentatives si le point de terminaison ne répond pas pendant un long moment. Pour plus d’informations, consultez Modèle Nouvelle tentative.
Vous pouvez conserver les événements non remis dans un compte de stockage d’objets blob en activant les lettres mortes. La livraison du message au point de terminaison de stockage de blob est retardée et, si ce point de terminaison ne répond pas, Event Grid ignore l’événement. Pour plus d’informations, consultez Définir un emplacement de lettres mortes et une stratégie de nouvelles tentatives.
Azure Event Hubs
Lorsque vous utilisez un flux d’événements, Azure Event Hubs est le courtier de messages recommandé. Il s’agit essentiellement d’un grand tampon capable de recevoir de gros volumes de données avec une faible latence. Les données reçues peuvent être lues rapidement par le biais d’opérations simultanées. Vous pouvez transformer les données reçues à l’aide de n’importe quel fournisseur d’analytique en temps réel. Event Hubs offre également la possibilité de stocker des événements dans un compte de stockage.
Ingestion rapide
Event Hubs peut ingérer des millions d’événements par seconde. Les événements sont ajoutés uniquement au flux et sont classés par heure.
Modèle de tirage (pull)
Comme Event Grid, Event Hubs offre également des fonctionnalités d’abonné de serveur de publication. La principale différence entre Event Grid et Event Hubs réside dans la façon dont les données d’événement sont mises à la disposition des abonnés. Event Grid transmet les données ingérées aux abonnés, tandis qu’Event Hubs les rend disponibles dans un modèle d’extraction. Au fur et à mesure que des événements sont reçus, Event Hubs les ajoute au flux. Un abonné gère son curseur et peut avancer ou reculer dans le flux, sélectionner un décalage temporel et relire une séquence à son rythme.
Les processeurs de flux sont des abonnés qui extraient des données depuis Event Hubs à des fins de transformation et d’analyse statistique. Utilisez Azure Stream Analytics et Apache Spark pour des traitements complexes tels que l’agrégation sur des fenêtres de temps ou la détection d’anomalies.
Si vous souhaitez agir sur chaque événement par partition, vous pouvez extraire les données en utilisant l’hôte de traitement des événements ou un connecteur intégré tel qu’Azure Logic Apps pour fournir la logique de transformation. Une autre option consiste à utiliser Azure Functions.
Partitionnement
Une partition est une partie du flux d’événements. Les événements sont divisés à l’aide d’une clé de partition. Par exemple, plusieurs appareils IoT envoient des données d’appareil à un Event Hub. La clé de partition est l’identificateur de l’appareil. À mesure que les événements sont ingérés, Event Hubs les déplace vers des partitions distinctes. Dans chaque partition, tous les événements sont classés par heure.
Un consommateur est une instance de code qui traite les données d’événement. Event Hubs suit un modèle de consommateur partitionné. Chaque consommateur lit uniquement une partition spécifique. Le fait d’avoir plusieurs partitions permet un traitement plus rapide car le flux peut être lu simultanément par plusieurs consommateurs.
Les instances du même consommateur composent un seul groupe de consommateurs. Plusieurs groupes de consommateurs peuvent lire le même flux avec différentes intentions. Supposons qu’un flux d’événements possède des données d’un capteur de température. Un groupe de consommateurs peut lire le flux pour détecter les anomalies telles qu’un pic de température. Un autre peut lire le même flux pour calculer une température moyenne mobile dans une fenêtre temporelle.
Event Hubs soutient le modèle éditeur-abonné en autorisant plusieurs groupes de consommateurs. Chaque groupe de consommateurs est un abonné.
Pour plus d’informations sur le partitionnement Event Hubs, consultez Partitions.
Event Hubs Capture
La fonctionnalité Capture vous permet de stocker le flux d’événements dans un stockage d’objets BLOB Azure ou Data Lake Storage. Cette méthode de stockage des événements est fiable, car, même si le compte de stockage n’est pas disponible, Capture conserve vos données pendant une certaine période, puis écrit dans le stockage une fois qu’elles sont disponibles.
Les services de stockage peuvent également offrir des fonctionnalités supplémentaires pour l’analyse des événements. Par exemple, en tirant parti des niveaux d’accès d’un compte de stockage d’objets blob, vous pouvez stocker les événements dans un niveau chaud pour les données qui ont besoin d’un accès fréquent. Vous pouvez utiliser ces données pour la visualisation. Vous pouvez également stocker les données dans le niveau Archive et le récupérer occasionnellement à des fins d’audit.
Capture stocke tous les événements ingérés par les Event Hubs et est utile pour le traitement par lots. Vous pouvez générer des rapports sur les données à l’aide d’une fonction MapReduce. Les données capturées peuvent également servir de source de vérité. Si certains faits n’ont pas été détectés lors de l’agrégation des données, vous pouvez faire référence aux données capturées.
Pour plus de détails sur cette fonctionnalité, consultez Capturer des événements avec Azure Event Hubs dans Stockage Blob Azure ou Azure Data Lake Storage.
Prise en charge des clients Apache Kafka
Event Hubs fournit un point d’accès pour les clients Apache Kafka. Les clients existants peuvent mettre à jour leur configuration pour pointer vers le point de terminaison et commencer à envoyer des événements à Event Hubs. Vous n’avez pas besoin d’apporter de modifications au code.
Pour plus d’informations, consultez Event Hubs pour Apache Kafka.
Scénarios de croisement
Dans certains cas, il est avantageux de combiner deux services de messagerie.
La combinaison de services peut accroître l’efficacité de votre système de messagerie. Par exemple, dans votre transaction commerciale, vous utilisez les files d’attente Azure Service Bus pour gérer les messages. Les files d’attente qui sont généralement inactives et qui reçoivent des messages sont parfois inefficaces, car le consommateur interroge en permanence la file d’attente à la recherche de nouveaux messages. Vous pouvez configurer un abonnement Event Grid avec une fonction Azure Function en tant que gestionnaire d’événements. Chaque fois que la file d’attente reçoit un message et qu’il n’y a pas de consommateurs qui écoutent, Event Grid envoie une notification, qui invoque la fonction Azure Function de drainage de la file d’attente.
Pour plus d’informations sur l’utilisation d’Azure Event Grid avec Service Bus, consultez la page Vue d’ensemble de l’intégration d’Azure Service Bus et Event Grid.
L’architecture de référence Intégration d’entreprise avec un courtier de messages et des événements montre une implémentation de l’intégration de Service Bus à Event Grid.
Voici un autre exemple : Event Grid reçoit un ensemble d’événements dans lesquels certains événements requièrent un workflow, tandis que d’autres sont utilisés pour la notification. Les métadonnées de message indiquent le type d’événement. L’une des méthodes pour les différencier consiste à vérifier les métadonnées à l’aide de la fonctionnalité de filtrage dans l’abonnement aux événements. S’il requiert un flux de travail, Event Grid l’envoie à la file d’attente Azure Service Bus. Les destinataires de cette file d’attente peuvent effectuer les actions nécessaires. Les événements de notification sont envoyés à Logic Apps pour envoyer des messages électroniques d’alerte.
Modèles associés
Tenez compte de ces modèles lors de l’implémentation de la messagerie asynchrone :
- Modèle des consommateurs concurrents. Plusieurs consommateurs peuvent être en concurrence pour lire les messages d’une file d’attente. Ce modèle explique comment traiter simultanément plusieurs messages de façon à optimiser le débit, à améliorer la scalabilité et la disponibilité et à équilibrer la charge de travail.
- Priority Queue pattern (Modèle de file d’attente de priorité). Pour les cas où la logique commerciale exige que certains messages soient traités avant d’autres, ce schéma décrit comment les messages publiés par un producteur avec une priorité plus élevée sont reçus et traités plus rapidement par un consommateur que les messages de moindre priorité.
- Queue-based Load Leveling pattern (Modèle de nivellement de charge basé sur une file d’attente). Ce modèle utilise un courtier en messages pour servir de tampon entre un producteur et un consommateur afin de minimiser l’impact sur la disponibilité et la réactivité des charges lourdes intermittentes pour ces deux entités.
- Modèle Nouvelle tentative. Un producteur ou un consommateur peut être incapable de se connecter à une file d’attente, mais les raisons de cet échec peuvent être temporaires et passer rapidement. Ce modèle décrit comment gérer cette situation pour ajouter la résilience à une application.
- Modèle de superviseur de l’agent du planificateur. La messagerie est souvent utilisée dans le cadre de la mise en œuvre d’un workflow. Ce schéma montre comment la messagerie peut coordonner un ensemble d’actions à travers un ensemble distribué de services et d’autres ressources distantes, et permettre à un système de récupérer et de réessayer des actions qui ont échoué.
- Modèle Choreography. Ce schéma montre comment les services peuvent utiliser la messagerie pour contrôler le déroulement d’une transaction commerciale.
- Modèle de réclamation-vérification. Ce modèle explique comment diviser un message volumineux en une vérification des revendications et une charge utile.
Ressources communautaires
Billet de blog de Jonathon Oliver : Idempotence
Billet de blog de Martin Fowler : What do you mean by « Event-Driven »?