OWIN (Open Web Interface for .NET) es una nueva especificación abierta definida por miembros del propio grupo de Asp.Net, cuya finalidad es desacoplar la dependencia entre el host de la aplicación web, y la propia aplicación. ¿Qué ha llevado a la necesidad de la especificación OWIN? Para responder a la pregunta, es necesario hacer una pequeña retrospección a la evolución de la plataforma Asp.Net.
Un poco de historia de Asp.Net
En el año 2002 nace Asp.Net, integrada en la primera versión de .Net Framework. Esta nueva tecnología mantuvo gran similitud con su antecesor, el clásico ASP, para no provocar un cambio completo en la forma en la que los desarrolladores construían sus aplicaciones. Además optó por el camino de lo que llamaron WebForms, formularios que se construían de una manera muy similar a como se hacía para aplicaciones escritorio (WinForms), y así atraer a los desarrolladores desktop hacia la web.
Durante varios años Asp.Net fue evolucionando de manera paralela a como lo hacía el propio .Net, ya que estaba completamente atado a éste por ser un framework monolítico. Todo Asp.Net se apoyaba en System.Web, que es parte del framework.
Entre 2007 y 2008 surge Asp.Net MVC, un framework de desarrollo web no orientado a Webforms, sino utilizando la arquitectura Modelo-Vista-Controlador. Además del cambio de filosofía que esto provocó, este framework no se incluía en el monolito .Net Framework, lo que permitía una evolución completamente independiente. Pero su ejecución seguía dependiendo de System.Web, por lo que la única manera de alojar una aplicación web basada en tecnología Microsoft, era a través de su servidor web, Internet Information Services (IIS). En este momento se empieza a ver la problemática que provoca todo el acoplamiento existente entre la aplicación web, .Net framework, y el host de aplicaciones.
Junto con la liberación de MVC4 surge Web API, una nueva API de desarrollo de aplicaciones web, pero esta vez sí, sin ningún tipo de dependencia sobre System.Web.dll. Y para marcar más esta independencia, se incluye un self-host para hospedar estas nuevas aplicaciones sin necesidad de IIS.
El nacimiento del Open Web Interface for .NET y Katana
Así, con todo lo aprendido durante la evolución de Asp.Net, y basándose en la filosofía de Web API, nace OWIN para crear la mayor independencia posible entre los componentes de un desarrollo web. Por tanto, la arquitectura para una aplicación OWIN queda de la siguiente manera:
Como se ha citado anteriormente, OWIN no es más que una especificación, y es aquí donde entra Katana, la implementación (una de ellas) de este estándar, que ofrece toda la funcionalidad de OWIN mediante Clases y Helpers para el manejo de peticiones y creación de respuestas HTTP.
Creando una primera aplicación
Una vez vista la teoría y con la nueva arquitectura en mente, ya se puede comenzar con el desarrollo de la aplicación.
1. Se crea un nuevo proyecto con la plantilla de aplicación Asp.Net vacía.
2. Mediante el gestor de paquetes nuget, se instalan los paquetes de Katana en el proyecto, todos pertenecientes al namespace OWIN:
3. Se agrega una nueva clase al proyecto con nombre Startup.cs. En ésta, se crea un método void de nombre Configuration, y un parámetro de tipo IAppBuilder (del namespace Owin). En el paquete Owin.Diagnostics se incluye un método de extensión llamado UseWelcomePage, creado especialmente para comprobar el correcto funcionamiento del proyecto.
4. Una vez compilado el proyecto, al ejecutarse debería aparecer en el navegador la página Welcome.
Como se puede observar hasta el momento, el objeto app del método Configuration contiene todo el contexto necesario de la petición y la respuesta HTTP, que son los parámetros que los componentes middleware se encargarán de utilizar. En este primer ejemplo, el middleware WelcomePage se encarga de escribir y enviar la respuesta directamente, para cualquier petición que se realice. Indagando un poco más en el método, se ve cómo es posible utilizar este middleware para un path concreto, es decir, solo respondiendo a las peticiones que se realicen a un path concreto.
Ahora la página welcome solo se mostrará para peticiones realizadas al path /Welcome, mientras que para cualquier otra se mostrará un error 403. ¿Por qué ocurre esto? Básicamente porque se ha elegido IIS como servidor, y en el caso de que ningún middleware gestione la petición, ésta llegará a IIS, y realizará el comportamiento que tenga asignado, en este caso mostrar el error de listado de directorio no permitido.
Ampliando la aplicación con la creación de nuevos middleware
Evidentemente lo útil de los componentes middleware es crearlos según las necesidades de la aplicación, pudiendo delegar diferentes acciones a cada uno de ellos, como estadísticas, autenticación y respuesta final. De una manera rápida, se pueden crear middleware apoyándose en expresiones lambda (anónimas) pudiendo utilizar el contexto para analizar la petición y crear la respuesta, como se puede ver en el ejemplo:
Aunque para un primer acercamiento es suficiente, para la creación de componentes middleware existe una clase abstracta llamada OwinMiddleware, que se puede implementar con la lógica que se le quiera otorgar. En este sencillo ejemplo, se van a crear tres componentes que se encargarán de crear la respuesta una vez estén anidados en el pipeline.
Una vez definidos los middleware propios, es suficiente con llamarlos (en el orden correcto) desde el método Configuration utilizando el método genérico Use tantas veces como middleware se necesiten.
La respuesta desde el navegador a cualquier recurso de la aplicación debería ser como se muestra en la imagen:
Y usar Latch en Asp.NET
Katana ofrece mucha más funcionalidad de la que se ha visto, pero esto es un pequeño acercamiento al nuevo rumbo por el que Asp.Net quiere caminar, que además también se integra perfectamente con Latch. El uso de middlewares permite modularizar la aplicación web y minimizar las dependencias entre módulos, por lo que el reemplazo de una funcionalidad concreta solo supone el rediseño o reimplementación de un middleware concreto. ¿Qué tal un middleware cuya única finalidad sea comunicarse con el servicio Latch, una vez comprobada la autenticación?
Esto no sería nada difícil de realizar, y habría que hacer un uso análogo al que se describe en este documento de 16 páginas que explica cómo integrar con el SDK de .Net y/o el plugin de Latch para el .Net Login en cualquier aplicación Asp.Net que vayas a realizar.
Autor: Ioseba Palop
Software Engineer en Eleven Paths
Un poco de historia de Asp.Net
En el año 2002 nace Asp.Net, integrada en la primera versión de .Net Framework. Esta nueva tecnología mantuvo gran similitud con su antecesor, el clásico ASP, para no provocar un cambio completo en la forma en la que los desarrolladores construían sus aplicaciones. Además optó por el camino de lo que llamaron WebForms, formularios que se construían de una manera muy similar a como se hacía para aplicaciones escritorio (WinForms), y así atraer a los desarrolladores desktop hacia la web.
Durante varios años Asp.Net fue evolucionando de manera paralela a como lo hacía el propio .Net, ya que estaba completamente atado a éste por ser un framework monolítico. Todo Asp.Net se apoyaba en System.Web, que es parte del framework.
Entre 2007 y 2008 surge Asp.Net MVC, un framework de desarrollo web no orientado a Webforms, sino utilizando la arquitectura Modelo-Vista-Controlador. Además del cambio de filosofía que esto provocó, este framework no se incluía en el monolito .Net Framework, lo que permitía una evolución completamente independiente. Pero su ejecución seguía dependiendo de System.Web, por lo que la única manera de alojar una aplicación web basada en tecnología Microsoft, era a través de su servidor web, Internet Information Services (IIS). En este momento se empieza a ver la problemática que provoca todo el acoplamiento existente entre la aplicación web, .Net framework, y el host de aplicaciones.
Junto con la liberación de MVC4 surge Web API, una nueva API de desarrollo de aplicaciones web, pero esta vez sí, sin ningún tipo de dependencia sobre System.Web.dll. Y para marcar más esta independencia, se incluye un self-host para hospedar estas nuevas aplicaciones sin necesidad de IIS.
El nacimiento del Open Web Interface for .NET y Katana
Así, con todo lo aprendido durante la evolución de Asp.Net, y basándose en la filosofía de Web API, nace OWIN para crear la mayor independencia posible entre los componentes de un desarrollo web. Por tanto, la arquitectura para una aplicación OWIN queda de la siguiente manera:
• Host: Proceso del sistema que recibe toda la comunicación Http. (IIS, servicio Windows….)• Server: Implementación del protocolo Http que se encuentra alojado en el Host. Las peticiones son gestionadas según marca la definición OWIN.• Middleware: Son los componentes que reciben las peticiones del server con el formato OWIN para procesar (o no) una respuesta. Estos componentes se ejecutan de manera encadenada en una pipeline, y evidentemente, tienen funcionalidades diferentes. A cada componente se le dotará de una funcionalidad concreta, pudiendo “romper” la cadena de ejecución para retornar un valor concreto al cliente en el caso de que así se desee, o continuar la ejecución hacia el siguiente componente.• Application: La propia aplicación web, construida apoyándose en los frameworks que se consideren oportunos (y compatibles con la definición Owin), como por ejemplo MVC o Web API.
 |
