soumission et surveillance d'un service Web peu fiable

Question

Je construis un site Web ASP.NET qui collectera les données d’un utilisateur et les soumettra à un service Web tiers. Le service Web est quelque peu peu fiable et c'est pour cette raison qu'il existe un service de sauvegarde.

Si un appel du service principal échoue (délai d'attente dépassé ou une autre erreur), je dois retourner un bit dans une classe statique, ce qui incitera le système à utiliser le service secondaire.

À ce stade, je dois commencer à interroger le service principal (avec des données factices) pour voir s’il est sauvegardé (à quel moment je recevrai un code OK en retour). À ce stade, je dois revenir en arrière pour que le site Web utilise à nouveau le service principal.

J'ai lu ceci Devrais-je utiliser un service Windows ou un thread d'arrière-plan ASP.NET? et je pense que séparer le code en un service Windows serait la méthode la plus propre pour effectuer l'interrogation, mais comment puis-je communiquer avec l'application Web.

Une des idées que j'ai eues est d'exposer un service Web que le service Windows pourrait utiliser pour communiquer avec l'application Web, mais cela semble à la fois désordonné et fatal.

J'apprécierais vos pensées et expériences dans l'exécution de tâches similaires.

Merci

Answer 1

Je pense que le service Windows est vraiment la voie à suivre.

En ce qui concerne la communication entre le service et votre site Web, la meilleure réponse dépend de la taille et de l’ampleur de votre solution. Si vous construisez quelque chose qui doit être fiable, je vous suggère d'implémenter une sorte de file d'attente entre votre site ASP.NET et votre service Windows. Vous disposez également de nombreuses options, en fonction du budget et des capacités: files d'attente BizTalk, MSMQ et SQL Server (SSIS). Sinon, si vous recherchez quelque chose de plus petit, je vous recommande de le coller quelque part dans une table de base de données.

J'éviterais d'utiliser des fichiers sur le système de fichiers car vous rencontrerez des problèmes de verrouillage de fichiers et de multithreading. J'éviterais également toute communication directe avec le service car vous risqueriez de perdre la file d'attente en mémoire si le service échouait pour une raison quelconque.

Modifié pour ajouter:

Si la fiabilité ne constitue pas un problème ici, vous pouvez utiliser un service hébergé nommé WPF par tubes nommés pour la communication entre votre site Web et votre service Windows. Cela évite une grande partie des frais généraux normalement impliqués dans les services Web classiques et est étonnamment rapide. Le seul inconvénient est qu’auto-héberger un service WPF est délicat et qu’il peut être difficile de maintenir le service.