Questo articolo (diviso in tre parti) vuole essere una panoramica sull’architettura ASP.NET dal punto di vista del sistema operativo. Non parleremo quindi di oggetti intrinsici o di modalità di scrittura del codice, ma ci concentreremo sull’interazione fra l’architettura di Internet Information Server e il processo in cui viene compilato e eseguito il codice ASP.NET, per poi entrare nelle varie componenti che entrano in gioco ad ogni esecuzione di richieste Http. Molti settaggi vengono gestiti da file di configurazione XML di cui analizzeremo le varie sezioni dedicate appunto alla gestione del processo stesso.

Per meglio comprendere l’interazione fra IIS e ASP.NET partiamo da lontano con i compianti Active Server Pages 1.0 (quasi non ci ricordiamo più il significato dell’acronimo ASP) e Internet Information Server 3.0.

Un po’ di storia per capire il nuovo contesto

ASP 1.0 nasce come applicazione (anche detta estensione, da non confondersi con filtro) ISAPI in Internet Information Server 3.0. In due parole questo significava semplicemente associare all’estensione “.asp” una dll che ne gestisse l’esecuzione, cosi come avveniva e avviene tutt’oggi per qualunque altra estensione.

Procediamo per gradi: Internet Information Server 3.0 è un processo (INetInfo.exe) che riceve (ascolta) le richieste Http che arrivano sulle varie porte configurate e per ognuna di esse si preoccupa di recuperare dal disco il file richiesto. Trovato tale file IIS inizia a comporre la risposta Http, che come sappiamo, consta di un Header (tipo di risposta, stato della risposta, lunghezza della risposta, ecc.) e di un Body che viene compilato con il file richiesto dal client. In questo semplice scenario IIS non fa altro che ricevere richieste di risorse (insieme di bytes) e inviare risposte con l’insieme di bytes richiesti dal client.

Ad ogni estensione di file è però possibile associare una DLL (applicazione ISAPI) che modifichi il semplice comportamento (da File Server potremmo dire) appena descritto. ASP non è altro che una DLL che consente di interpretare il codice scritto all’interno di una risorsa richiesta per rendere dinamica la risposta generata da IIS.
Il processo si compone dei seguenti passi: per prima cosa IIS si incarica di effettuare tutti i controlli necessari (validità dell’utente, della richiesta ecc.), per poi rintracciare la risorsa su disco e passarla in toto alla DLL in oggetto (Asp.dll). Il motore ASP interpreta il codice presente nel file e forma dinamicamente la risposta Http che viene ripassata ad IIS per l’invio al client.

In IIS 3.0 l’applicazione ISAPI ASP girà in-process rispetto ad IIS come qualunque altra API richiamata da un eseguibile. Questo crea non pochi problemi dal punto di vista della protezione delle applicazioni e di IIS stesso. Mi spiego meglio: se n applicazioni ASP girano su uno stesso server, il crash di una di esse porta inevitabilmente al crash di tutte le altre (visto che girano tutte nello stesso processo) e molto spesso al crash anche dell’eseguibile che le ospita...poco male se fosse un client gestito dall’utente, un “po’ peggio” se si tratta del nostro servizio web che smette di rispondere anche alle richieste di elementi statici (pagine Html o immagini o quant’altro).

Dobbiamo attendere la versione successiva di IIS, la 4.0, per avere una prima risposta a questa problematica: nel marzo 1997 è stato presentato in italia Microsoft Transaction Server 1.0 (MTS) che, fra le mille magie promesse, consentiva anche di separare il contesto di esecuzione di un eseguibile rispetto ai componenti (COM DLL) dell’applicazione. I componenti venivano installati in package gestiti da MTS. Ogni package rappresentava un processo separato. A fronte di un crash di un componente in un package, l’eseguibile resta “illeso” e può richiamare nuovamente la dll in questione che veniva fatta “magicamente” rinascere in un nuovo processo.
L’idea venne applicata anche a IIS 4 (“fortemente” integrato con MTS 2.0) , in cui è possibile configurare ogni applicazione ASP in modo che giri in uno spazio di memoria separato da INetInfo.exe: Il pulsante “Create/Remove” indica a IIS di gestire le apgine asp di questo sito/directory come un’applicazione. Se la directory (o l’intero sito) non viene marcata come applicazione, ASP.DLL gira ancora in-process rispetto ad IIS. Al contrario, le directory marcate come Application vengono inserita in un package MTS (IIS In-Process Application).

 Ricorderete sicuramente la maschera di gestione delle applicazioni seguente,

 

Il processo interno per eseguire una richiesta Http per una pagina di un’applicazione ASP è il seguente: IIS riceve la richiesta, controlla nel suo metabase la configurazione dell’applicazione che ospita la risorsa richiesta, chiama in causa MTS che farà girare ASP.DLL all’interno del package “IIS In-Process Applications” come si vede nella figura seguente.
Inoltre, se l’applicazione viene marcata “Run in separate memory space” MTS utilizzerà un package apposito per far girare solamente l’applicazione in questione, che risulterà quindi, non solo isolata da INetInfo, ma anche isolata da tutte le altre applicazioni ASP ospitate sulla macchina. Sicuramente perdiamo un po’ in performance ma abbiamo la “garanzia” (le virgolette sono d’obbligo) che a fronte di un crash applicativo IIS resta “in piedi” (così come tutte le altre applicazioni ASP) e che alla prossima richiesta IIS chiamerà di nuovo in causa MTS che a sua volta farà ripartire il processo per l’applicazione web.

 