| Figura 1: Componentes de la arquitectura OWIN |
Como se ha citado anteriormente, OWIN no es más que una especificación, y es aquí donde entra Katana, la implementación (una de ellas) de este estándar, que ofrece toda la funcionalidad de OWIN mediante Clases y Helpers para el manejo de peticiones y creación de respuestas HTTP.
Creando una primera aplicación
Una vez vista la teoría y con la nueva arquitectura en mente, ya se puede comenzar con el desarrollo de la aplicación.
1. Se crea un nuevo proyecto con la plantilla de aplicación Asp.Net vacía.
 |
| Figura 2: Creación de una aplicación Asp.NET vacia |
2. Mediante el gestor de paquetes nuget, se instalan los paquetes de Katana en el proyecto, todos pertenecientes al namespace OWIN:
• Install-Package Microsoft.Owin.Host.SystemWeb
• Install-Package Owin.Extensions
• Install-Package Microsoft.Owin.Diagnostics
 |
| Figura 3: Instalación de los paquetes de Katana con nuget |
3. Se agrega una nueva clase al proyecto con nombre Startup.cs. En ésta, se crea un método void de nombre Configuration, y un parámetro de tipo IAppBuilder (del namespace Owin). En el paquete Owin.Diagnostics se incluye un método de extensión llamado UseWelcomePage, creado especialmente para comprobar el correcto funcionamiento del proyecto.
 |
