2011-03-27 1 views

Répondre

3

Voici quelques-unes de mes observations:

IIS 7:

Plus:

  • Prêt en environnement d'hébergement dans IIS
  • travaillera de concert avec à peu près tout environnement d'hébergement

Moins:

  • HTTP uniquement
  • configuration un peu plus complexe

WAS:

Plus:

  • prêt à l'emploi et le modèle de processus familier à celui de IIS
  • Aucune dépendance sur IIS
  • Tous les protocoles pris en charge

Moins:

  • ne sont pas tous les environnements d'hébergement partagés soutiendront les liaisons de protocole non HTTP ou les numéros de port inhabituels.
  • configuration un peu plus complexe

Windows Service:

Plus:

  • au démarrage de Windows
  • Vous pouvez démarrer/arrêter le service via le gestionnaire de contrôle de service
  • Tous les protocoles pris en charge

Moins:

  • Quelques mesures supplémentaires pour déployer/redéployer (InstallUtil)
  • Vous avez besoin du code boilerplate supplémentaire pour soutenir la mise en œuvre de services
  • Pas idéal si vous ne pouvez pas avoir accès au serveur à installer (par exemple hébergement mutualisé)

Application console:

Avantages:

  • rapides et simples à déployer des fins de test
  • Tous les protocoles pris en charge

Moins:

  • Vous devez être connecté pour démarrer le processus
  • Perte d'arrêt de la session ou à la machine va tuer le service
  • accès à la console/RDP nécessaire
+0

Merci Kev. Je vais héberger ce service dans Win2008 VPS, donc l'accès sage j'ai le contrôle complet. Aussi, je voulais savoir si l'endroit où j'héberge (IIS7/WAS/ConsoleApp/WinService) affecte la performance du service ou pas. – saarthak

+0

@Saarthak - Avec IIS et WAS, il y aura peut-être un léger surcoût lorsque le processus sera créé en fonction de la façon dont vous réglez votre politique de délai d'inactivité et de recyclage. Mais ce sont de petites pommes de terre. – Kev

Questions connexes