Nella figura precedente vediamo il Package “IIS In-Process Applications” che ospita tutte le applicazioni ASP in un unica area di memoria (processo) e il package “Default Web Site/.../ExAir/Catalog” che ospiterà l’applicazione “ExAir/Catalog”.

Questa configurazione si evolve in IIS 5.0 e COM+ sulla piattaforma Windows 2000. In ogni caso resta l’idea di base: a fronte di una richiesta di una risorsa con estensione “.asp” Internet Information Server esegue i controlli Http e poi passa la palla a una DLL che si incarica di formare dinamicamente la risposta.
L’intera configurazione delle estensioni e delle applicazioni ISAPI deve essere effettuata in IIS.
E’ possibile scriversi una propria applicazione ISAPI che gestisca le risposte ed associarla in IIS ad una certa estensione di file. Le applicazioni ISAPI si scrivono in C++ e ovviamente devono sottostare all’insieme di regole che ne consentiranno l’inserimento nell’architettura di IIS.

 

Le applicazioni (anche dette estensioni) ISAPI non devono essere confuse con i filtri ISAPI. Un’estensione ISAPI, come ci suggerisce il termine, interviene per estendere le funzionalità di Internet Information Server e di conseguenza agiscono dopo il normale lavoro di IIS fornendo poi una risposta Http che verrà inviata al client. Microsoft Proxy 1.0/2.0 (per la parte “Web Proxy”, non WinSock Proxy) è un’estensione ISAPI (W3Proxy.dll) che consente ad un web server locale di girare la richiesta arrivata da un browser interno verso la rete esterna, di cacharne la risposta e di inviarla al client che ne ha fatto richiesta. Il browser chiede informazioni via Http ad IIS e vedendosi ritornare una risposta, ignora tutto il lavoro fatto dall’estensione ISAPI.

Filtri ISAPI

Un filtro ISAPI invece interviene prima che IIS controlli l’estensione del file, cerchi la risorsa su disco o chiami le estensioni ISAPI configurate. Frequentemente, il compito di un filtro ISAPI è quello di analizzare la richiesta arrivata ad IIS, effuattuarvi controlli e apportarvi modifiche  prima che le richieste vengano processate; allo stesso modo ogni risposta “attraversa” il filtro ISAPI che potrà eseguire nuovamente delle analisi, controlli o effettuare modifiche in qualunque byte dello stream di risposta.
Un filtro ISAPI installato di default in IIS è SSPIFilt.dll che ci ricorda il Security Support Provider Interface, parolone che banalizzando identifica l’API che controlla la sicurezza sulle risorse (account utente valido, password corretta ecc.).
Per chiarire ulteriormente il concetto, un’altro filtro ISAPI è FPEXEDLL.dll (non è un errore il nome del file), che rappresenta le FrontPage Server Extension. Come sappiamo, le FP Extension, consentono di eseguire operazioni sulle risorse memorizzate su IIS come rename, move, ecc, che in Http sarebbero state impossibili, almento fino all’arrivo dell’estensione standard del protocollo Http denominata WebDAV (Visual Studio.NET utilizza di default WebDAV per la pubblicazione/gestione delle applicazioni Web) . Il trucco è semplice: i client (FrontPage o Visual InterDev) inseriscono nella richiesta http informazioni aggiuntive e proprietarie; quando la richiesta arriva ad IIS interviene il filtro ISAPI delle FrontPage Server Extension che analizza queste informazioni, esegue le operazioni richieste e invia la risposta al client. La richiesta in questo caso non arriva neanche al normale flusso di funzionamento di IIS (ricerca del file su disco, parsing della risorsa e invio della risposta): è il filtro ISAPI che compone la risposta da inviare a FrontPage o InterDev indicando in questo caso il successo/fallimento dell’operazione.

Nella figura seguente si vedono i filtri ISAPI installati di default in IIS 5 per il servizio WWW. Come ci indica il testo sopra l’elenco, i filtri ISAPI presenti sono attivi per tutti i virtual site di questa macchina, vengono eseguiti nell’ordine elencato e non verranno visualizzati nell’elenco dei filtri installati in ogni sito proprio perchè configurati a livello master.

 

I filtri ISAPI si scrivono anch’essi in C++ secondo regole definite e consentono di “incastrare” metodi di funzionamento, controlli e/o flussi diversi dal normale funzionamento di un server Web.
Dopo questa breve analisi del normale funzionamento di IIS,  delle funzionalità delle applicazioni ISAPI e del ruolo dei filtri ISAPI cerchiamo di calare questi concetti nel mondo ASP.NET in cui restano validi tutti i concetti.

Ci sentiamo presto con le due parti conclusive dell'articolo...