Katana: Cortando el framework

Si eres desarrollador en tecnologías Microsoft y especialmente desarrollador web, acúerdate de esas dos palabras: Proyecto Katana. Este proyecto representa el futuro a corto plazo de todas las tecnologías de desarrollo web de Microsoft y, no me cabe duda de ello, el futuro a medio plazo del propio .NET.

No dejes que esa introducción te confunda: Katana no es una nueva tecnología, ni una nueva plataforma, ni un lenguaje nuevo, ni tan siquiera realmente una API nueva. Es simplemente un cambio de filosofía. Es como Microsoft entiende que debe ser la evolución de ASP.NET para poder seguir dando respuestas al, cada vez más, cambiante mundo del desarrollo de aplicaciones web. Katana se circumscribe sólo a ASP.NET, pero no me cabe duda de que al final todo .NET irá en la misma dirección.

¿Y qué dirección es esa? Para saber donde vamos hemos de saber de donde venimos…

Hace 12 años (año arriba, año abajo)…

Microsoft sacó .NET y con él una “nueva versión” de ASP. Conocida primero como ASP+, luego ASPX para adoptar la terminología de ASP.NET al final. La intención de MS con ASP.NET era doble. Por un lado que los desarrolladores de “toda la vida” en tecnologías web de Microsoft (que en un 95% usaban ASP) empezaran a usar la nueva versión. Pero también que esa nueva versión pudiese ser atractiva y usable rápidamente por la gran mayoría de los desarrolladores que usaban tecnologías Microsoft, lo que era equivalente a decir VB6 en aquella época.

Es este segundo objetivo el que hace que Microsoft apueste por el modelo de Webforms para que “desarrollar para web sea igual a hacerlo para escritorio”. No olvides eso: el assembly principal de ASP.NET (System.Web.dll) está totalmente acoplado a IIS.

ASP.NET se integró dentro de lo que se pasó a llamar (y se llama) .NET Framework: Un framework monolítico del que ASP.NET era tan solo una parte y que se actualizaba cada cierto tiempo (entre 1 y 2 años y pico), básicamente cada vez que había una nueva versión de Visual Studio.

En medio de todo este tiempo varios cambios en el paradigma del desarrollo web a los que ASP.NET no podía responder con prontitud por su modelo de distribución y actualización, hicieron que alguien en Redmond se diese cuenta de que alguna cosa se tenía que hacer.

Hace 4 años (año arriba, año abajo)…

Veía la luz ASP.NET MVC. Era un nuevo framework, basado en ASP.NET que venía a complementar a Webforms. Desde este momento había dos APIs para desarrollar aplicaciones web en tecnologías Microsoft: Webforms y ASP.NET MVC. Ambas funcionaban bajo toda la plataforma de ASP.NET (y el .NET Framework subyacente que era el 3.5SP1 por aquel entonces).

Pero la novedad principal de ASP.NET MVC no era que fuese una nueva API si no el hecho de que se distribuía independientemente del .NET Framework. Era la primera vez que una API de Microsoft veía la luz fuera del “paraguas” aglutinador del .NET Framework. Esto suponía la posibilidad para Microsoft de evolucionar ASP.NET MVC mucho más ágilmente. Para que te hagas una idea: junto con el .NET Framework 4, salió ASP.NET MVC2. Después salieron MVC3 y MVC4 sin que hubiese ninguna versión más del Framework, hasta que salió Visual Studio 2012 y el .NET Framework 4.5.

ASP.NET MVC marcaba una nueva tendencia (que luego ha seguido Entity Framework) en donde se intenta huir de un framework monolítico para pasar a otro “framework” formado por varios módulos que se actualizan de forma separada.

Pero recuerda: ASP.NET MVC seguía funcionando bajo System.Web.dll y por lo tanto estaba “atada” a IIS (y también al .NET Framework, ya que System.Web.dll forma parte del .NET Framework).

Hace tres año (año arriba, año abajo)…

La aparición de ASP.NET MVC3 supuso otro hito importante en esta historia, no por MVC3 en si mismo, si no por un componente que le acompañaba: NuPack.

NuPack, luego llamado NuGet, era una extensión de Visual Studio que permitía (permite) instalar paquetes de forma muy sencilla. Estos paquetes pueden ser cualquier cosa, usualmente librerías de terceros (pero también templates de proyectos, etc). Era como tener PEAR pero en .NET.

