Qual é a diferença entre o modo de pipeline 'clássico' e 'integrado' no IIS7?

Eu estava implantando um aplicativo ASP.NET MVC ontem à noite e descobri que é menos trabalhoso implantar com o IIS7 definido no modo integrado. Minha pergunta é qual é a diferença? E quais são as implicações de usar um ou outro?

O modo clássico (o único modo no IIS6 e abaixo) é um modo em que o IIS trabalha apenas com extensões ISAPI e filtros ISAPI diretamente. De fato, nesse modo, o ASP.NET é apenas uma extensão ISAPI (aspnet_isapi.dll) e um filtro ISAPI (aspnet_filter.dll). O IIS trata o ASP.NET apenas como um plug-in externo implementado no ISAPI e funciona com ele como uma caixa preta (e somente quando é necessário fornecer a solicitação ao ASP.NET). Nesse modo, o ASP.NET não é muito diferente do PHP ou de outras tecnologias para o IIS.

O modo integrado, por outro lado, é um novo modo no IIS7, em que o pipeline do IIS está totalmente integrado (ou seja, é o mesmo) que o pipeline de solicitação do ASP.NET. O ASP.NET pode ver todas as solicitações que deseja e manipular as coisas ao longo do caminho. O ASP.NET não é mais tratado como um plug-in externo. É completamente misturado e integrado ao IIS. Nesse modo, os ASP.NETs HttpModulebasicamente têm quase a mesma potência que um filtro ISAPI teria e os ASP.NETs HttpHandlerpodem ter capacidade quase equivalente à de uma extensão ISAPI. Nesse modo, o ASP.NET é basicamente uma parte do IIS.

Modo de pool de aplicativos integrado

Quando um pool de aplicativos está no modo Integrado, você pode tirar proveito da arquitetura de processamento de solicitação integrada do IIS e ASP.NET. Quando um processo de trabalho em um pool de aplicativos recebe uma solicitação, a solicitação passa por uma lista ordenada de eventos. Cada evento chama os módulos nativos e gerenciados necessários para processar partes da solicitação e gerar a resposta.

Há vários benefícios na execução de pools de aplicativos no modo Integrado. Primeiro, os modelos de processamento de solicitação do IIS e ASP.NET são integrados a um modelo de processo unificado. Este modelo elimina etapas que foram duplicadas anteriormente no IIS e ASP.NET, como autenticação. Além disso, o modo Integrado permite a disponibilidade de recursos gerenciados para todos os tipos de conteúdo.

Modo de pool de aplicativos clássico

Quando um pool de aplicativos está no modo Clássico, o IIS 7.0 lida com solicitações como no modo de isolamento do processo do operador do IIS 6.0. As solicitações do ASP.NET passam primeiro pelas etapas de processamento nativo no IIS e são roteadas para Aspnet_isapi.dll para processamento do código gerenciado no tempo de execução gerenciado. Finalmente, a solicitação é roteada de volta através do IIS para enviar a resposta.

Essa separação dos modelos de processamento de solicitação do IIS e do ASP.NET resulta na duplicação de algumas etapas de processamento, como autenticação e autorização. Além disso, os recursos de código gerenciado, como autenticação de formulários, estão disponíveis apenas para aplicativos ASP.NET ou aplicativos para os quais você mapeou por script todas as solicitações a serem tratadas pelo aspnet_isapi.dll.

Teste a compatibilidade dos aplicativos existentes no modo Integrado antes de atualizar um ambiente de produção para o IIS 7.0 e atribuir aplicativos aos pools de aplicativos no modo Integrado. Você só deve adicionar um aplicativo a um pool de aplicativos no modo Clássico se o aplicativo não funcionar no modo Integrado. Por exemplo, seu aplicativo pode depender de um token de autenticação transmitido do IIS para o tempo de execução gerenciado e, devido à nova arquitetura no IIS 7.0, o processo interrompe seu aplicativo.

Retirado de: Qual é a diferença entre DefaultAppPool e Classic .NET AppPool no IIS7?

Fonte original: Introdução à arquitetura do IIS

IIS 6.0 e versões anteriores:

O ASP.NET integrou-se ao IIS por meio de uma extensão ISAPI, uma API C (API baseada na linguagem de programação C) e expôs seu próprio modelo de processamento de aplicativos e solicitações.

Isso expôs efetivamente dois pipelines de servidor separados (solicitação / resposta), um para filtros ISAPI nativos e componentes de extensão e outro para componentes de aplicativos gerenciados. Os componentes do ASP.NET seriam executados totalmente dentro do balão de extensão ISAPI do ASP.NET E APENAS para solicitações mapeadas para o ASP.NET na configuração do mapa de script do IIS.

Solicitações para tipos de conteúdo que não são do ASP.NET: - imagens, arquivos de texto, páginas HTML e páginas ASP sem script, foram processadas pelo IIS ou outras extensões ISAPI e NÃO eram visíveis para o ASP.NET.

A principal limitação desse modelo foi que os serviços fornecidos pelos módulos ASP.NET e pelo código do aplicativo ASP.NET personalizado NÃO estavam disponíveis para solicitações que não são do ASP.NET

O que é um mapa de script?

Os mapas de script são usados ​​para associar extensões de arquivo ao manipulador ISAPI que é executado quando esse tipo de arquivo é solicitado. O mapa de scripts também possui uma configuração opcional que verifica se o arquivo físico associado à solicitação existe antes de permitir que a solicitação seja processada

Um bom exemplo pode ser seen here

IIS 7 e superior

O IIS 7.0 e superior foram reprojetados desde o início para fornecer um novo ISAPI baseado em API C ++.

O IIS 7.0 e superior integram o tempo de execução do ASP.NET à funcionalidade principal do servidor Web, fornecendo um pipeline de processamento de solicitação unificado (único) exposto a componentes nativos e gerenciados conhecidos como módulos (IHttpModules)

O que isso significa é que o IIS 7 processa solicitações que chegam para qualquer tipo de conteúdo, com ambas NON ASP.NET Modules / native IIS modulese ASP.NET modulesfornecendo processamento de solicitações em todas as etapas. Esse é o motivo pelo qual tipos de conteúdo NÃO ASP.NET (.html, arquivos estáticos) podem ser manipulados por módulos .NET .

• Você pode criar novos módulos gerenciados ( IHttpModule) com capacidade de execução para todo o conteúdo do aplicativo e forneceu um conjunto aprimorado de serviços de processamento de solicitação para o seu aplicativo.
• Adicionar novos manipuladores gerenciados ( IHttpHandler)

No modo clássico, o IIS trabalha h extensões ISAPI e filtros ISAPI diretamente. E usa duas linhas de pipe, uma para código nativo e outra para código gerenciado. Você pode simplesmente dizer que, no modo Clássico, o IIS 7.x funciona da mesma maneira que o IIS 6 e não obtém benefícios extras com os recursos do IIS 7.x.

No modo integrado, o IIS e o ASP.Net são fortemente acoplados, dependendo de apenas duas DLLs no Asp.net, como no caso do modo clássico.