Hébergement WAS vs Hébergement Windows Service

Question

Je travaille sur un projet utilisant Windows 2008, .NET 3.5 et WCF pour certains services internes et la question de savoir comment héberger ces services s'est posée.

Depuis que nous utilisons Windows 2008, je pensais qu'il serait bon de tirer parti du service d'activation de processus Windows (WAS) bien que l'impression du projet semble être que l'utilisation des services Windows serait préférable.

Quel est donc le faible intérêt de l'utilisation de WAS pour héberger des services WCF par rapport à un service Windows? Existe-t-il de réels avantages à utiliser Windows Services ou bien WAS est-il la solution?

Answer 1

Récemment, j'ai dû répondre à une question très similaire. C’est la raison pour laquelle j’ai décidé d’utiliser IIS 7.0 et WAS au lieu de l’infrastructure Windows Service.

1. IIS 7.0 est un hôte beaucoup plus robuste, doté de nombreuses fonctionnalités facilitant le débogage. Suivi des demandes ayant échoué, recyclage du processus de travail, orphelin du processus, pour en nommer quelques-uns.
2. IIS 7.0 vous donne davantage d’option pour spécifier ce qui doit se passer avec le processus de travail dans certaines circonstances.
3. Si vous hébergez votre service sous IIS, aucun processus de travail ne lui est attribué jusqu'à la toute première demande. C'est quelque chose qui était un comportement souhaité de mon point de vue, mais il pourrait être différent dans votre cas. Le service Windows vous donne la possibilité de démarrer votre service de manière plus déterministe.
4. D'après mon expérience, WAS ne fournit pas une fiabilité accrue. Son plus gros avantage est qu’elle expose la richesse d’IIS à des applications utilisant des protocoles différents de HTTP. Par différent, je veux dire: TCP, canaux nommés et MSMQ.
5. À ma connaissance, le seul inconvénient de l'utilisation de WAS est que l'adresse à laquelle votre service est exposé doit être conforme à une sorte de modèle. A quoi ça ressemble dans le cas de MSMQ est décrit ici