¿Cuál es la diferencia entre el modo de canalización 'clásico' e 'integrado' en IIS7?
Anoche estaba implementando una aplicación ASP.NET MVC y descubrí que es menos trabajo implementar con IIS7 configurado en modo integrado. Mi pregunta es cual es la diferencia? ¿Y cuáles son las implicaciones de usar uno u otro?
El modo clásico (el único modo en IIS6 y versiones anteriores) es un modo en el que IIS solo funciona con extensiones ISAPI y filtros ISAPI directamente. De hecho, en este modo, ASP.NET es sólo una extensión ISAPI (aspnet_isapi.dll) y un filtro ISAPI (aspnet_filter.dll). IIS simplemente trata a ASP.NET como un complemento externo implementado en ISAPI y funciona con él como una caja negra (y solo cuando es necesario enviar la solicitud a ASP.NET). En este modo, ASP.NET no se diferencia mucho de PHP u otras tecnologías para IIS.
El modo integrado, por otro lado, es un modo nuevo en IIS7 donde la canalización de IIS está estrechamente integrada (es decir, es igual) que la canalización de solicitudes de ASP.NET. ASP.NET puede ver cada solicitud que desee y manipular cosas a lo largo del camino. ASP.NET ya no se trata como un complemento externo. Está completamente mezclado e integrado en IIS. En este modo, HttpModulelos ASP.NET básicamente tienen casi tanta potencia como la que habría tenido un filtro ISAPI y los ASP.NET HttpHandlerpueden tener una capacidad casi equivalente a la que podría tener una extensión ISAPI. En este modo, ASP.NET es básicamente parte de IIS.
Modo de grupo de aplicaciones integrado
Cuando un grupo de aplicaciones está en modo integrado, puede aprovechar la arquitectura integrada de procesamiento de solicitudes de IIS y ASP.NET. Cuando un proceso de trabajo en un grupo de aplicaciones recibe una solicitud, la solicitud pasa por una lista ordenada de eventos. Cada evento llama a los módulos nativos y administrados necesarios para procesar partes de la solicitud y generar la respuesta.
Existen varios beneficios al ejecutar grupos de aplicaciones en modo integrado. Primero, los modelos de procesamiento de solicitudes de IIS y ASP.NET se integran en un modelo de proceso unificado. Este modelo elimina pasos que anteriormente se duplicaban en IIS y ASP.NET, como la autenticación. Además, el modo Integrado permite la disponibilidad de funciones administradas para todo tipo de contenido.
Modo de grupo de aplicaciones clásico
Cuando un grupo de aplicaciones está en modo Clásico, IIS 7.0 maneja las solicitudes como en el modo de aislamiento de procesos de trabajo de IIS 6.0. Las solicitudes de ASP.NET primero pasan por los pasos de procesamiento nativo en IIS y luego se enrutan a Aspnet_isapi.dll para procesar el código administrado en el tiempo de ejecución administrado. Finalmente, la solicitud se enruta nuevamente a través de IIS para enviar la respuesta.
Esta separación de los modelos de procesamiento de solicitudes de IIS y ASP.NET da como resultado la duplicación de algunos pasos de procesamiento, como la autenticación y la autorización. Además, las funciones de código administrado, como la autenticación de formularios, solo están disponibles para aplicaciones ASP.NET o aplicaciones para las cuales tiene un script asignado para que todas las solicitudes sean manejadas por aspnet_isapi.dll.
Asegúrese de probar la compatibilidad de sus aplicaciones existentes en el modo Integrado antes de actualizar un entorno de producción a IIS 7.0 y asignar aplicaciones a grupos de aplicaciones en el modo Integrado. Solo debe agregar una aplicación a un grupo de aplicaciones en modo Clásico si la aplicación no funciona en modo Integrado. Por ejemplo, su aplicación podría depender de un token de autenticación pasado desde IIS al tiempo de ejecución administrado y, debido a la nueva arquitectura en IIS 7.0, el proceso interrumpe su aplicación.
Tomado de: ¿ Cuál es la diferencia entre DefaultAppPool y Classic .NET AppPool en IIS7?
Fuente original: Introducción a la arquitectura IIS
IIS 6.0 y versiones anteriores:
ASP.NET se integró con IIS a través de una extensión ISAPI, una API C (API basada en lenguaje de programación C) y expuso su propia aplicación y modelo de procesamiento de solicitudes.
Esto expuso efectivamente dos canalizaciones de servidor (solicitud/respuesta) separadas, una para filtros ISAPI nativos y componentes de extensión, y otra para componentes de aplicaciones administradas. Los componentes de ASP.NET se ejecutarían completamente dentro de la burbuja de extensión ISAPI de ASP.NET Y SOLO para solicitudes asignadas a ASP.NET en la configuración del mapa de script de IIS.
Las solicitudes de tipos de contenido que no son ASP.NET: imágenes, archivos de texto, páginas HTML y páginas ASP sin secuencias de comandos fueron procesadas por IIS u otras extensiones ISAPI y NO eran visibles para ASP.NET.
La principal limitación de este modelo era que los servicios proporcionados por los módulos ASP.NET y el código de aplicación ASP.NET personalizado NO estaban disponibles para solicitudes que no fueran ASP.NET.
¿Qué es un MAPA DE GUIÓN?
Los mapas de secuencias de comandos se utilizan para asociar extensiones de archivos con el controlador ISAPI que se ejecuta cuando se solicita ese tipo de archivo. El mapa de script también tiene una configuración opcional que verifica que el archivo físico asociado con la solicitud exista antes de permitir que se procese la solicitud.
Un buen ejemplo puede serseen here
IIS 7 y superior
IIS 7.0 y superiores han sido rediseñados desde cero para proporcionar una nueva ISAPI basada en API C++.
IIS 7.0 y superiores integran el tiempo de ejecución de ASP.NET con la funcionalidad principal del servidor web, proporcionando una canalización de procesamiento de solicitudes unificada (única) que está expuesta a componentes nativos y administrados conocidos como módulos (IHttpModules).
Lo que esto significa es que IIS 7 procesa solicitudes que llegan para cualquier tipo de contenido, y NON ASP.NET Modules / native IIS modulesproporciona ASP.NET modulesprocesamiento de solicitudes en todas las etapas. Esta es la razón por la cual los tipos de contenido NO ASP.NET (.html, archivos estáticos) pueden ser manejados por módulos .NET. .
- Puede crear nuevos módulos administrados (
IHttpModule) que tengan la capacidad de ejecutarse para todo el contenido de la aplicación y proporcionar un conjunto mejorado de servicios de procesamiento de solicitudes para su aplicación. - Agregar nuevos controladores administrados (
IHttpHandler)
