Partager via

Déploiement d'un service WCF hébergé dans Internet Information Services

Le développement et le déploiement d’un service Windows Communication Foundation (WCF) hébergé dans Internet Information Services (IIS) se compose des tâches suivantes :

  • Vérifiez que IIS, ASP.NET, WCF et le composant d’activation WCF sont correctement installés et inscrits.

  • Créez une application IIS ou réutilisez une application ASP.NET existante.

  • Créez un fichier .svc pour le service WCF.

  • Déployez l’implémentation du service sur l’application IIS.

  • Configurez le service WCF.

Pour obtenir une procédure pas à pas détaillée de la création d’un service WCF hébergé par IIS, consultez Guide pratique pour héberger un service WCF dans IIS.

Vérifiez que IIS, ASP.NET et WCF sont correctement installés et inscrits

WCF, IIS et ASP.NET doivent être installés pour que les services WCF hébergés par IIS fonctionnent correctement. Les procédures d’installation de WCF (dans le cadre du .NET Framework), ASP.NET et IIS varient en fonction de votre système d’exploitation. Pour plus d’informations sur l’installation de WCF et du .NET Framework, consultez Installer le .NET Framework pour les développeurs. Pour installer IIS sur Windows 10, ouvrez Programmes et fonctionnalités dans le Panneau de configuration , puis sélectionnez Activer ou désactiver les fonctionnalités Windows. Dans les fonctionnalités Windows, sélectionnez Internet Information Services , puis cliquez sur OK.

Fonctionnalités Windows avec IIS mis en surbrillance

Vous trouverez des instructions pour installer IIS sur d’autres systèmes d’exploitation à l’adresse IIS sur Windows Vista et Windows 7 et installer IIS 8.5 sur Windows Server 2012 R2.

Le processus d’installation pour .NET Framework inscrit automatiquement WCF auprès d’IIS si IIS est déjà présent sur l’ordinateur. Si IIS est installé après .NET Framework, une étape supplémentaire est nécessaire pour inscrire WCF auprès d’IIS et ASP.NET. Vous pouvez le faire comme suit, en fonction de votre système d’exploitation :

Créer une application IIS ou réutiliser une application ASP.NET existante

Les services WCF hébergés par IIS doivent résider à l’intérieur d’une application IIS. Vous pouvez créer une application IIS pour héberger exclusivement des services WCF. Vous pouvez également déployer un service WCF dans une application existante qui héberge déjà ASP.NET contenu 2.0 (par exemple, .aspx pages et ASP.NET services web [ASMX]). Pour plus d’informations sur ces options, consultez les sections « Hébergement de WCF côte à côte avec ASP.NET » et « Hébergement des services WCF en mode de compatibilité ASP.NET » dans les services WCF et ASP.NET.

Notez que IIS 6.0 et versions ultérieures redémarrent régulièrement une application de programmation orientée objet isolé. La valeur par défaut est 1740 minutes. La valeur maximale prise en charge est de 71 582 minutes. Ce redémarrage peut être désactivé. Pour plus d’informations sur cette propriété, consultez l’élément PeriodicRestartTime.

Créer un fichier .svc pour le service WCF

Les services WCF hébergés dans IIS sont représentés en tant que fichiers de contenu spéciaux (fichiers .svc) à l’intérieur de l’application IIS. Ce modèle est similaire à la façon dont les pages ASMX sont représentées à l’intérieur d’une application IIS en tant que fichiers .asmx. Un fichier .svc contient une directive de traitement spécifique à WCF (@ServiceHost) qui permet à l’infrastructure d’hébergement WCF d’activer les services hébergés en réponse aux messages entrants. La syntaxe la plus courante pour un fichier .svc se trouve dans l’instruction suivante.

<% @ServiceHost Service="MyNamespace.MyServiceImplementationTypeName" %>

Il se compose de la directive @ServiceHost et d’un attribut unique. Service La valeur de l’attribut Service est le nom de type CLR (Common Language Runtime) de l’implémentation de service. L’utilisation de cette directive équivaut essentiellement à créer un hôte de service à l’aide du code suivant.

new ServiceHost( typeof( MyNamespace.MyServiceImplementationTypeName ) );

Une configuration d’hébergement supplémentaire, telle que la création d’une liste d’adresses de base pour le service, peut également être effectuée. Vous pouvez également utiliser une commande personnalisée ServiceHostFactory pour étendre la directive à utiliser avec des solutions d’hébergement personnalisées. Les applications IIS qui hébergent les services WCF ne sont pas responsables de la gestion de la création et de la durée de vie des ServiceHost instances. L’infrastructure d’hébergement WCF managée crée l’instance nécessaire ServiceHost dynamiquement lorsque la première requête est reçue pour le fichier .svc. L’instance n’est pas libérée tant qu’elle n’est pas fermée explicitement par du code ou lorsque l’application est recyclée.

Pour plus d’informations sur la syntaxe des fichiers .svc, consultez @ServiceHost.

