Services d’hébergement

Article
05/10/2023

Pour devenir actif, un service doit être hébergé dans un environnement d'exécution qui le crée et contrôle son contexte et sa durée de vie. Les services WCF (Windows Communication Foundation) sont conçus pour s’exécuter dans tout processus Windows qui prend en charge le code managé.

WCF est le modèle de programmation unifié de Microsoft permettant de générer des applications orientées service. Ce modèle de programmation reste cohérent et est indépendant de l'environnement d'exécution dans lequel le service est déployé. En pratique, cela signifie que le code de vos services est essentiellement le même quelle que soit l'option d'hébergement.

Ces options d'hébergement vont de l'exécution dans une application console à une exécution dans des environnements serveur tels qu'un service Windows dans un processus de travail managé par les services IIS (Internet Information Services) ou WAS (Windows Process Activation Services). Les développeurs choisissent l'environnement d'hébergement qui répond aux spécifications de déploiement du service. Ces spécifications peuvent dériver de la plateforme sur laquelle l'application est déployée, du transport sur lequel envoyer et recevoir des messages ou du type de recyclage de processus et tout autre gestion de processus indispensable pour garantir la disponibilité adéquate, ou d'autres impératifs de gestion ou de fiabilité. La section suivante fournit des informations et des instructions sur les options d'hébergement.

Options d’hébergement

Auto-hébergement dans une application managée

Les services WCF peuvent être hébergés dans n’importe quelle application managée. Il s'agit de l'option la plus souple car l'infrastructure à déployer est la plus faible. Vous incorporez le code pour le service à l'intérieur du code d'application managée, puis créez et ouvrez une instance de ServiceHost pour rendre le service disponible. Pour plus d’informations, consultez Guide pratique pour héberger un service WCF dans une application managée.

Cette option active deux scénarios courants : les services WCF qui s’exécutent à l’intérieur d’applications console et des applications clientes élaborées telles que celles basées sur WPF (Windows Presentation Foundation) ou WinForms (Windows Forms). L’hébergement d’un service WCF à l’intérieur d’une application console est en général utile pendant la phase de développement de l’application. Cela simplifie son débogage, l'obtention des informations de suivi pour déterminer ce qui se passe à l'intérieur de l'application, et son déplacement en la copiant vers un nouvel emplacement. Cette option d’hébergement permet aux applications clientes complexes, comme WPF et WinForms, de communiquer facilement avec le monde extérieur. Il peut s’agir par exemple d’un client de collaboration pair à pair qui utilise WPF pour son interface utilisateur et héberge également un service WCF qui permet à d’autres clients de se connecter à lui et de partager des informations.

Services Windows managés

Cette option d’hébergement consiste à enregistrer le domaine d’application (AppDomain) qui héberge un service WCF en tant que service Windows managé (autrefois appelé service NT) afin que la durée de vie de processus du service soit contrôlée par le Gestionnaire de contrôle des services (SCM) pour les services Windows. Comme l'option d'auto-hébergement, ce type d'environnement d'hébergement requiert que du code d'hébergement soit écrit dans le cadre de l'application. Le service est implémenté en tant que service Windows et en tant que service WCF en lui faisant hériter de la classe ServiceBase ainsi que d’une interface de contrat de service WCF. Le ServiceHost est ensuite créé et ouvert dans une méthode OnStart(String[]) substituée et fermée dans une méthode OnStop() substituée. Une classe Installer qui hérite de Installer doit également être implémentée pour permettre au programme d'être installé comme un service Windows par l'outil Installutil.exe. Pour plus d’informations, consultez Guide pratique pour héberger un service WCF dans un service Windows managé. Le scénario activé par l’option d’hébergement du service Windows managé est celui d’un service WCF de longue durée hébergé en dehors d’IIS dans un environnement sécurisé qui n’est pas activé par message. La durée de vie du service est contrôlée par le système d'exploitation. Cette option d'hébergement est disponible dans toutes les versions de Windows.

Internet Information Services (IIS)

L’option d’hébergement IIS est intégrée à ASP.NET et utilise les fonctionnalités offertes par ces technologies, telles que le recyclage de processus, l’arrêt en cas d’inactivité, le contrôle d’état de processus et l’activation basée sur des messages. Sur les systèmes d’exploitation Windows XP et Windows Server 2003, il s’agit de la solution par défaut pour héberger les applications de service web qui sont fortement sollicitées et doivent être très scalables. Les services IIS offrent également la facilité de gestion intégrée que les clients attendent d'un produit serveur de classe d'entreprise. Cette option d'hébergement requiert que les services IIS soient configurés correctement, mais n'exige pas l'écriture d'un code d'hébergement dans le cadre de l'application. Pour plus d’informations sur la configuration de l’hébergement IIS pour un service WCF, consultez Guide pratique pour héberger un service WCF dans IIS.

