Quelle est la différence entre le mode pipeline «classique» et «intégré» dans IIS7?

Hier soir, je déployais une application ASP.NET MVC et j'ai découvert qu'il fallait moins de travail pour déployer avec IIS7 réglé en mode intégré. Ma question est quelle est la différence? Et quelles sont les implications de l'utilisation de l'un ou de l'autre?

Le mode classique (le seul mode dans IIS6 et ci-dessous) est un mode où IIS ne fonctionne qu'avec les extensions ISAPI et les filtres ISAPI directement. En fait, dans ce mode, ASP.NET n'est qu'une extension ISAPI (aspnet_isapi.dll) et un filtre ISAPI (aspnet_filter.dll). IIS traite simplement ASP.NET comme un plugin externe implémenté dans ISAPI et fonctionne avec lui comme une boîte noire (et uniquement lorsqu'il doit transmettre la demande à ASP.NET). Dans ce mode, ASP.NET n'est pas très différent de PHP ou d'autres technologies pour IIS.

Le mode intégré, d'autre part, est un nouveau mode dans IIS7 où le pipeline IIS est étroitement intégré (c'est-à-dire tout à fait le même) que le pipeline de demande ASP.NET. ASP.NET peut voir chaque demande qu'il souhaite et manipuler les choses en cours de route. ASP.NET n'est plus traité comme un plugin externe. Il est complètement mélangé et intégré dans IIS. Dans ce mode, les ASP.NET HttpModuleont pratiquement autant de puissance qu'un filtre ISAPI aurait eu et les ASP.NET HttpHandlerpeuvent avoir des capacités presque équivalentes à celles d'une extension ISAPI. Dans ce mode, ASP.NET fait fondamentalement partie d'IIS.

Mode pool d'applications intégré

Lorsqu'un pool d'applications est en mode intégré, vous pouvez tirer parti de l'architecture intégrée de traitement des demandes d'IIS et d'ASP.NET. Lorsqu'un processus de travail dans un pool d'applications reçoit une demande, la demande passe par une liste ordonnée d'événements. Chaque événement appelle les modules natifs et gérés nécessaires pour traiter des parties de la demande et générer la réponse.

L'exécution de pools d'applications en mode intégré présente plusieurs avantages. Tout d'abord, les modèles de traitement des demandes d'IIS et d'ASP.NET sont intégrés dans un modèle de processus unifié. Ce modèle élimine les étapes qui étaient précédemment dupliquées dans IIS et ASP.NET, telles que l'authentification. De plus, le mode intégré permet la disponibilité des fonctionnalités gérées pour tous les types de contenu.

Mode de pool d'applications classique

Lorsqu'un pool d'applications est en mode classique, IIS 7.0 gère les demandes comme en mode d'isolation du processus de travail IIS 6.0. Les demandes ASP.NET passent d'abord par des étapes de traitement natives dans IIS, puis sont acheminées vers Aspnet_isapi.dll pour le traitement du code managé dans le runtime managé. Enfin, la demande est renvoyée via IIS pour envoyer la réponse.

Cette séparation des modèles de traitement des demandes IIS et ASP.NET entraîne la duplication de certaines étapes de traitement, telles que l'authentification et l'autorisation. En outre, les fonctionnalités de code managé, telles que l'authentification par formulaire, sont uniquement disponibles pour les applications ASP.NET ou les applications pour lesquelles vous avez mappé par script toutes les demandes à traiter par aspnet_isapi.dll.

Assurez-vous de tester la compatibilité de vos applications existantes en mode intégré avant de mettre à niveau un environnement de production vers IIS 7.0 et d'affecter des applications à des pools d'applications en mode intégré. Vous ne devez ajouter une application à un pool d'applications en mode classique que si l'application ne fonctionne pas en mode intégré. Par exemple, votre application peut s'appuyer sur un jeton d'authentification transmis d'IIS au runtime géré et, en raison de la nouvelle architecture dans IIS 7.0, le processus interrompt votre application.

Tiré de: Quelle est la différence entre DefaultAppPool et Classic .NET AppPool dans IIS7?

Source originale: Introduction à l'architecture IIS

IIS 6.0 et versions précédentes:

ASP.NET intégré à IIS via une extension ISAPI, une API C (API basée sur le langage de programmation C) et exposé son propre modèle de traitement des demandes et des applications.

Cela a effectivement exposé deux pipelines de serveurs distincts (demande / réponse), un pour les filtres natifs ISAPI et les composants d'extension, et un autre pour les composants des applications gérées. Les composants ASP.NET s'exécuteraient entièrement à l'intérieur de la bulle d'extension ISAPI ASP.NET ET UNIQUEMENT pour les demandes mappées sur ASP.NET dans la configuration de mappage de script IIS.

Demandes à des types de contenu non ASP.NET: - les images, les fichiers texte, les pages HTML et les pages ASP sans script ont été traités par IIS ou d'autres extensions ISAPI et n'étaient PAS visibles par ASP.NET.

La principale limitation de ce modèle était que les services fournis par les modules ASP.NET et le code d'application ASP.NET personnalisé n'étaient PAS disponibles pour les demandes non ASP.NET

Qu'est-ce qu'une carte SCRIPT?

Les mappages de script sont utilisés pour associer des extensions de fichier au gestionnaire ISAPI qui s'exécute lorsque ce type de fichier est demandé. La mappe de script possède également un paramètre facultatif qui vérifie que le fichier physique associé à la demande existe avant de permettre le traitement de la demande

Un bon exemple peut être seen here

IIS 7 et supérieur

IIS 7.0 et versions ultérieures ont été entièrement repensées pour fournir une toute nouvelle ISAPI basée sur l'API C ++.

IIS 7.0 et versions ultérieures intègrent le runtime ASP.NET avec les fonctionnalités de base du serveur Web, fournissant un pipeline de traitement des demandes unifié (unique) qui est exposé aux composants natifs et gérés appelés modules (IHttpModules)

Cela signifie que IIS 7 traite les demandes qui arrivent pour tout type de contenu, avec les deux NON ASP.NET Modules / native IIS moduleset ASP.NET modulesfournissant le traitement des demandes à toutes les étapes.C'est la raison pour laquelle les types de contenu NON ASP.NET (.html, fichiers statiques) peuvent être traités par les modules .NET .

• Vous pouvez créer de nouveaux modules gérés (IHttpModule ) pouvant s'exécuter pour tout le contenu de l'application et fournir un ensemble amélioré de services de traitement des demandes à votre application.
• Ajouter de nouveaux gestionnaires gérés ( IHttpHandler)

En mode classique, IIS fonctionne directement avec les extensions ISAPI et les filtres ISAPI. Et utilise deux pipelines, l'un pour le code natif et l'autre pour le code managé. Vous pouvez simplement dire qu'en mode classique, IIS 7.x fonctionne exactement comme IIS 6 et vous ne bénéficiez pas d'avantages supplémentaires grâce aux fonctionnalités IIS 7.x.

En mode intégré, IIS et ASP.Net sont étroitement couplés plutôt qu'en fonction de seulement deux DLL sur Asp.net comme dans le cas du mode classique.