Windows Service ou toute autre alternative

Question

Je suis dans le dilema si utiliser le service de Windows pour mon application ou pas, ci-dessous est la description de mon application s'il vous plaît pourrait suggérer quelle est la meilleure approche pour mon exigence, si possible avec pros et contre aussi.

L'application "A" est une application fermée et toutes les données dont j'ai besoin de cette application sont exposées uniquement via les services WCF. Mon application "M" doit appeler l'un des services WCF exposés par "A", puis obtenir les données et le traiter et jeter un fichier. De même, si un fichier est injecté dans mon application "M", je dois le traiter et transférer cette information dans l'application "A" en utilisant son service WCF. C'est l'exigence en bref.

problèmes-

1) Voici ma demande "M" a besoin à l'application sondage continously "A" service WCF pour vérifier si quelque chose est availabel pour elle de traiter. Je n'aime pas interroger, mais d'autres alternatives, s'il vous plaît suggérer. Je pensais à MSMQ, cette application "A" envoie un message à mon application "M" chaque fois qu'une nouvelle donnée entre. Mon application "M" traite ensuite celle de la file d'attente. Vous ne savez pas comment le faire. S'il vous plaît aviser si c'est la bonne approche.

2) Une autre chose est si un nouveau fichier vient sur un dossier de serveur alors mon application "M" doit le ramasser et le traiter et l'envoyer à l'application "A". Donc, pour y parvenir, il se peut que je doive avoir un observateur de système de fichiers et dès que quelque chose devient disponible, il doit lancer mon application. Encore une fois frappé à quelle technologie (uniquement dans .Net) à utiliser. MSMQ est-il la meilleure approche?

Je suis maintenant frappé de savoir quelle technologie (seulement en .Net) je dois utiliser pour remplir efficacement mes besoins. Est-ce que Windows Service approche le mieux en interrogeant constamment l'application "A" et en implémentant MSMQ avec elle. S'il vous plaît donnez votre avis.

Merci à l'avance
Sai

Answer 1

Pour la condition 1, je voudrais utiliser un service WCF hébergé par le service d'activation des processus Windows (WAS) - voir le MSDN reference. Cela nécessite WAS (Windows Vista/7 ou Windows Server 2008/2008R2), cependant, si ceux-ci ne sont pas disponibles, un service NT normal serait le remplacement approprié.

Pour l'exigence 2, vous pouvez implémenter un service NT qui utilise la classe FileSystemWatcher (MSDN reference).

Ainsi, vous pourriez mettre en œuvre un seul service NT avec le FileSystemWatcher et un fil de vote, ou vous pouvez mettre en œuvre à la fois un service NT avec le FileSystemWatcher et un service de WCF WAS-hébergé séparé qui écoute via MSMQ.

Ce dernier est peut-être un peu plus propre puisqu'il suit le principe de la séparation des préoccupations. Mais ce n'est possible que si l'application "A" peut être configurée pour envoyer des messages via MSMQ (c'est-à-dire que votre service "M" deviendrait le "serveur" et l'application "A" agirait comme client). Donc, la première option (un seul service NT pour faire les deux) peut mieux convenir à votre scénario, mais je ne suis pas complètement sûr de votre description de "A".

En ce qui concerne l'envoi de messages à l'application "A", MSMQ peut ou peut ne pas être le choix approprié. Les deux applications sont-elles sur la même machine? Ensuite, utilisez des tuyaux nommés. Sont-ils sur des machines différentes? Utilisez ensuite une liaison TCP si l'application "A" est toujours en cours d'exécution (service actif), mais utilisez une liaison MSMQ si vous avez besoin d'une livraison garantie de vos messages et que l'application "A" peut être hors connexion occasionnellement. il messages.(Notez également que l'utilisation de MSMQ requiert l'installation du composant Windows MSMQ sur la machine réceptrice.)

Answer 2

Il semble que l'option A soit immuable et que vous ne puissiez pas la modifier. ("Closed")

L'application M doit être un service Windows, comme décrit par Lars. Mais, n'utilisez jamais l'observateur de système de fichiers à moins que vous aimiez déchirer le code plus tard et le remplacer par un mécanisme d'interrogation. Votre meilleur pari est de commencer un fil pour interroger l'application A, et un autre pour interroger le système de fichiers.

Il n'y a rien de mal à interroger. Utilisez un Thread.Sleep (10), et tout ira bien. FileSystemWatcher vous donnera souvent un fichier qui a été 'changé', mais cela n'a pas fini d'écrire. Cela entraîne l'obtention d'un fichier tronqué.

Ne vous embêtez pas avec MSMQ, sauf si vous en avez absolument besoin. C'est juste une autre pièce à maintenir, et ne peut pas gérer les opérations de récupération complexes.