Hébergement dans le service d’activation des processus Windows
Le service d’activation de processus Windows (WAS) gère l’activation et la durée de vie des processus de travail qui contiennent des applications qui hébergent les 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 sur 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 possibilité 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 manière plus robuste, plus gérable et qui utilise efficacement les ressources :
L’activation basée sur les messages des applications et des applications de processus de travail démarre et s’arrête dynamiquement en réponse aux éléments de travail entrants qui arrivent à l’aide de protocoles réseau HTTP et non HTTP.
Recyclage robuste des processus d’application et de travail pour maintenir l’intégrité des applications en cours d’exécution.
Configuration et gestion centralisées des applications.
Permet aux applications de tirer parti du modèle de processus IIS sans nécessiter l’empreinte de déploiement d’une installation IIS complète. Windows Server AppFabric fonctionne avec IIS 7.0 et le service WAS (Windows Process Activation Service) pour fournir un environnement d’hébergement d’applications enrichi pour les services WCF et WF NET4. Ces avantages incluent la gestion du cycle de vie des processus, le recyclage des processus, l’hébergement partagé, la protection rapide contre les défaillances, la gestion des processus orphelins, l’activation à la demande et la surveillance de l'état de santé. Pour plus d’informations, consultez les fonctionnalités d’hébergement AppFabric et les concepts d’hébergement AppFabric .
Éléments du modèle d’adressage WAS
Les applications ont des adresses URI (Uniform Resource Identifier), qui sont les unités de code dont la durée de vie et l’environnement d’exécution sont gérés par le serveur. Une seule instance de serveur WAS peut être à la base de nombreuses applications différentes. Les serveurs organisent des applications en groupes appelés sites . Au sein d’un site, les applications sont organisées de manière hiérarchique qui reflète la structure des URI qui servent d’adresses externes.
Les adresses d’application ont deux parties : un préfixe d’URI de base et une adresse relative spécifique à l’application (chemin), qui fournissent l’adresse externe d’une application lorsqu’elle est jointe. Le préfixe d’URI de base est construit à partir de la liaison de site et est utilisé pour toutes les applications sous le site. Les adresses d’application sont ensuite construites en prenant des fragments de chemin spécifiques à l’application (par exemple, « /applicationOne ») et en les ajoutant au préfixe d’URI de base (par exemple, « net.tcp ://localhost ») pour arriver à l’URI complet de l’application.
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’accès de l’application | URI d’application de base |
|---|---|---|---|
| HTTP uniquement | http : * :80 :* | /appTwo | http://localhost/appTwo/ |
| 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 au sein d’une application peuvent également être traités. Dans une application, les ressources d’application sont traitées par rapport au chemin d’accès de l’application de base. Par exemple, supposons qu’un site sur un nom d’ordinateur contoso.com a des liaisons de site pour les protocoles HTTP et Net.TCP. Supposons également que le site contient une application située sur /Billing, qui expose un service sur GetOrders.svc. Ensuite, si le service GetOrders.svc a exposé un point de terminaison avec une adresse relative de SecureEndpoint, le point de terminaison de service est exposé aux deux URI suivants :
http://contoso.com/Billing/GetOrders.svc/SecureEndpointnet.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
L'environnement d'exécution WAS
Les applications sont organisées en sites à des fins d’adressage et de gestion. Au moment de l’exécution, les applications sont également regroupées dans des pools d’applications. Un pool d’applications peut héberger de nombreuses applications différentes à partir de nombreux sites différents. Toutes les applications d’un pool d’applications partagent un ensemble commun de caractéristiques d’exécution. Par exemple, ils s’exécutent tous sous la même version du Common Language Runtime (CLR) et partagent tous une identité de processus commune. Chaque pool d’applications correspond à une instance d’un processus de travail (w3wp.exe). Chaque application managée s’exécutant à l’intérieur d’un pool d’applications partagés est isolée des autres applications à l’aide d’un CLR AppDomain.