Internet Information Services 7.0 (IIS 7.0) è stato rilasciato in versione RTM all'interno di Windows Server 2008, ma è già disponibile in una versione leggermente differente da oltre un anno, funzionante su Windows Vista.

Le novità introdotte da questa versione sono già state documentate in questo precedente articolo, per cui l'idea che guida questo articolo è quella di darvi la visione delle novità da un duplice punto di vista, quello dello sviluppatore e quello del sistemista.

Vale la pena segnalare che l'articolo già pubblicato a cui si fa riferimento tratta l'argomento in maniera organica, mentre questo è una carrellata più rapida delle funzionalità più interessanti, viste da due figure che in genere hanno necessità differenti, ma che spesso si trovano a dover lavorare nello stesso ambito per fare in modo che un'applicazione web possa trarre il massimo vantaggio sia dall'hardware disponibile che dalla configurazione software.

IIS 7.0 è probabilmente il primo web server che mette d'accordo sia le necessità degli sviluppatori, che hanno bisogno di maggiore libertà, sia quella dei sistemisti, che hanno bisogno di poter disporre di un sistema affidabile e sicuro, lasciando agli sviluppatori la possibilità di operare senza dover essere coinvolti direttamente quando sono necessari piccoli e semplici aggiustamenti alla configurazione.

Il punto di vista dello sviluppatore

IIS 7.0 è la prima versione di IIS che mette d'accordo sviluppatori e sistemisti. Cercando però di dare una risposta in maniera chiara ai vantaggi che uno sviluppatore ha nell'adottare IIS 7.0, è fuor di dubbio che l'aspetto principale, quello che salta all'occhio subito, è la possibilità di sfruttare la nuova pipeline integrata. La seconda caratteristica di indubbio interesse è la possibilità di poter finalmente usare il web.config come unico posto centralizzato per la definizione delle informazioni relative alla configurazione, caratteristica che rende IIS 7.0 unico e diverso rispetto alle versioni precedenti.

Integrated pipeline vs ISAPI pipeline

Sin dalla prima versione, IIS si è sempre stato basato sul concetto di ISAPI, una serie di specifiche che indicano come costruire moduli in grado di integrarsi con il web server. Per chi ha dimestichezza con ASP.NET, è lo stesso identico concetto espresso attraverso gli HttpModule all'interno della pipeline di ASP.NET.

L'idea è di filtrare particolari stati del web server per rispondere agli stessi con azioni personalizzate. Un tipico esempio di questo approccio è la possibilità di gestire i meccanismi di autenticazione. Probabilmente non ve lo sarete mai chiesti, ma il motivo per cui IIS chiede all'utente di autenticarsi quando viene impostata l'autenticazione di Windows, è proprio in un filtro ISAPI, che intercetta questa impostazione e richiede un'azione da parte dell'utente per andare avanti.

Lo stesso identico approccio è in realtà applicato ad altri scenari, come il logging, la creazione dell'output, perfino il funzionamento delle estensioni di FrontPage.

Quello che purtroppo IIS (almeno fino alla versione 6.0) non consente di fare è invece modificare questi comportamenti per aggiungerne di personalizzati. Nella maggior parte dei casi è possibile affiancare un comportamento personalizzato, ma non è assolutamente possibile rimuovere quello di default. E quando questo è possibile, è necessario usare C++.

Questo stato di cose si traduce spesso in una mancata ottimizzazione del web server, che deve ripetere due volte lo stesso tipo di funzionalità.

Se si pensa ad ASP.NET ed ai già citati HttpModule, l'esempio è perfettamente calzante. Possiamo sfruttare l'autenticazione via Forms di ASP.NET per personalizzare il modo in cui andiamo a dare accesso agli utenti alle aree private delle nostre applicazioni. L'effetto però è quello di passare due volte per lo stesso controllo per intercettare e gestire in maniera opportuna la richiesta di autenticazione, ovvero prima tramite IIS e poi attraverso il nostro HttpModule di ASP.NET.

Potendo invece unificare la pipeline delle richieste managed con quelle unmanaged (native), l'effetto è quello di ottimizzare questo genere di controlli. In più il fatto di poter usare codice managed come C# e VB.NET vuol dire poter sfruttare un ambiente più semplice da gestire e già noto agli sviluppatori.

L'ISAPI pipeline funziona nella modalità classica e va utilizzata quando non si vuole sfruttare questa integrazione, che invece è riservata alla nuova modalità, chiamata Integrated pipeline.

In questo scenario ASP.NET è perfettamente integrato all'interno di tutte le richieste e le risposte gestite dal web server, sin da quando esse partono. Questo vuol dire che IIS non utilizza più la propria autenticazione per poi richiamare ASP.NET, ripetendo l'operazione due volte, ma unifica nello stesso flusso l'operazione richiesta, unendo i moduli unmanaged con quelli managed. Lo schema che segue illustra meglio il funzionamento nei due scenari.

Figura 1 - ISAPI pipeline

Figura 2 - Integrated pipeline

In entrambi i casi le funzionalità a disposizione restano le stesse, ma se l'Application Pool è utilizzato con l'Integrated pipeline è possibile sfruttare gli HttpModule di ASP.NET anche con risorse di tipo unmanaged, come pagine ASP o PHP. Questa caratteristica di IIS 7.0 apre nuovi scenari dove è possibile, ad esempio, proteggere le diverse tipologie di pagine utilizzando sempre e comunque ASP.NET, rendondo unica l'autenticazione per tutte le parti di un sito, indipendentemente dalla tecnologia di sviluppo impiegata per la loro realizzazione.