No sé si cuando salió alguien fue consciente de la importancia que adquiriría NuGet para el desarrollo en tecnologías Microsoft…

Hace un año (año arriba, año abajo)…

Salió ASP.NET MVC4 y el hito final de esta pequeña historia. No por MVC4 si no por un componente que le acompañaba (otra vez) y que parecía que formaba parte de MVC4 cuando realmente poco tenía que ver con ella: WebApi.

La gran novedad de WebApi es que no tenía ninguna dependencia contra System.Web.dll. Es decir, WebApi podía evolucionar de forma completamente independiente de ASP.NET (eso no era del todo cierto en ASP.NET MVC aunque se distribuyera via NuGet) y además al no depender de System.Web.dll implicaba que no se estaba atado a IIS por lo que se podía hospedar WebApi en otros procesos (p. ej. una aplicación de línea de comandos).

La idea de WebApi es pues la idea final: una parte del framework sin dependencias externas, que evoluciona a su propio ritmo y que se distribuye automáticamente via NuGet.

Hoy (día arriba, día abajo)…

El proyecto Katana es quien ha tomado el relevo de esta filosofía que se inaugura con WebApi. La idea del proyecto Katana es tener un conjunto de componentes cada uno de los cuales pueda evolucionar independientemente y por supuesto sin ninguna dependencia a System.Web.dll.

Katana es un conjunto de componentes, implementados por Microsoft y que son componentes OWIN. Estos componentes van desde hosts, servidores hasta componentes funcionales (p. ej. hay una versión de SignalR “katanizada” o la propia WebApi). Recuerda la clave: cada componente podrá evolucionar a su propio ritmo y podrá ser sustuído por otro en cualquier momento. Olvídate de decir que “esta web es ASP.NET 3.5” y que todo el mundo sepa que es esto. Tu web serà una combinación de distintos módulos, cada uno con su propia versión. Desde NuGet seleccionarás cual de los módulos quieres usar (p.ej. un nuevo módulo de autenticación).

Y a futuro… extiende esta visión a todo el framework. Cierra los ojos e imagina que ya no hay un .NET Framework 6 ó 7 o el que toque y que en su lugar tu proyecto usará System.Collections en una versión y también System.Net y el entity framework que toque y nada más. Incluso, porque no, seleccionar que CLR (o CLRs) quieres atacar. Yo al menos lo veo así (aunque desde que predije el fracaso del iPad tengo claro que como pitoniso no me ganaré la vida).

OWIN

Antes he mencionado que Katana es (será) básicamente un conjunto de componentes OWIN y me he quedado tan ancho. Pero… ¿qué es básicamente OWIN? Pues inspirándose de nuevo en la comunidad de Ruby (en concreto en Rack) la comunidad de .NET ha creado una abstracción entre el servidor web y los componentes del framework que se use. La idea es que:

  1. Se puedan (y usar) crear nuevos componentes de forma sencilla y fácil
  2. Sea más sencillo portar aplicaciones entre hosts.

No entraré en detalles sobre OWIN ahora (lo dejo para un post siguiente) pero básicamente sus puntos clave son:

  1. El servidor Web OWIN es el encargado de rellenar los datos OWIN (environment según la especificación) a partir de la petición. A la práctica estos datos son un diccionario (IDictionary<string,object>). Las cadenas usadas como claves están definidas en la propia especificación de OWIN.
  2. Los componentes deben implementar el application delegate (AppFunc). Básicamente la idea es que los componentes reciben el diccionario anterior y devuelven una Task con la definición de la tarea a realizar.

Estos dos puntos parecen una chorrada, pero quédate con un par de ideas al respecto:

  • OWIN está diseñado con visos de ser asíncrono (de ahí que los componentes devuelvan un Task). La idea es parecida a la de nodejs: procesar asíncronamente aumenta el rendimiento en aquellas peticiones que básicamente dependen de E/S que son la mayoría.
  • Los componentes OWIN son encadenables de forma sencilla.

Conclusión

El modelo de un framework monolítico podía ser válido hace, pongamos, siete años, pero cada vez es necesario poder evolucionar más rápidamente.