| Figura 4: Creando la clase Startup |
4. Una vez compilado el proyecto, al ejecutarse debería aparecer en el navegador la página Welcome.
 |
| Figura 5: Welcome Page |
Como se puede observar hasta el momento, el objeto app del método Configuration contiene todo el contexto necesario de la petición y la respuesta HTTP, que son los parámetros que los componentes middleware se encargarán de utilizar. En este primer ejemplo, el middleware WelcomePage se encarga de escribir y enviar la respuesta directamente, para cualquier petición que se realice. Indagando un poco más en el método, se ve cómo es posible utilizar este middleware para un path concreto, es decir, solo respondiendo a las peticiones que se realicen a un path concreto.
 |
| Figura 6: middleware para el path Welcome |
Ampliando la aplicación con la creación de nuevos middleware
Evidentemente lo útil de los componentes middleware es crearlos según las necesidades de la aplicación, pudiendo delegar diferentes acciones a cada uno de ellos, como estadísticas, autenticación y respuesta final. De una manera rápida, se pueden crear middleware apoyándose en expresiones lambda (anónimas) pudiendo utilizar el contexto para analizar la petición y crear la respuesta, como se puede ver en el ejemplo:
 |
| Figura 7: Extendiendo el middleware |
Aunque para un primer acercamiento es suficiente, para la creación de componentes middleware existe una clase abstracta llamada OwinMiddleware, que se puede implementar con la lógica que se le quiera otorgar. En este sencillo ejemplo, se van a crear tres componentes que se encargarán de crear la respuesta una vez estén anidados en el pipeline.
 |
| Figura 8: Componiendo una respuesta con varios métodos |
Una vez definidos los middleware propios, es suficiente con llamarlos (en el orden correcto) desde el método Configuration utilizando el método genérico Use tantas veces como middleware se necesiten.
 |
| Figura 9: Componiendo la respuesta con la llamada a los métodos |
La respuesta desde el navegador a cualquier recurso de la aplicación debería ser como se muestra en la imagen:
 |
| Figura 10: Respuesta obtenida |
Y usar Latch en Asp.NET
Katana ofrece mucha más funcionalidad de la que se ha visto, pero esto es un pequeño acercamiento al nuevo rumbo por el que Asp.Net quiere caminar, que además también se integra perfectamente con Latch. El uso de middlewares permite modularizar la aplicación web y minimizar las dependencias entre módulos, por lo que el reemplazo de una funcionalidad concreta solo supone el rediseño o reimplementación de un middleware concreto. ¿Qué tal un middleware cuya única finalidad sea comunicarse con el servicio Latch, una vez comprobada la autenticación?
Figura 11: Integrando latch en aplicaciones Asp.Net
Esto no sería nada difícil de realizar, y habría que hacer un uso análogo al que se describe en este documento de 16 páginas que explica cómo integrar con el SDK de .Net y/o el plugin de Latch para el .Net Login en cualquier aplicación Asp.Net que vayas a realizar.
Autor: Ioseba Palop
Software Engineer en Eleven Paths
O sea, siglos por detrás de Java...
ResponderEliminar