Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Communication asynchrone

À l'inverse, dans une communication asynchrone, le client envoie une demande à un service mais ne reçoit pas de réponse immédiate. Dans ce cas, le client ne reçoit généralement qu'un accusé de réception indiquant que la demande a été acceptée.

Les avantages de la communication asynchrone incluent :

Les inconvénients incluent la complexité. Par exemple :

Les approches de communication asynchrone incluent le fire and forget, la vérification des réclamations, le rappel et la communication bidirectionnelle.

Tirez et oubliez

Dans le schéma « fire and forget », un client envoie une demande au serveur et reçoit de manière synchrone un accusé de réception indiquant que le serveur a reçu le message et qu'il va le traiter. Cependant, le traitement proprement dit n'a pas encore eu lieu et le client ne sait pas quand ni comment il sera effectué. Le schéma suivant illustre ce schéma.

Dans ce cas, le service ne doit pas envoyer d'accusé de réception tant que l'objet n'est pas conservé de manière durable. Cette persistance peut être implémentée sous la forme d'une opération d'écriture dans une base de données ou en plaçant un élément dans une file d'attente.

Considérations supplémentaires :

Vérification des réclamations

Si un client a besoin du résultat d'un appel de service, vous pouvez créer le service pour émettre un chèque de réclamation lorsqu'il reçoit une demande. Le schéma suivant illustre ce schéma. La vérification des réclamations est implémentée sous la forme d'un identifiant que le service renvoie dans son accusé de réception. Le client peut utiliser cet identifiant ultérieurement pour vérifier l'état de la demande et pour récupérer le résultat lorsque la demande est terminée.

Les clients doivent mettre en place un mécanisme de sondage pour obtenir les résultats. Cela peut être automatisé (par exemple, un contrôle peut être effectué toutes les n minutes) ou mis en œuvre manuellement, lorsque le contrôle est effectué en réponse à un autre événement ou à une autre action de l'utilisateur. Les services qui mettent en œuvre le modèle de vérification des réclamations doivent indiquer clairement la durée de validité d'une vérification des réclamations.

Bonnes pratiques :

Rappel

Dans le modèle de rappel, un client envoie une demande à un service et fournit un emplacement à contacter par le service une fois le traitement terminé. Le client n'attend pas de résultat et le traitement se poursuit. Le service est chargé de contacter le site une fois le traitement terminé et de fournir le résultat. Les types courants d'emplacements pour les réponses sont le REST APIs ou les files d'attente. Le schéma suivant illustre le modèle de rappel.

Mise en œuvre :

Communication bidirectionnelle

Pour implémenter la communication bidirectionnelle, vous devez créer une connexion dynamique entre un client et un service, qui permet à la fois au client et au service d'envoyer et de traiter des messages. Le diagramme suivant en est l’illustration. Bien que la communication soit asynchrone, le service doit être capable de prendre en charge une connexion ouverte pour chaque client.

Considérations relatives à l'implémentation :