ASP.NET onder de Motorkap: Integratie met IIS7
Door Michiel van Otegem
23 juni 2009
Met de komst van Windows 2008 hebben we vanuit ASP.NET ook meteen te maken met een nieuwe versie van Internet
Information Server (IIS). Op het eerste gezicht maakt dat niet zoveel uit, onze ASP.NET applicaties werken zonder
aanpassingen op IIS5, IIS6 en IIS7. Onder de kap is IIS7 echter compleet nieuw en de manier waarop ASP.NET
geïntegreerd is ook. Dit geeft ons allerlei nieuwe mogelijkheden.
IIS7 Classic Mode
IIS7 kent twee verschillende instellingen: Classic Mode en Integrated Mode. IIS7 Classic Mode is er voor die gevallen waarin een applicatie niet goed werkt in IIS7 in Integrated Mode. In Classic Mode gedraagt IIS7 zich namelijk als IIS5 en IIS6, die vanuit het oogpunt van ASP.NET niet (veel) verschillen. In IIS5 en IIS6 wordt ASP.NET aangeroepen vanuit de ISAPI Extension aspnet_isapi.dll. Het verschil tussen IIS5 en IIS6 zit met name in de procescontext. In IIS5 is die gedeeld tussen alle applicaties en draait ASP.NET in een eigen proces(context), terwijl in IIS6 applicaties gescheiden kunnen worden in verschillende Application Pools, waardoor ASP.NET geen eigen proces nodig heeft.
In IIS zijn ISAPI Extensions gekoppeld aan een bepaald bestandsformaat. Zo zijn onder andere .aspx, .asmx en .config gekoppeld aan de ASP.NET ISAPI. Wanneer IIS bepaald heeft wat het bestandsformaat is, wordt (indien het niet gaat om statische bestanden of CGI scripts) de bijbehorende ISAPI Extension aangeroepen om de request af te handelen. Voor en na die aanroep doorloopt IIS nog een aantal stappen waarvan ASP.NET geen weet heeft en ook geen invloed op uit kan oefenen. Afbeelding 1 laat zien hoe IIS en ASP.NET samenwerken bij het afhandelen van een request. Afbeelding 1 is een versimpelde weergave, waarin een aantal stappen bij zowel IIS als ASP.NET achterwege gelaten zijn. Dit laat echter mooi zien dat er sprake is van overlap tussen IIS en ASP.NET. Beide voeren een authenticatiestap uit en beide bepalen welke handler de request af moet handelen op basis van de bestandsextensie. Omdat onder andere de authenticatie van ASP.NET los staat van die van IIS, is het niet mogelijk om ASP.NET bestanden te laten beveiligen die niet door ASP.NET afgehandeld worden, zoals statische HTML en afbeeldingen. Je kunt daar omheen door in IIS de ASP.NET ISAPI te koppelen aan de betreffende extensie, maar dat brengt een behoorlijke overhead met zich mee in vergelijking met de afhandeling door IIS.
Afbeelding 1: Versimpelde weergave van ASP.NET in IIS5, IIS6 en IIS7 Classic Mode
IIS7 Integrated Mode
IIS7 is helemaal van de grond af opnieuw opgebouwd en geheel modulair gemaakt. De opbouw lijkt heel veel op die
van ASP.NET, waar bijna ieder onderdeel te vervangen is door een custom module, zoals ik in de vorige column
gedemonstreerd heb voor sessies in ASP.NET. ASP.NET en IIS bestaan in feite uit een pipeline en modules die
aangeroepen worden in de pipeline. De modules implementeren de interface die hoort bij het event(s) waar de module
wat mee wil doen.
De overeenkomsten tussen de pipelines van ASP.NET en IIS, zoals weergegeven in afbeelding 1, maken het mogelijk om
deze samen te voegen. In IIS7 Integrated Mode maakt ASP.NET onderdeel uit van de pipeline van IIS. Hierdoor is het
onder andere mogelijk om de authenticatie eenmalig te doen én Forms Authentication toe te passen voor alle
requests die door IIS afgehandeld worden. Omdat er sprake is van een enkele pipeline, brengt dit geen overhead met
zich mee zoals in IIS5, IIS6 en IIS7 Classic Mode. Om dezelfde reden is er ook geen overhead bij het aanroepen van
een ASP.NET bestand, omdat de juiste handler maar een keer bepaald hoeft te worden.
Afbeelding 2: Versimpelde weergave van ASP.NET in IIS7 Integrated Mode
Het aardige van de manier waarop IIS7 en ASP.NET met elkaar samenwerken is dat de HttpModules die je schrijft nu
direct inhaken op de pipeline van IIS, in plaats van die van ASP.NET. Hierdoor is de controle die je uit kunt
oefenen nog groter. Net als ASP.NET kent IIS7 het HttpApplication object. Dit object kennen we als ASP.NET
ontwikkelaars al en we kunnen het net zo manipuleren als we voorheen deden. Het verschil is dat we nu direct met
IIS communiceren, terwijl voorheen het resultaat van ASP.NET doorgesluisd werd naar IIS, waarna het eventueel nog
aangepast kon worden. Modules die naderhand nog aanpassingen doen kunnen we zo nodig weglaten.
Dit artikel is eerder verschenen op de website van SDN, 13-03-2008
|