Déployer l’implémentation du service sur l’application IIS

Les services WCF hébergés dans IIS utilisent le même modèle de compilation dynamique que ASP.NET 2.0. Tout comme avec ASP.NET, vous pouvez déployer le code d’implémentation pour les services WCF hébergés par IIS de plusieurs façons à différents emplacements, comme suit :

  • En tant que fichier .dll précompilé situé dans le Global Assembly Cache (GAC) ou dans le répertoire \bin de l’application. Les fichiers binaires précompilés ne sont pas mis à jour tant qu’une nouvelle version de la bibliothèque de classes n’est pas déployée.

  • Comme fichiers sources noncompilés situés dans le répertoire \App_Code de l’application. Les fichiers sources situés dans ce répertoire sont obligatoires dynamiquement lors du traitement de la première requête de l’application. Toutes les modifications apportées aux fichiers dans le répertoire \App_Code entraînent le recyclage et la recompilation de l’application entière lors de la réception de la requête suivante.

  • Comme code noncompilé placé directement dans le fichier .svc. Le code d’implémentation peut également se trouver inline dans le fichier .svc du service, après la directive @ServiceHost. Toutes les modifications apportées au code inline entraînent le recyclage et la recompilation de l’application lors de la réception de la requête suivante.

Pour plus d’informations sur le modèle de compilation ASP.NET 2.0, consultez ASP.NET Vue d’ensemble de la compilation.

Configurer le service WCF

Les services WCF hébergés par IIS stockent leur configuration dans les applications Web.config fichier. Les services hébergés par IIS utilisent les mêmes éléments de configuration et syntaxe que les services WCF hébergés en dehors d’IIS. Toutefois, les contraintes suivantes sont uniques à l’environnement d’hébergement IIS :

  • Adresses de base pour les services hébergés par IIS.

  • Les applications hébergeant des services WCF en dehors d’IIS peuvent contrôler l’adresse de base des services qu’ils hébergent en transmettant un ensemble d’URI d’adresse de base au ServiceHost constructeur ou en fournissant un <élément hôte> dans la configuration du service. Les services hébergés dans IIS n’ont pas la possibilité de contrôler leur adresse de base ; l’adresse de base d’un service hébergé par IIS est l’adresse de son fichier .svc.

Adresses de point de terminaison pour les services IIS-Hosted

Lorsqu’elles sont hébergées dans IIS, les adresses de point de terminaison sont toujours considérées comme relatives à l’adresse du fichier .svc qui représente le service. Par exemple, si l’adresse de base d’un service WCF est http://localhost/Application1/MyService.svc avec la configuration de point de terminaison suivante :

<endpoint address="anotherEndpoint" />

Cela fournit un point de terminaison accessible à l’adresse http://localhost/Application1/MyService.svc/anotherEndpoint.

De même, l’élément de configuration de point de terminaison qui utilise une chaîne vide comme adresse relative fournit un point de terminaison accessible à l’adresse http://localhost/Application1/MyService.svcde base, qui est l’adresse de base.

<endpoint address="" />

Vous devez toujours utiliser des adresses de point de terminaison relatives pour les points de terminaison hébergés par IIS. La fourniture d’une adresse de point de terminaison complète (par exemple) http://localhost/MyService.svcpeut entraîner des erreurs dans le déploiement du service si l’adresse du point de terminaison ne pointe pas vers l’application IIS qui héberge le service exposant le point de terminaison. L’utilisation d’adresses de point de terminaison relatives pour les services hébergés évite ces conflits potentiels.

Transports disponibles

Les services WCF hébergés dans IIS 5.1 et IIS 6.0 sont limités à l’utilisation de la communication http. Sur ces plateformes IIS, la configuration d’un service hébergé pour utiliser une liaison non HTTP entraîne une erreur lors de l’activation du service. Pour IIS 7.0, les transports pris en charge incluent HTTP, Net.TCP, Net.Pipe, Net.MSMQ et msmq.formatname pour la compatibilité descendante avec les applications MSMQ existantes.

Sécurité du transport HTTP

Les services WCF hébergés par IIS peuvent utiliser la sécurité du transport HTTP (par exemple, les schémas d’authentification HTTPS et HTTP tels que l’authentification de base, Digest et l’authentification intégrée Windows) tant que le répertoire virtuel IIS qui contient le service prend en charge ces paramètres. Les paramètres HTTP Transport Security sur la liaison d’un point de terminaison hébergé doivent correspondre aux paramètres de sécurité de transport sur le répertoire virtuel IIS qui le contient.

Par exemple, un point de terminaison WCF configuré pour utiliser l’authentification HTTP digest doit résider dans un répertoire virtuel IIS qui est également configuré pour autoriser l’authentification HTTP Digest. Les combinaisons sans correspondance des paramètres IIS et des paramètres de point de terminaison WCF entraînent une erreur lors de l’activation du service.

Voir aussi