Hébergement de service IIS WCF vs service Windows

Question

Nous avons développé un service WCF et nous sommes à la recherche pour le déployer. Nos clients seront en l'utilisant avec des basicHttpBinding , mais notre équipe interne sera de l'utiliser avec namedPipesBinding.

Nous nous demandons si il est mieux pour l'accueillir dans IIS 7 ou avec un Service Windows. Nous avons couru quelques tests et nous avons constaté que lorsque nous ajoutons des liaisons dans IIS, il n'a pas de mise à jour du fichier de config de notre service. Cela signifie que nous avons besoin pour maintenir la configuration à deux endroits différents. Il n'est pas logique, non?

Nous avons également lire sur StackOverflow que l'adresse de base est ignoré lorsqu'un service WCF est l'hôte dans IIS (voir service WCF fichier de configuration question concernant <baseAddresses>)

Answer 1

Hébergement dans IIS a de nombreux avantages et beaucoup d'inconvénients.

Oui, IIS vous donne sur-le chargement de la demande - ce qui peut être un plus ou un moins. Lorsqu'une demande arrive, le ServiceHost est construit, puis la classe de service hébergé est instancié, et la demande est traitée. Rien ne doit être en cours d'exécution autour de l'horloge. Mais dans le même temps, cette configuration nécessite plus de temps et d'effort à chaque fois qu'un message arrive, et vous en tant que programmeur n'avez pas beaucoup de contrôle sur votre hôte de service, vraiment.

Et oui, avec IIS, le répertoire virtuel où l' *.svc fichier réside définit votre adresse - toutes les adresses de base ou explicitement défini les adresses dans votre config sont pas pris en compte. Et sans beaucoup d'effort, vous ne pouvez pas modifier la configuration de l'adresse de service - ils sont toujours va être http://servername/virtualdirectory/YourService.svc (y compris l' .svc extension).

L'auto-hébergement est souvent fois plus rapidement, depuis votre ServiceHost est d'ores et déjà en cours d'exécution - mais c'est à vous de assurez-vous qu'il est vraiment en place et en cours d'exécution, il n'y a pas de "demande" de chargement à chaque fois qu'un message est en soit c'est et peut répondre à la requête, ou pas. Mais vous avez beaucoup plus de contrôle sur le service d'accueil - quand et comment il est construit, etc., et vous obtenez de choisir et de définir votre service des adresses que vous voyez l'ajustement.

Personnellement, je serait presque toujours choisir d'utiliser l'auto-hébergement, - dans une application console pour tester, dans un service NT pour la production. Pour moi, il me semble que la manière la plus appropriée de le faire, et le manière plus contrôlée, trop. Que vous avez à faire plus de travail, mais, vous savez exactement ce que vous faites.

Marc

Answer 2

marc_s donne généralement de grandes réponses que je suis d'accord avec tout, mais dans ce cas je n'en ai pas.
L'auto-hébergement de FMC n'est pas une bonne idée, surtout avec le Dublin technologies de l'être publié prochainement par Microsoft. La gestion et l'exploitation de la WCF (et WF) des applications est beaucoup plus simple lorsqu'il est hébergé à l'intérieur de IIS.

En outre, vous obtenez le chargement à la demande.

Il y a une option pour IIS7.5 (WS2008 R2).

Et vous pouvez facilement faire de la réécriture d'URL pour omettre l' .svc si cela vous ennuie.

Answer 3

Information intéressante-> après la lecture de ce fil, je suis tombé sur ces mots dans la MSDN sur l'hébergement d'un service WCF à l'aide d'un Service Windows:

Les éléments suivants sont quelques-uns des inconvénients de services Windows:

•Déploiement: les Services doivent être installés avec le .NET Framework Installutil.exe utilitaire ou par le biais d'une action personnalisée dans un package d'installation.
•Des fonctionnalités limitées: Windows, les services ont toujours un ensemble limité de dehors-de-le-boîte de fonctionnalités pour le support de la haute disponibilité, la simplicité d'administration, de gestion des versions et des scénarios de déploiement. Vous aurez essentiellement à la couverture de ces besoins vous-même grâce à un code personnalisé, tandis que, par exemple, IIS est livré avec plusieurs de ces caractéristiques par défaut. Services Windows ne ajouter de la récupération et de certains éléments de sécurité, mais vous avez encore du travail à faire vous-même.
http://msdn.microsoft.com/en-us/library/bb332338.aspx

...et le lien suivant:

Services d'hébergement: nice (tableau comparatif)
http://msdn.microsoft.com/en-us/library/ms730158.aspx

Answer 4

Pour répondre à ces question :

Nous avons couru quelques tests et nous avons trouvé que lorsque nous ajoutons des liaisons dans IIS, il n'a pas de mise à jour de fichier de configuration notre service. Cela signifie que nous nécessité de maintenir la configuration dans deux endroits différents. Il n'est pas logique, droit ?

Lorsque vous utilisez IIS pour héberger votre service, vous devez configurer votre Application.fichier de config ou web.fichier de configuration permettant d'IIS pour exposer certaines de liaison, de sorte que dans votre fichier de configuration, vous mettez tous vos contraignantes vous permettez à votre service wcf. Http, net.tcp etc...

Dans votre affectation vous sera pas spécifié d'adresse, parce que vous aurez spécifié ceux adresse dans IIS directement.

Dans IIS, vous devez autoriser la liaison disponibles dans les paramètres avancés de votre site web. Après que vous avez mis de liaison pour votre site web "web service" et ajoutez tous les liens que vous souhaitez écouter, et préciser l'adresse.

Vous devrez indiquer l'adresse directement dans IIS.

Il y a un exemple.

Votre fichier de configuration:

<services>
    <service name="ServiceName">                    
        <endpoint address=""
            binding="basicHttpBinding"
            bindingConfiguration="httpMode"
            contract="IContract" />                 
        <endpoint address=""
            binding="netTcpBinding"
            contract="IContract" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

Dans votre IIS advenced réglage de votre volonté de mettre

http,net.tcp en charge les Protocoles

Après cela, vous allez dans votre liaison dans IIS. Mettez votre liaison pour http normalement et ajouter une nouvelle liaison net.tcp, dans la configuration de liaison mis le port et le répertoire virtuel comme

8001:*

Ce paramètre autoriser toutes les connexions sur le port 8001 pour n'importe quel répertoire virtuel.

Vous devez également avoir la fonction "Activation de windows communication foundation (Http activation et de la Non-Activation Http)" installés sur votre serveur.

Answer 5

Il n'y a pas de réponse standard à cette question. Je suis en complet désaccord avec la réponse de Cheeso (l'Auto-hébergement de FMC n'est pas une bonne idée).

Veuillez consulter les liens suivants: (http://msdn.microsoft.com/en-us/library/ms730158.aspx, http://msdn.microsoft.com/en-us/library/bb332338.aspx) et de réfléchir à vos contraintes:

• système d'exploitation
• les performances attendues
• disponible HW
• disponibilité prévue

et vous verrez que dans de nombreuses situations "auto-hébergement" est la meilleure alternative.