ASP.NET ha ido evolucionando, y ahora con OWIN y Katana se va a proceder a un cambio de filosofía dentro del Framework. No se trata de una nueva tecnología, ni de una nueva plataforma, ni tampoco de una nueva API sino de un cambio de cómo debe evolucionar ASP.NET.

Veamos un poco cómo ha sido la evolución de ASP.NET desde que Microsoft lo sacó. Con la primera versión de ASP.NET Microsoft quiso cumplir dos objetivos: que los desarrolladores que usaban ASP puedieran trabajar con el Framework .NET, y que además los desarrolladores de aplicaciones de escritorio tradicionales pudieran dar el salto a la web. Esta primera versión salió junto con el Framework .NET, y sus actualizaciones llegaban con cada nueva versión del Framework.

Esta evolución de ASP.NET no era tan rápida como la de la web. Así que con la salida del nuevo Framework MVC, basado en ASP.NET, éste se empezó a distribuir independientemente del Frakework .NET. Esto ha hecho posible que MVC evolucione a un ritmo independiente más rápido.

Con esto podemos ver como los diferentes componentes de ASP.NET van convirtiéndose en componentes externos al Framework .NET que evolucionan a su propio ritmo, que no tienen que esperar a las nuevas versiones del Framework .NET completo, y que se distribuyen de forma sencilla mediante NuGet.

La última gran novedad nos llegó de la mano de Web API. Éste Framework no trae ninguna de pendencia sobre System.Web.dll, lo que lo hace completamente independiente de IIS. Permitiendo hospedar Web API en procesos como por ejemplo una aplicación de consola. Y es aquí donde entra OWIN.

OWIN (Open Web Interface For .NET)

El proyecto de OWIN lo empezó la comunidad .NET creando una abstracción entre los servidores web y los componentes del Framework. El diseño de esta abstracción ha tenido dos objetivos fundamentales, crear una abstracción lo más simple posible y que utilice las mínimas dependencias posibles. Todo esto nos ayuda a la hora de crear nuevos componentes, ya que nos permite desarrollarlos más fácilmente y son más fáciles de utilizar e integrar en el resto de proyectos. Además esto nos proporciona la posibilidad de cambiar entre diferentes servidores hosts o incluso tener aplicaciones web hospedadas en nuestro propio proceso.

Esto se ha conseguido mediante dos elementos. El primero es un diccionario con las variables de entorno donde se guarda el estado de toda la información para procesas las peticiones y respuestas realizadas al servidor. El diccionario con las variables de entorno se define como:

IDictionary<string, object>

Un servidor web compatible con OWIN es responsable de crear este diccionario con los datos de las peticiones y respuestas, como las cabeceras, el cuerpo, los parámetros… En la web de OWIN podemos encontrar las especificaciones con todas las variables de entorno que como mínimo deben de estar.

El segundo elemento que nos proporciona OWIN es el application delegate, que es el que se encarga de ejecutar los diferentes componentes pasándoles como parámetro el diccionario anterior y devolviendo una Task. Se define como:

Func<IDictionary<string, object>, Task>;

Con esta abstracción se consiguen una serie de objetivos:

· Tener un número mínimo de dependencias.

· Obtener un mayor rendimiento gracias al diseño asíncrono.

· Poder crear pipelines complejos.

Hemos estado comentando en todo momento que OWIN es una abstracción que no va a ser un nuevo servidor web, sino que simplemente es una especificación. Desde el punto de vista de la implementación, dentro de NuGet podemos encontrar el paquete Owin.dll que únicamente contiene una única interfaz IAppBuilder. Esta interfaz formaliza la especificación y nos permite crear componentes con un punto de referencia concreto y que haya compatibilidad entre ellos.

Proyecto Katana

Mientras OWIN es mantenido por la comunidad, el proyecto Katana son los componentes de OWIN creados por Microsoft. Aunque estos también los encontramos como software libre. Entre estos componentes podemos encontrar SignalR y Wep API.

Los principales objetivos del proyecto Katana son:

· Componentes portables, fácilmente sustituibles por nuevos componentes y fácilmente actualizables sin alterar al resto de componentes. Además implica que los mismos pueden ser ejecutados tanto en un IIS como en un servidor de terceros o incluso en procesos nuestros como aplicaciones de consola.

