web-dev-qa-db-fra.com

IIS Hébergement de service WCF vs service Windows

Nous avons développé un service WCF et nous cherchons à le déployer ..__ Nos clients l’utiliseront avec basicHttpBinding mais notre équipe interne l’utilisera avec namedPipesBinding.

Nous nous demandons s’il est préférable de l’héberger dans IIS 7 ou avec un service Windows . Nous avons effectué des tests et nous avons découvert que lorsque nous ajoutons des liaisons dans IIS, la mise à jour fichier de notre service. Cela signifie que nous aurions besoin de maintenir la configuration à deux endroits différents. Ce n'est pas logique, non?

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

c#.netwcfiiswas
45
esylvestre

Pour répondre à ces questions:

Nous avons fait des tests et nous avons découvert que lorsque nous ajoutons des liaisons dans IIS, il ne met pas à jour le fichier de configuration de notre service. Cela signifie que nous aurions besoin de maintenir la configuration dans deux endroits différents. Ce n'est pas logique, droite ?

Lorsque vous utilisez IIS pour héberger votre service, vous devez configurer votre fichier App.config ou votre fichier web.config afin de permettre à IIS d'exposer certaines liaisons, de sorte que dans votre fichier de configuration, toutes vos liaisons seront exécutées. vous autorisez votre service wcf. Http, net.tcp etc ...

Dans votre liaison, vous ne spécifierez pas d'adresse, car vous spécifierez directement ces adresses dans IIS.

Dans IIS, vous devez autoriser la liaison disponible dans les paramètres avancés de votre site Web. Après cela, vous définissez une nouvelle liaison pour votre site Web "service Web", ajoutez toutes les liaisons que vous souhaitez écouter et spécifiez l'adresse.

Vous spécifierez 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 paramètre avancé, votre testament sera mis 

http, net.tcp dans les protocoles activés

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

8001: *

Ce paramètre autorise toutes les connexions au port 8001 pour tous les répertoires virtuels.

Vous devez également avoir la fonctionnalité "Activation WCF, (activation Http et Activation non-Http)" sur votre serveur.

11
Cédric Boivin

L'hébergement dans IIS a de nombreux avantages et inconvénients.

Oui, IIS vous donne un chargement à la demande - cela peut être un avantage ou un inconvénient. Lorsqu'une requête arrive, ServiceHost est construit, puis la classe de service hébergée est instanciée et la requête est gérée. Rien ne doit fonctionner 24 heures sur 24. Mais en même temps, cette configuration nécessite plus de temps et d’efforts chaque fois qu’un message arrive et, en tant que programmeur, vous n’avez vraiment pas beaucoup de contrôle sur votre hôte de service. 

Et oui, avec IIS, le répertoire virtuel où réside le fichier * .svc définit votre adresse - les adresses de base ou les adresses explicitement définies dans votre configuration ne sont pas prises en compte. Et sans trop d'effort, vous ne pouvez pas changer la disposition des adresses de service - elles seront toujours http: //servername/virtualdirectory/YourService.svc (y compris l'extension .svc).

L'auto-hébergement est souvent plus rapide, car votre ServiceHost est déjà opérationnel - mais vous devez vous assurer qu'il est vraiment opérationnel, il n'y a pas de chargement "à la demande" à chaque fois qu'un message arrive - peut traiter la demande, ou non. Mais vous avez beaucoup plus de contrôle sur l'hôte de service - quand et comment il est construit, etc., et vous devez choisir et définir vos adresses de service comme bon vous semble.

Personnellement, je choisirais presque toujours d'utiliser l'auto-hébergement - dans une application console pour les tests, dans un service NT pour la production. Pour moi, cela semble tout simplement la manière la plus appropriée de procéder, et la plus contrôlée également. Vous devez faire plus de travail - mais vous savez exactement ce que vous faites.

Marc

75
marc_s

marc_s donne généralement d'excellentes réponses avec lesquelles je suis tout à fait d'accord, mais dans ce cas je ne le fais pas.
L’auto-hébergement de la WCF n’est pas une bonne idée, en particulier avec les technologies de Dublin publiées prochainement par Microsoft. La gestion et les opérations des applications WCF (et WF) sont beaucoup plus simples lorsqu'elles sont hébergées dans IIS. 

De plus, vous bénéficiez du chargement à la demande. 

Il existe une option permanente pour IIS7.5 (WS2008 R2). 

Et vous pouvez facilement faire la réécriture d'URL pour omettre le .svc si cela vous dérange. 

26
Cheeso

Tidbit intéressant-> après avoir lu ce fil de discussion, je suis tombé sur ces mots dans MSDN à propos de l'hébergement d'un service WCF à l'aide d'un service Windows:

Certains des inconvénients des services Windows sont les suivants: 

• Déploiement: les services doivent être installés avec l'utilitaire .NET Framework Installutil.exe ou via une action personnalisée dans un package d'installation.
• Fonctionnalités limitées: les services Windows disposent toujours d’un ensemble limité de fonctionnalités prédéfinies pour la prise en charge de la haute disponibilité, d’une gestion simplifiée, de la gestion des versions et de scénarios de déploiement. Vous devez essentiellement couvrir vous-même ces exigences avec du code personnalisé. Par exemple, IIS est livré avec plusieurs de ces fonctionnalités par défaut. Les services Windows ajoutent à la possibilité de restauration et à certaines fonctionnalités de sécurité, mais vous devez néanmoins effectuer certains travaux vous-même.
http://msdn.Microsoft.com/en-us/library/bb332338.aspx

... et le lien suivant:

Services d'hébergement: (Beau tableau de comparaison)
http://msdn.Microsoft.com/en-us/library/ms730158.aspx

16
atconway

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

Vérifiez les liens suivants: ( http://msdn.Microsoft.com/en-us/library/ms730158.aspx , http://msdn.Microsoft.com/en-us/library/bb332338. aspx ) et réfléchissez à vos contraintes:

  • système opérationnel
  • performance attendue
  • disponible HW
  • disponibilité attendue

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

7
Rafa

IIS vous fournit de nombreuses fonctionnalités prédéfinies, telles que le rechargement de domaine d'applications, la surveillance, etc.

C’est pourquoi vous devez d’abord répondre à cette question: avez-vous besoin de toutes ces fonctionnalités ou non? .__ Sinon, le service Windows peut être envisagé.

5
Vitaliy Liptchinsky

Bien qu'il y ait une réponse sélectionnée ici, je me permettrai de poster un lien de fil de questions/réponses. 

Comment configurer le service WCF à partir du code lorsqu'il est hébergé dans IIS?

Ce que vous trouverez dans ma réponse ici (et le lien qui y figure) est votre contrôle fin sur l'hôte de service, que vous le chargiez dans WService ou dans IIS.

Au démarrage du service, vous pouvez déterminer IIS quelles sont ses liaisons et créer les points de terminaison appropriés. Recherchez la configuration de IIs dans l'espace de noms Microsoft.Web.Administration. 

J'espère que ça aide un peu.

0
ChristoD