Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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.msmq et msmq.formatname, 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é.
WAS inclut un service d’activation Message Queuing (MSMQ) qui active une application mise en file d’attente lorsqu’un ou plusieurs messages sont placés dans l’une des files d’attente utilisées par l’application. Le service d’activation MSMQ est un service NT qui est démarré automatiquement par défaut.
Pour plus d’informations sur WAS et ses avantages, consultez Hébergement dans le service d’activation des processus Windows. Pour plus d’informations sur MSMQ, consultez La vue d’ensemble des files d’attente.
Adressage de file d’attente dans WAS
Les applications WAS ont des adresses URI (Uniform Resource Identifier). Les adresses d’application ont deux parties : un préfixe d’URI de base et une adresse relative spécifique à l’application (chemin d’accès). Ces deux parties fournissent l’adresse externe d’une application lorsqu’elles sont jointes. 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, par exemple « net.msmq ://localhost », « msmq.formatname ://localhost » ou « net.tcp ://localhost ». Les adresses d’application sont ensuite construites en prenant des fragments de chemin spécifiques à l’application (tels que « /applicationOne ») et en les ajoutant au préfixe d’URI de base pour arriver à l’URI complet de l’application, par exemple « net.msmq ://localhost/applicationOne ».
Le service d’activation MSMQ utilise l’URI de l’application pour correspondre à la file d’attente que le service d’activation MSMQ doit surveiller pour les messages. Lorsque le service d’activation MSMQ démarre, il énumère toutes les files d’attente publiques et privées sur l’ordinateur où il est configuré pour recevoir et surveille les messages. Toutes les 10 minutes, le service d’activation MSMQ actualise la liste des files d’attente à surveiller. Lorsqu’un message se trouve dans une file d’attente, le service d’activation associe le nom de la file d’attente à l’URI d’application qui correspond le mieux à la liaison net.msmq et active l’application.
Remarque
L'application qui est activée doit correspondre (correspondance la plus longue) au préfixe du nom de file d'attente.
Par exemple, un nom de file d’attente est : msmqWebHost/orderProcessing/service.svc. Si Application 1 a un répertoire virtuel /msmqWebHost/orderProcessing avec un service.svc sous celui-ci, et Application 2 a un répertoire virtuel /msmqWebHost avec un orderProcessing.svc sous celui-ci, l’application 1 est activée. Si l’application 1 est supprimée, l’application 2 est activée.
Remarque
Lorsqu’une file d’attente est créée, tous les messages envoyés à celle-ci n’activent pas une application tant que le service d’activation MSMQ n’actualise pas la liste de files d’attente, soit au maximum 10 minutes après la création de la file d’attente. Le redémarrage du service d’activation actualise également la liste de files d’attente.
L'impact des files d'attente privées et publiques sur l'adressage
Le service d’activation MSMQ ne fait pas la distinction entre la surveillance de file d’attente privée et publique. Par conséquent, vous ne pouvez pas avoir de files d’attente publiques et privées portant le même nom. Si c'est le cas, une application hébergée sur le Web peut être activée suite à la lecture de l'une ou l'autre file d'attente.
Configuration de file d’attente pour l’activation
Le service d'activation MSMQ s'exécute comme Service réseau. Il s’agit du service qui surveille les files d’attente pour activer les applications. Pour que ce service active des applications à partir de la file d'attente, celle-ci doit autoriser le Service réseau à lire les messages dans sa liste de contrôle d'accès.
Messagerie toxique
La gestion des messages empoisonnés dans WCF est assurée par le canal, qui non seulement détecte qu’un message est empoisonné, mais sélectionne une disposition en fonction de la configuration de l’utilisateur. Par conséquent, il existe un seul message dans la file d’attente. L'application hébergée sur le web se déconnecte plusieurs fois et le message est déplacé vers une file de réessai. À un moment dicté par le délai de cycle de nouvelle tentative, le message est déplacé de la file d’attente de nouvelles tentatives vers la file d’attente principale pour réessayer. Toutefois, cela nécessite que le canal mis en file d’attente soit actif. Si l’application est recyclée par WAS, le message reste dans la file d’attente de nouvelles tentatives jusqu’à ce qu’un autre message arrive dans la file d’attente principale pour activer l’application mise en file d’attente. La solution de contournement dans ce cas consiste à déplacer le message manuellement de la file d’attente de nouvelles tentatives vers la file d’attente principale pour réactiver l’application.
Limitations relatives aux sous-files d'attente et aux files d'attente système
Une application hébergée par le service WAS ne peut pas être activée sur la base des messages présents dans une file d'attente système, telle que la file d'attente de lettres mortes à l'échelle du système, ou dans des sous-files d'attente, telles que les sous-files d'attente de poison. Il s’agit d’une limitation pour cette version du produit.