Souscrire une application web à un événement dans NServiceBus

Question

Je voudrais savoir comment mon application web peut s'abonner à un événement provenant d'un serveur ? Je sais qu'une application web ne doit pas publier d'événement. Dans l'exemple asynchrone, c'est l'application web qui envoie le message au serveur. Je veux que l'application s'abonne au serveur. En d'autres termes, comment gérer un événement provenant d'une application web. Je ne sais pas comment écrire la page Global.asax : public class Global : System.Web.HttpApplication et la méthode void Application_Start(object sender, EventArgs e). Merci d'avance, Loïc

Answer 1

Je ne suis pas d'accord avec Hugh. Il y a des raisons très valables pour qu'une application web s'abonne à un événement publié par un autre service.

En général, ce n'est pas le genre de chose pour laquelle vous voulez prendre des mesures dans la base de données. Un excellent exemple de cas d'utilisation serait la gestion du cache. En reprenant l'exemple de UserCreated dans les commentaires, l'application web pourrait répondre à UserCreated en supprimant son objet User du cache. Cela permet à plusieurs applications Web faisant partie d'une ferme Web de rester synchronisées les unes avec les autres.

Une utilisation plus aventureuse d'une application web s'abonnant à un événement (encore une fois UserCreated comme exemple) serait de créer un service de connexion ultra-scalable qui ne doit jamais interroger la base de données pour authentifier l'utilisateur. Au démarrage, l'application web chargerait tous les noms d'utilisateur et les hachages de mots de passe dans un dictionnaire en mémoire, puis s'abonnerait à un événement UserCreated en complétant ce dictionnaire. Il est probable qu'elle s'abonne également à un événement UserPasswordChanged, afin de mettre à jour ce dictionnaire.

(Il est important dans ce scénario de ne pas penser à mettre en cache un objet utilisateur entier - ce service ne serait concerné que par l'authentification, pas par l'autorisation, et donc seuls les noms d'utilisateurs et les hachages de mots de passe seraient stockés).

Pour ce faire, vous devez configurer vous-même le bus dans le fichier Global.asax, comme décrit dans le document suivant Héberger NServiceBus dans votre propre processus . Le site .LoadMessageHandlers() est essentielle pour que NServiceBus analyse les assemblages de votre site Web à la recherche de gestionnaires de messages.

Il s'agit d'un bloc de configuration fluide typique pour une application web :

public static IBus Bus { get; set; }

// In Application_Start()
Bus = NServiceBus.Configure.WithWeb()
        .Log4Net()
        .DefaultBuilder()
        .XmlSerializer()
        .MsmqTransport()
            .IsTransactional(false)
            .PurgeOnStartup(true)
        .UnicastBus()
            .ImpersonateSender(false)
            .LoadMessageHandlers() // <-- only if handling commands/events
        .CreateBus()
        .Start();

Étant donné que les applications web sont intrinsèquement instables (elles se recyclent et perdent leur état assez souvent), il est courant d'utiliser la balise .PurgeOnStartup(true) ligne après .MsmqTransport() afin de vider les messages en attente de l'application web dans la file d'attente pendant le démarrage. En effet, les messages adressés à une application web sont généralement des instructions visant à modifier un état, mais une application web qui vient de démarrer n'a pas d'état ! Pourquoi traiter un tas de commandes pour "déposer l'élément X du cache" alors que nous savons pertinemment que notre cache est vide ?

Pour résumer, vous pouvez (et dans certains cas, vous devez) faire en sorte que votre application Web s'abonne à des événements provenant d'autres services, en fonction de votre logique commerciale, mais vous devez faire attention à la manière dont vous le faites.

Answer 2

OK, je pense que je comprends ce que vous dites.

En gros, votre application web, qui, je suppose, est hébergée dans IIS, consulte une base de données et affiche ensuite les résultats à un utilisateur.

Vous voulez qu'un événement commercial déclenché par un autre service soit envoyé sous forme de message et soit reçu dans la base de données, ce qui permet à votre utilisateur de rafraîchir la page et de voir les nouvelles données.

Ce que vous voulez faire est très raisonnable, mais vous devez arrêter de penser que votre application web s'abonne à quelque chose.

Ce dont vous avez besoin, c'est d'un autre service qui reçoit les messages envoyés par un service expéditeur. Lorsque le service reçoit un message, il l'écrit dans la base de données.

Votre application Web peut ensuite récupérer les données dans la base de données et les afficher pour un utilisateur.

Les deux processus sont totalement indépendants. Votre application web est hébergée dans IIS. Votre service récepteur peut être hébergé dans son propre processus. Ceci découple votre application web du service récepteur.

Vous pouvez utiliser NServiceBus pour activer ce scénario.

Votre service émetteur devient un émetteur de messages NServiceBus, et votre service récepteur devient un récepteur de messages NServiceBus. La façon la plus simple de faire ceci est d'héberger votre émetteur et votre récepteur en utilisant l'hôte générique NServiceBus et de les déployer en tant que services Windows.