· Modular y flexible. A diferencia de muchos frameworks que vienen con multitud de funcionalidades activadas por defecto, el proyecto Katana tiene como objetivo pequeños componentes centrados en tareas concretas, dando al programador la elección de cuales de ellos utilizar.

· Eficiente y escalable. Romper el framework en pequeños componentes nos da la posibilidad de utilizar sólo los componentes que realmente necesitamos, incrementando el rendimiento de nuestras aplicaciones.

Para conseguir esto Katana divide la arquitectura de la aplicación en cuatro capas lógicas, dando la posibilidad de cambiar un componente en cualquiera de las capas sin afectar al resto.

clip_image001

Host

El host es responsable de manejar el hilo principal y crear el flujo que seguirán las peticiones en el pipeline de OWIN. Actualmente en el proyecto Katana hay tres opciones:

· IIS: Instalando el páquete Microsoft.Owin.Host.SystemWeb el pipeline de OWIN funcionara sobre IIS sin problemas, pero las capas de Host y Server están ligadas y no podemos sustituir la implementación del Server.

· OwinHost.exe: El proyecto Katana ya nos trae un ejecutable que puede arrancarnos el host desde una aplicación de consola, como si lo hospedáramos en nuestro propio proceso pero sin tener que crearlo nosotros.

· Host personalizado: El proyecto Katana nos permite hospedar nuestras aplicaciones en nuestro propio proceso, de una manera similar a como se realiza con Web API.

Server

El Server es el responsable de empezar y mantener los procesos en los que corre la aplicación, además de abrir las diferentes conexiones, escuchar las peticiones y enviarlas al pipeline de OWIN creado por el Host. Actualmente en el proyecto Katana hay dos implementaciones para esta capa:

· Microsoft.Owin.Host.SystemWeb. Como se ha comentado anteriormente, IIS actúa tanto de servidor como de Host.

· Microsoft.Owin.Host.HttpListener. Este componente utiliza la clase HttpListener del Framework .NET para abrir las diferentes conexiones.

Middleware/framework

Un componente middleware sólo necesita implementar el application delegate de OWIN para poder ser llamado desde el pipeline. Sin embargo, para facilitar el desarrollo de nuevos componentes, el proyecto Katana soporta gran cantidad de convenciones y tiene gran cantidad de helpers para facilitar el desarrollo. El más común es OwinMiddleware, con el cual puedes crear tu propio componente middleware heredando de él. Aquí podemos ver un ejemplo:

 1:  
 2: public class LoggerMiddleware : OwinMiddleware
 3: {
 4: private readonly ILog _logger;
 5: public LoggerMiddleware(OwinMiddleware next, ILog logger) : base(next)
 6: {
 7: _logger = logger;
 8: }
 9: public override async Task Invoke(IOwinContext context)
 10: {
 11: _logger.LogInfo("Middleware begin");
 12: await this.Next.Invoke(context);
 13: _logger.LogInfo("Middleware end");
 14: }
 15: }

 

Este middleware se puede añadir fácilmente en la inicialización del pipeline de OWIN:

 1:  
 2: public class Startup
 3: {
 4: public void Configuration(IAppBuilder app)
 5: {
 6: app.Use<LoggerMiddleware>(new TraceLogger());
 7: }
 8: }

 

Aquí también es donde registraríamos los diferentes componentes que queramos utilizar en el pipeline, además de los frameworks como WebApi o SignalR. La clase Startup se llama así por convención y tiene que estar en la raíz del proyecto, aunque lo podemos cambiar en la configuración de dicho proyecto.

Applications

Esta capa no ha cambiado ya que, como hemos comentado, OWIN y Katana no son un nuevo modelo de programación; simplemente desacoplan los servidores de los frameworks. Por lo que para realizar nuestras aplicaciones podremos seguir utilizando todo lo que ya sabíamos.

Para acabar

Como hemos visto, OWIN y Katana son un gran cambio para ASP.NET. Pero éstos no nos hacen tener que aprender todo de nuevo, sino que han dividido al máximo las diferentes capas para poder elegir en cada momento el componente que más nos interese en cada una de estas. Esto nos da un control completo sobre toda la pila de nuestra aplicación.

Carlos Carrillo Boj (3lcarry)