Meilleur hôte sous Windows pour les processus sans interface utilisateur

Question

Nous planifions un système fonctionnant sous Windows/.Net 3.5 qui a un certain nombre de "services" devant s'exécuter en arrière-plan. Certains seront actifs tout le temps, mais certains ne seront appelés que de temps en temps et peuvent être mis sur pied à la demande.

Pour autant que je peux voir, mes options sont les suivantes: - (?)

• Services Windows toujours en cours d'exécution
• IIS hébergé quelque chose - appelé à la demande
• COM +/.Net Enterprise Sevices - plus option complexe, mais le plus puissant?

Les transactions distribuées ne sont pas une exigence, ce sont principalement des moteurs de calcul, plutôt que des processeurs de transaction.

Est-ce que quelqu'un a déjà travaillé avec toutes ces technologies et quels autres avantages peuvent être revendiqués pour chaque technologie?

EDIT

est supposé il y a plusieurs façons de code d'hébergement dans IIS, les services Web, WCF (comme indiqué ci-dessous), tous les autres? Avantages/inconvénients relatifs?

Answer 1

La WCF semble être la bonne solution. Il y a encore beaucoup de choix à faire. WCF fournit un certain nombre de mécanismes de communication et d'environnements d'hébergement: WCF combine les technologies suivantes dans un ensemble d'API: ASMX; WSE; À distance; COM +; MSMQ. Par exemple, vous pouvez utiliser des messages persistants de MSMQ pour des clients occasionnellement connectés ou des messages SOAP d'encodage XML standard sur une couche de transport HTTP. Vous pouvez également utiliser de nouvelles fonctionnalités dans 3.5 comme le codage binaire de codage XML ou JSON sur HTTP.

environnements d'hébergement comprennent: applications console de services Windows services WCF à l'intérieur IIS 7.0 et sous Windows Vista ou Windows Server 2008, vous pouvez utiliser WAS (Windows Activation Services) pour héberger des services WCF.

Différents environnements d'hébergement ont des avantages et des inconvénients. Je vous suggère de regarder MSDN pour plus de détails (par exemple http://msdn.microsoft.com/en-us/library/bb332338.aspx).

Parce que WCF englobe beaucoup de fonctionnalités, il est plus difficile à apprendre que l'une des technologies qu'il remplace. Je pense toujours que c'est rentable à long terme.

Answer 2

Cela dépend de ce que le logiciel va faire, et comment (et si) les utilisateurs ou les systèmes ont besoin d'interagir avec lui. En fonction de ces éléments, il peut y avoir une autre option, souvent négligée: la configurer en tant que tâche planifiée. C'est souvent une très bonne alternative à un service Windows, si le logiciel est du type qui agira sur certains intervalles de temps (vérifier un changement dans une base de données, agir sur les données modifiées et les envoyer quelque part, par exemple).

Si vous voulez que d'autres systèmes parlent directement à votre logiciel, j'imagine qu'une application WCF hébergée dans IIS serait un moyen assez simple. Nous utilisons ces deux approches dans ma mission actuelle; Les services WCF pour rechercher et stocker des données, et les tâches planifiées pour les calculs de données qui se déroulent sur une base régulière.

La tâche planifiée a un avantage par rapport aux autres dans un domaine spécifique; il utilise les ressources du système uniquement lorsqu'il est en cours d'exécution.

Answer 3

Vous avez mentionné le démarrage d'un processus "à la demande". WAS - Windows Activation Service, ou parfois appelé Windows Process Activation Servvice, bien qu'il ne soit jamais abrégé "WPAS" - est la chose dans Windows qui fournit l'activation de processus à la demande. La façon dont cela fonctionne - lorsqu'un message arrive, WAS peut démarrer un processus de travail pour gérer le message. WAS était, avant IIS7, assez étroitement intégré à IIS. Il était principalement utilisé pour activer les processus qui travaillaient sur le Web, comme un processus de travail ASP.NET. Avec IIS7, WAS est généralisé afin de pouvoir activer les processus de travail basés sur des messages non HTTP ainsi que des messages HTTP. Si vous écrivez votre application pour recevoir des messages via WCF, vous pouvez obtenir l'activation essentiellement "gratuitement". Cela s'applique si c'est HTTP, TCP, MSMQ; SOAP ou autre. Cependant, le point clé de ce démarrage à la demande est qu'il est lié à la communication. En fait, le modèle de cycle de vie des processus pour WAS est également lié à la communication. Par défaut, s'il n'y a aucun message entrant après un moment, le processus sera arrêté par WAS. Cela peut ou peut ne pas être ce que vous voulez. Comme pour l'hébergement de processus - COM + offre un environnement d'hébergement mais il est principalement destiné à être utilisé comme hôte pour les processus qui communiquent. Ce n'est peut-être pas le choix parfait pour vous.

Si vous avez des moteurs de calcul, vous pouvez simplement exécuter un service Windows. Un service de ce type peut être démarré et arrêté de manière administrative ou programmée. Dans ce dernier cas, vous pouvez imaginer un processus de travail activé par WAS démarrant par programme un service Windows. Vous pouvez également imaginer écrire un simple service Windows qui surveille un emplacement (système de fichiers, file d'attente de messages, etc.) pour un message, et lorsque ce fichier ou message arrive, le service Windows démarre un processus de calcul, qui est lui-même PAS un service Windows, mais est juste un processus.

En parlant de MSMQ - C'est fondamentalement le même modèle que les déclencheurs MSMQ. Vous pouvez configurer MSMQ pour démarrer un processus lorsqu'un message arrive dans une file d'attente particulière.

Il y a beaucoup d'options.