DEV232 - IIS 7.0: End to End Overview

Una nueva sesión del Tech·Ed... Esta iba sobre las novedades de IIS7.0 y ofrecía una visión general del mismo.

Primero vimos las principales novedades de IIS7 respecto IIS6

• Seguridad: Muchos componentes que antes estaban en el "kernel" ahora son modulares (p.ej. CGI).
• Extensibilidad: IIS7 aporta una API nueva (tanto nativa como managed) para temas de extensibilidad. Además ofrece soporte integrada para los módulos ASP.NET
• Configuración: Basada en ficheros XML, con el mismo esquema que los ficheros de configuración de ASP.NET. Aparece además inetmgr una herramienta de configuración con interfaz gráfica (a l'estilo de lo que viene haciendo MS últimamente).
  
• Managment: Aparece una herramienta de línea de comandos que permitee realizar cualquier operación con IIS.

Modularidad
Uno de los aspectos claves de IIS7 es su construcción modular. Casi todo es un módulo que se carga o no en función de lo que indique el fichero de configuración. Existen más de 40 módulos. Por ejemplo varios módulos de autenticación (Digest, Windows,...), varios de desarrollos de aplicaciones (ASP, ASP.NET,...) y así ir siguiendo.
El setup por defecto de IIS7 instala solamente los módulos necesarios para servir páginas estáticas con autenticación anónima (jejejee... problemas de seguridad mínimos).
Es posible incluso desactivar todos los módulos y IIS sólo carga la pipe-line (la pipe-line es quien genera los distintos eventos a los que los módulos se pueden suscribir).

Extensibilidad
IIS6 se extiende mediante filtros ISAPI y extensiones ISAPI. Muy potentes pero complejas de desarrollar y no hay soporte managed para ISAPI.
Con IIS6 se pueden crear módulos con código managed pero esos módulos deben ser procesados por la extensión ISAPI de ASP.NET antes de ser invocados. Es decir, la request debe pasar por toda la pipe-line de IIS6, hasta llegar a la extensión ISAPI de ASP.NET y entonces pasar por toda la pipe-line de ASP.NET.
En IIS7 se pueden combinar Handlers de ASP.NET (IHttpHandlers) con los nativos (filtros o extensiones ISAPI) y la pipe-line es compartida. Eso significa que una request ya no debe pasar por el pipe-line de ASP.NET antes de poder ser tratada por un IHttpHandler.
De igual forma podemos tener módulos ASP.NET (IHttpModules) que se pueden suscribir a esta pipe-line compartida. Esos IHttpModules también se cargan o no en función de lo que indique el fichero de configuración del servidor.

Aquí hizo una demo, donde creo un IHttpHandler, que capturaba todas las requests a imágenes y les añadía una marca de agua a modo de copyright. A diferencia de IIS6 este IHttpHandler era a nivel de servidor IIS.

Configuración
Muere la metabase de IIS y toda la configuración es ahora basada en fichero XML (basada en el esquema de ASP.NET). El fichero principal se llama ApplicationHost.config (jejeeee... se ve que IIS tiene pretensiones de servidor de aplicaciones).
La configuración de cada aplicación web se realiza mediante el web.config (por lo que es compartido automáticamente si la aplicación es asp.net), y los ficheros de configuración de cada aplicación pueden redefinir parámetros establecidos en el ApplicationHost.config siempre que éste último lo permita.

Aquí hizo una demo: habilito la cache (tag <cacge> de web.config) y comprobamos como el IHttpHandler de la demo anterior pasaba de soportar tasas de 8 req/s a más de 400 req/s.

Managment
IIS7 viene con un proveedor WMI completamente nuevo.
Nueva herramienta de configuración con interfaz gráfica (no basada en MMC, como todas las últimas).
La herramienta en línea de comandos AppCmd permite configurar cualquier cosa del servidor, ya no son necesarios los scripts vbs que vienen con IIS6 (de hecho para que funcionen los scripts de managment de IIS6 debe instalarse un módulo de compatibilidad que no se instala por defecto).
En este punto nos hizo una demo de AppCmd, creando 10 aplicaciones web desde un fichero bat.

Resolución de errores
IIS7 añade páginas renovadas para errores HTTP 500 con detalles adicionales del error y soporte mejorado para custom-errors. Al estilo de ASP.NET las páginas pueden ser distintas para localhost y para clientes externos.
Aparece también la herramienta FREB que permite realizar un seguimiento de lo ocurrido cuando una request falla. Genera un xml (con una xslt asociada para su visualización) donde hay información de la request en cada paso de la pipe-line. Se guarda un xml por cada request fallada, dentro del directorio de logs.

Y esto fue todo lo que nos contaron... Bastante interesante todo, no?