Evolución rápida implica que sea al margen del .NET Framework. ASP.NET MVC abrió el camino y el proyecto Katana es la culminación de esa idea: tener todas las APIs y componentes de ASP.NET (y algunos más) pero sin dependencias contra System.Web.dll (y por lo tanto con el .NET Framework y con IIS). Para la implementación de Katana, Microsoft se ha apoyado en OWIN, una iniciativa de la comunidad .NET, que define una interfaz entre servidores web y frameworks de desarrollo web modulares.

En próximos posts iremos ampliando la información sobre OWIN y Katana.

Saludos!

9 comentarios sobre “Katana: Cortando el framework”

  1. Todo lo que cuentas parece maravilloso, pero solo lo parece. Una de las cosas que siempre me han gustado de .Net es que te marca el camino de cómo hacer las cosas. Y puede parecer esto una actitud conformista, pero en la práctica te quita muchos dolores de cabeza. Estoy cansado de ver como se adoptan tecnologías sin ninguna experiencia sobre ellas, las cuales no resultan tan buenas como se prometían. O como chavales que salen como Miuras de la universidad, con muchas ganas y poca cabeza, insisten utilizar tecnologías por el único afán de ponerlo en el curriculum (lo que se llama arquitectura basada en curriculum). .Net siempre ha sido un framework de muy alta calidad y si no ha sido lo mejor en cada momento ha estado muy cerca de serlo. Siempre ha marcado una apuesta segura. Así que ramificarlo va a suponer más dolores de cabezas, discusiones, toma de decisiones a ciegas, …

  2. Yo aún no lo pillo. Pareciera que ligarse al .NET Framework y a System.Web.dll fuese malo y mal visto socialmente :-)

    Evolucionarlo más rápidamente…como diche @andrechi, sin cabeza, sin alta calidad, sin mesura…

    Esperamos más artículos para aclararnos. Gracias!

  3. No tengo nada claro que extender la idea de Katana/Owin al framework sea algo que se haya dejado entrever por ningún lado, por lo menos yo no lo he visto ni lo entiendo así… De hecho, en lo que comentas hay alguna que otra inconsistencia.. el CLR no es solo librería es también características de lenguaje, por lo tanto, algunos de los escenarios que planteas no me parecen a priori muy realistas…

    saludos
    unai

  4. @unai
    No, no es algo que se haya dejado entrever por parte de Microsoft. Es simplemente lo que yo creo que ocurrirá, una paja mental o un deseo mío, llámalo como quieras. Quizá no con el CLR (y parte de la BCL quizá), pero me atrevo a pensar que con el framework sí. De hecho hoy en día MS ya está sacando librerías que complementan el framework a través de NuGet y no me extrañaría que en un futuro la propia BCL (o parte de ella) se “fragmentase” y distribuyese por separado (y porque no, otras APIs del framework como WPF o WCF). En el CLR puro es cierto que hay temas de características de lenguajes que se deberían tratar y quizá no sea tan realista (o quizá no lo sea en absoluto).

    @Kiquenet
    No es que sea malo per se. Pero actualmente .NET Framework se actualiza cada demasiado tiempo. ¿Porque hay que esperar a una nueva versión entera del framework (con su nueva versión de WPF, de Winforms, de BCL, de WCF) para tener una nueva versión de webforms? No estaría bien que pudiese evolucionar aparte? Actualmente MVC, WebApi y EF lo hacen y no les va nada mal. Releases ágiles permiten adaptarse más rápidamente a las necesidades de los clientes (== desarrolladores).
    Lo de no estar atado a System.Web.dll es por un lado porque esto te ata (en ciertos aspectos) a una versión concreta del Framework y por el hecho de que System.Web.dll está también muy atada al propio IIS.

    @andrechi
    No es tanto una “ramificación” si no una evolución por separado de todos sus componentes (ojo, a futuro y según visión personal, que quede claro. De momento esto afecta tan solo a EF, MVC y WebApi). El camino sigue igual de marcado, pero el framework NO evoluciona como un todo si no que evoluciona por separado. Es posible como bien dice @unai que siempre haya una parte que deba ir evolucionando como “base” (CLR + algo más). Pero a partir de aquí todo podrían (insisto que eso es una visión personal) librerías desplegadas (y actualizables) a través de NuGet.

    Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *