Je dois concevoir et mettre en œuvre un moyen de gérer les processus de course à long terme dans une application client / serveur. Un processus de course de longue date typique / pourrait prendre 2-3 minutes. J'ai également besoin de signaler des progrès de l'interface utilisateur dans l'intervalle et de garder l'interface utilisateur réactive.
Les avoir dans mon esprit, je pense que quelques solutions:
Une demande ASYNC de démarrer le processus qui démarre le processus côté serveur et renvoie un LRPID assigné (ID de processus de course longue) puis sondage périodiquement à partir du client en utilisant ce lrpid. ( pro : simple à déployer, aucun pare-feu ne résume pas con : non observant, ressources consommant, etc.)
Utilisez une liaison en duplex (telle que NetCPBinding) et initiez des rappels du serveur à mesure que les progrès sont en cours de progression ( pro : élégant, efficace, [Votre suggestion ???]
quelle serait votre prise sur cela?
3 Réponses :
Voici un POST par DAN WAHLIN sur la manière de créer un indicateur de progression de la WCF pour une application Silverlight. Cela devrait être de l'aide.
semble assez cool, je vais devoir regarder un peu plus dedans. Merci!
Ok, cela s'est avéré être le meilleur moyen du milieu! Surtout parce que "... Il initie une demande de réseau, puis la demande est effectivement" mise en veille "en attente du serveur de réagir (il ne revient pas immédiatement). Le serveur maintient ensuite la connexion ouverte mais pas actif jusqu'à ce qu'il ait quelque chose à renvoyer (ou les temps de connexion après 90 secondes - à quel point le client Duplex se connecte à nouveau et attendez). De cette façon, vous évitez de frapper le serveur à plusieurs reprises - mais obtenez toujours une réponse immédiate quand il y a est des données à envoyer. "
ou en d'autres termes, un système de vote clair et efficace et efficace qui simule une version true-bidirectionnelle
Si vous ne voulez pas avoir à vous soucier du pare-feu du client, etc. Je vais probablement aller avec votre première solution et utiliser un Backworker Pour faire appel à l'appel afin de ne pas bloquer le fil de l'interface utilisateur. Je l'ai récemment fait pour une application dans laquelle une demande de génération d'un rapport est placée sur une file d'attente et est récupérée une fois que cela est terminé. Il semble bien fonctionner.
Une autre solution (sans avoir à modifier la liaison WCF) consiste à utiliser un contrôle WebBrowser dans le client WPF et signalez-vous pour publier des messages de progression du serveur à ce contrôle.
Notez que pour éviter les erreurs JavaScript qui se produisent avec le contrôle WebBrowser (car par défaut, il semble utiliser Internet Explorer version 7 qui ne semble pas être compatible avec jquery.js), vous devrez ajouter des clés au registre. Sur la machine cliente Pour modifier la valeur par défaut de l'application cliente pour utiliser IE10 ou ultérieure - voir http://weblog.west-wind.com/ports/2011/may/21/web-Browser-Control-specifiant-L'Inversion ).
Cela pourrait être une nuisance de déploiement (car les droits de l'administrateur semblent être nécessaires - par exemple sur un PC Windows 8.1 64 bits - pour ajouter les clés de registre).
En outre, il semble toujours nécessaire d'appeler la méthode WCF à long terme dans un thread séparé, sinon le contrôle WebBrowser ne semble pas mettre à jour son écran pour afficher les messages SignalR qu'il reçoit. (Cela a du sens parce que le fil de l'interface utilisateur devait autrement attendre que l'appel de la WCF avait fini).
Mais je le mentionne comme une approche alternative utilisant un outil plus récent (SignalR) :)
Quelle est l'application côté client écrite?
Nightmare de déploiement? Pourquoi, à cause de IIS / était? Alors ne les utilisez pas.
@Daniel Auger: L'application client est écrite dans WPF
@Allon Guralnek: en raison de ports d'ouverture du pare-feu, hébergeant le "Minisserver" sur le client prêt pour les rappels, etc.
Vous devriez le faire avec n'importe quel service WCF.