Pattern Request/Reply : ESB pour les nuls

Le problème

Ca me trottait dans la tête depuis un bout de temps : je n’ai jamais été à l’aise avec le pattern Request / Reply, car j’ai l’impression que ça allait à l’encontre de la notion d’asynchronisme. Dans un bus de message asynchrone, j’envoie le message et le middleware me donne la garantie qu’il sera testé, et je n’ai pas besoin d’attendre le retour du serveur qui l’aura utilisé.

Maintenant, que fait-on quand on met en place un pattern Request / Reply ? On ajoute un écouteur en retour, et on demande au serveur de nous envoyer un message asynchrone avec les résultats du traitement précédent. Je me demandais bien si ça ne suffisait pas à supprimer les avantages de l’asynchronisme. En effet, on se retrouve tout de même à attendre quelque chose.

La solution

En fait, le problème venait du fait que je raisonnais uniquement autour de ce message. Or, ce qui compte finalement n’est pas vraiment le tuyau ni le middleware. Ce qui compte est ce que le client fait pendant ce temps-là. Si effectivement on entre dans une boucle d’attente, on a effectivement transformé un comportement asynchrone en synchrone, ce qui annule tout le bénéfice. L’important est de bien se baser sur une attente d’un évènement de retour, et de traiter le message de réponse dans un autre thread. Après, du point de vue du client, ça peut prendre la forme d’un message “Toast” ou de n’importe quoi…

L’explication “pour les nuls”

Ce qui m’a vraiment fait faire tilt est quand je me suis mis à comparer le travail d’un SI basé sur un bus ESB véhiculant des documents avec un bon vieux bureau à l’ancienne où les gens s’échangeait des dossiers. Lorsque vous posiez un dossier sur le bureau de quelqu’un et que vous aviez besoin qu’il remplace une fiche avant de vous le repasser, vous étiez effectivement en mode asynchrone. En effet, lorsque vous retourniez à votre bureau, vous accomplissiez d’autres tâches, et vous n’attendiez pas en vous tournant les pouces que la personne vous ramène le dossier.

Le résumé

Le dossier = Le message sur le bus.

Vous et la personne = le client et le serveur.

La requête = le fait que vous demandiez un avis sur le dossier.

La réponse = le dossier qui revient avec un avis.

L’asynchronisme = si vous bossez pendant ce temps là.

Le traitement synchrone = si, après avoir posé le dossier sur le bureau de la personne, vous attendez bêtement devant en ne faisant rien qu’il se décide à y jeter un oeil.

La conclusion

Je crois qu’il n’y a pas besoin de sortir de Saint Cyr pour voir que la productivité sera meilleure dans l’avant dernier cas que dans le dernier.

About JP Gouigoux

Jean-Philippe Gouigoux est Architecte Logiciel, MVP Connected Systems Developer. Il intervient régulièrement à l'Université de Bretagne Sud ainsi qu'à l'Agile Tour. Plus de détails sur la page "Curriculum Vitae" de ce blog.
This entry was posted in Veille and tagged . Bookmark the permalink.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha Captcha Reload