Les services hébergés par IIS peuvent utiliser uniquement le transport HTTP. Son implémentation dans IIS 5.1 a introduit des limitations dans Windows XP. L’activation basée sur des messages fournie pour un service WCF par IIS 5.1 sur Windows XP empêche tout autre service WCF auto-hébergé sur le même ordinateur d’utiliser le port 80 pour communiquer. Les services WCF peuvent s’exécuter dans le même domaine d’application/pool d’application/processus Worker que d’autres applications une fois hébergés par IIS 6.0 sur Windows Server 2003. Cependant, dans la mesure où WCF et IIS 6.0 utilisent la pile HTTP en mode noyau (HTTP.sys), IIS 6.0 peut partager le port 80 avec d’autres services WCF auto-hébergés qui s’exécutent sur le même ordinateur, contrairement à IIS 5.1.

Windows Process Activation Service (WAS)

Le service WAS (Windows Process Activation Service) est le nouveau mécanisme d’activation de processus pour Windows Server 2008, également disponible sur Windows Vista. Il conserve le modèle de processus IIS 6.0 classique (pools d’applications et activation de processus basée sur des messages) et les fonctionnalités d’hébergement (telles que la protection rapide contre les pannes, le monitoring de l’intégrité et le recyclage), mais il supprime la dépendance envers HTTP de l’architecture d’activation. IIS 7.0 utilise le service WAS pour accomplir l’activation basée sur des messages via HTTP. Les composants WCF supplémentaires s’intègrent aussi dans le service WAS pour assurer l’activation basée sur des messages via les autres protocoles pris en charge par WCF, tels que TCP, MSMQ et les canaux nommés. Cela permet aux applications qui utilisent des protocoles de communication d'utiliser les fonctionnalités IIS (telles que le recyclage de processus, la protection rapide contre les pannes et le système de configuration commun) qui étaient réservées exclusivement aux applications basées sur HTTP.

Cette option d'hébergement requiert que les services WAS soient configurés correctement, mais n'exige pas l'écriture d'un code d'hébergement dans le cadre de l'application. Pour plus d’informations sur la configuration de l’hébergement WAS, consultez Guide pratique pour héberger un service WCF dans WAS.

Choisir un environnement d’hébergement

Le tableau suivant résume certains avantages et scénarios clés associés à chacune des options d'hébergement.

Environnement d'hébergement	Scénarios courants	Avantages et limitations clés
Application managée (« auto-hébergée »)	- Applications consoles utilisées pendant le développement - Applications clientes WPF et WinForm élaborées accédant aux services	- Flexibilité - Facilité de déploiement - Ne constitue pas une solution d’entreprise pour les services
Services Windows (autrefois appelés services NT)	- Service WCF de longue durée hébergé en dehors d’IIS	- Durée de vie des processus de service contrôlée par le système d’exploitation, et non activée par des messages - Pris en charge par toutes les versions de Windows - Environnement sécurisé
IIS 5.1, IIS 6.0	- Exécution d’un service WCFG côte à côte avec du contenu ASP.NET sur Internet à l’aide du protocole HTTP	- Recyclage de processus - Arrêt en cas d’inactivité - Monitoring de l’intégrité de processus - Activation basée sur des messages - HTTP uniquement
Windows Process Activation Service (WAS)	- Exécution d’un service WCF sur Internet sans installer IIS à l’aide de différents protocoles de transport	- IIS n’est pas requis - Recyclage de processus - Arrêt en cas d’inactivité - Monitoring de l’intégrité de processus - Activation basée sur des messages - Fonctionne avec HTTP, TCP, les canaux nommés et MSMQ
IIS 7.0	- Exécution d’un service WCF avec contenu ASP.NET - Exécution d’un service WCF sur Internet à l’aide de différents protocoles de transport	- Avantages du service WAS - Intégré au contenu ASP.NET et IIS

Le choix d'un environnement d'hébergement dépend de la version de Windows sur lequel il est déployé, des transports requis pour envoyer les messages et du type de recyclage de processus et de domaine d'application requis. Le tableau suivant résume les données liées à ces spécifications.

Environnement d'hébergement	Disponibilité de plateforme	Transports pris en charge	Recyclage de processus et AppDomain
Applications managées (« auto-hébergées »)	Windows XP, Windows 2003, Windows Vista, Windows Server 2008	HTTP, net.tcp, net.pipe, net.msmq	Non
Services Windows (autrefois appelés services NT)	Windows XP, Windows 2003, Windows Vista, Windows Server 2008	HTTP, net.tcp, net.pipe, net.msmq	Non
IIS 5,1	Windows XP	HTTP	Oui
IIS 6.0	Windows Server 2003	HTTP	Oui
Windows Process Activation Service (WAS)	Windows Vista, Windows Server 2008	HTTP, net.tcp, net.pipe, net.msmq	Oui

Il est important de noter que l'exécution d'un service ou d'une extension à partir d'un hôte non fiable compromet la sécurité. De plus, lors de l’ouverture d’un ServiceHost lorsque l’emprunt d’identité est activé, une application doit garantir que l’utilisateur n’est pas déconnecté, par exemple en mettant en cache le WindowsIdentity de l’utilisateur.