Hébergement dans le service d'activation de processus de Windows (WAS, Windows Process Activation Service)
Le service d'activation des processus Windows (WAS, Windows Process Activation Service) gère l'activation et la durée de vie des processus worker contenant des applications qui hébergent des services Windows Communication Foundation (WCF). Le modèle de processus WAS généralise le modèle de processus IIS 6.0 pour le serveur HTTP en supprimant la dépendance envers le protocole HTTP. Cela permet aux services WCF d'utiliser à la fois des protocoles HTTP et non-HTTP, tels que Net.TCP, dans un environnement d'hébergement qui prend en charge l'activation basée sur les messages et offre la capacité d'héberger un grand nombre d'applications sur un ordinateur donné.
Pour plus d’informations sur la création d’un service WCF qui s’exécute dans l’environnement d’hébergement WAS, consultez Guide pratique pour héberger un service WCF dans WAS.
Le modèle de processus WAS fournit plusieurs fonctionnalités qui permettent aux applications d’être hébergées de façon plus fiable, plus maniable et plus efficace au niveau de l’utilisation des ressources :
L’activation basée sur message des applications et les applications de processus de travail démarrent et s’arrêtent dynamiquement en réponse aux éléments de travail entrants qui arrivent, via des protocoles réseau HTTP et non-HTTP.
Application fiable et recyclage des processus de travail pour maintenir l'intégrité de l'exécution d'applications.
Configuration et gestion centralisées de l'application.
Permet aux applications de tirer parti du modèle de processus IIS sans requérir d'espace mémoire pour le déploiement d'une installation IIS complète.
Windows Server App Fabric fonctionne avec IIS 7.0 et WAS afin d'offrir un environnement d'hébergement d'application enrichi pour les services NET4 WCF et WF. Ces avantages incluent la gestion du cycle de vie de processus, le recyclage de processus, l'hébergement partagé, la protection rapide contre les incidents, les processus parallèles, l'activation à la demande et le contrôle d'état. Pour plus d'informations, consultez Fonctionnalités d'hébergement d’App Fabric et Concepts d'hébergement d’App Fabric.
Éléments du modèle d'adressage WAS
Les applications ont des adresses d'URI (Uniform Resource Identifier) qui sont en fait des unités de code dont la durée de vie et l'environnement d'exécution sont gérés par le serveur. Une instance de serveur WAS unique peut loger de nombreuses applications différentes. Les serveurs organisent les applications en groupes appelés sites. Dans un site, les applications sont réorganisées d'une façon hiérarchique reflétant la structure des URI qui servent d'adresses externes.
Les adresses d’application se composent de deux parties : un préfixe URI de base et une adresse relative spécifique à l’application (chemin d’accès) qui fournit l’adresse externe pour une application en cas d’association. Le préfixe URI de base est construit à partir de la liaison du site et est utilisé pour toutes les applications sous le site. Les adresses d’application sont ensuite créées en prenant des fragments de chemin propres à l’application (comme "/applicationOne") et en les ajoutant au préfixe d’URI de base (par exemple, "net.tcp://localhost") afin d’obtenir l’URI d’application complet.
Le tableau suivant illustre plusieurs scénarios d'adressage possibles pour les sites WAS avec des liaisons de site HTTP et non-HTTP.
| Scénario | Liaisons de site | Chemin d’application | URI d'application de base |
|---|---|---|---|
| HTTP uniquement | http: *:80:* | /appTwo | http://localhost/appTwo/ |
| À la fois HTTP et non-HTTP | http: *:80:* net.tcp: 808:* |
/appTwo | http://localhost/appTwo/net.tcp://localhost/appTwo/ |
| Non-HTTP uniquement | net.pipe: * | /appThree | net.pipe://appThree/ |
Les services et les ressources dans une application peuvent également être adressés. Dans une application, les ressources d'application sont adressées relativement au chemin d'accès d'application de base. Par exemple, supposez qu'un site sur un nom d'ordinateur contoso.com aie des liaisons de site pour les protocoles HTTP et Net.TCP à la fois. Supposez également que le site contienne une application située dans /Billing, qui expose un service à GetOrders.svc. Dans ce cas, si le service GetOrders.svc a exposé un point de terminaison avec une adresse relative de SecureEndpoint, le point de terminaison du service est exposé aux deux URI suivants :
http://contoso.com/Billing/GetOrders.svc/SecureEndpointnet.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
Exécution WAS
Les applications sont organisées en sites pour les besoins d'adressage et de gestion. Au moment de l'exécution, les applications sont également groupées ensemble dans des pools d'applications. Un pool d'applications peut loger de nombreuses applications différentes à partir de nombreux sites différents. Toutes les applications à l'intérieur d'un pool d'applications partagent un jeu commun de caractéristiques d'exécution. Par exemple, elles s'exécutent toutes sous la même version CRL (Common Language Runtime) et elles partagent toutes une identité de processus commune. Chaque pool d'applications correspond à une instance d'un processus de travail (w3wp.exe). Chaque application gérée qui s'exécute dans un pool d'applications partagé est isolée des autres applications au moyen d'un AppDomain CLR.