Reaprendendo a programar com ASP.NET: Welcome Katana

Na semana passada, impulsionado pelos vários anúncios realizados no TechEd North America em relação ao futuro do ASP.NET, iniciei a escrita desta nova série. Como mencionei no post anterior, o objetivo principal da série é apresentar de forma um pouco mais aprofundada (e prática), os conceitos que norteiam o novo modelo.

No primeiro post da série, apresentei o OWIN, especificação que serve como base para o desenvolvimento do novo modelo proposto pelo ASP.NET vNext. Lá explicamos que o OWIN, é uma especificação que independente da tecnologia associada. Hoje, falaremos do Katana, o conglomerado de tecnologias OWIN para .NET e claro, criaremos juntos um exemplo que explica seu funcionamento. Let’s go?!

O que é Katana?

Para que você possa construir o conceito de forma concreta, vamos primeiro definir o que é Katana e sua função, para só então, em um momento posterior, entender os aspectos que motivaram sua criação. De forma resumida, Katana é o container de elementos (infra estrutura de servidor, host, binders, etc.) .NET baseado em OWIN que suporta a execução de aplicações web (no modelo vNext). Katana é open source, entretanto, é mantido pela Microsoft.

É claro que quando falamos em Katana, é inevitável (pelo menos a meu ver) não tentarmos realizar uma comparação imediata com Node.js (eu ousaria dizer até, que Katana foi fortemente baseado no modelo do Node). Essa comparação se deve ao modelo funcional do Node, que possui como uma de suas principais características, a facilidade em “subir” novo web server para “rodar” uma aplicação baseada em Javascript.

Já que tocamos neste ponto (Node x Katana), é importante notar a principal diferença em relação aos modelos. Javascript, como você deve saber, é uma linguagem interpretada enquanto  as linguagens suportadas por .NET, são pseudo-compiladas (ok, sei que há controvérsias em relação a isso, desta forma, você pode assumir que são compiladas) e é aqui que entra o Roslyn. Mas isso é tema para um outro post no futuro. Isso quer dizer que, muito embora esta não seja a única maneira de se construir uma aplicação para o Katana, uma boa maneira de se criar algo neste sentido, é utilizar o Visual Studio (claro!) com projetos ASP.NET.

Em termos de ferramental, o NuGet assume um papel de suma importância nos projetos ASP.NET: o de tornar a aplicação flexível (lembre-se, aplicações baseadas no System.Web ainda estarão disponíveis). Note, o que fará de seu projeto ASP.NET (One Asp.Net) algo ajustável ao Katana (OWIN), será a implantação de um pacote disponível no repositório, a saber:

• Microsoft.Owin.Host.SystemWeb

Este pacote será o responsável por implantar todas as dependências do Katana, incluindo Microsoft.Owin, que traz todos os recursos de “infraestrutura” relacionados. Para instalar é simples, basta que, no Visual Studio (no “Manage Package Console“), você digite a linha abaixo.

• install-package Microsoft.Owin.Host.SystemWeb

Arquitetura do Katana

Outro aspecto importante a ter em mente aqui, é a arquitetura interna do Katana. Se você está lembrado do primeiro post desta série, lembrará que OWIN padroniza o tratamento das requests através com a quebra em camadas conceituais, das operações a serem realizadas. Em tempo, são camadas conceituais do OWIN: server, web framework, web application, middleware e host.

Katana é baseado no modelo OWIN, logo, segue o mesmo padrão de arquitetura, com a diferença de que a camada “web framework” já é padronizada para .NET. Veja o esquema funcional através da Figura 1.

Figura 1: Divisão lógica do Katana (fonte: .NET Curry)

A ideia da arquitetura do Katana é que estas camadas possam ser personalizadas de forma simplificada, de modo que uma alteração estrutural na aplicação não necessariamente resulte no processo de recompilação da mesma. Cada uma destas camadas gerenciam partes específicas das requisições HTTP. A seguir, tento ampliar a visão sobre cada uma destas camadas.

Host

O host é o elemento mais primário da arquitetura OWIN e como tal, possui função vital na arquitetura do Katana. Em um processo mental de associação, podemos dizer que o host está para o Katana assim como o processador está para a arquitetura de Von Neumann. Podemos dizer que esta é a camada de articulação, o “cérebro” do container.

De forma resumida, o são as atribuições principais do host:

• Gerenciar os processos paralelos dentro do container;
• Realizar o gerenciamento dos resultados gerados, organizar o pipeline de processamento e alocar os servidores (servers) específicos para executar as tarefas retornadas;

Até este momento, existem três (este número pode crescer) opções disponíveis para “hostear” aplicações provenientes do Katana: IIS/ASP.NET, Host personalizado e OwinHost. Veremos de forma detalhada, cada um deles.

IIS/ASP.NET

Os famosos HttpModule e HttpHandler são fundamentais aqui. Neste caso, Katana estende o pipeline de execução do IIS com ASP.NET para que seja possível a ele (IIS) executar aplicações OWIN. Não preciso nem dizer que a base tecnológica aqui é ASP.NET, certo?

No nível de aplicação, deve ser instalado na aplicação, o pacote “Microsoft.AspNet.Host.SystemWeb“. Neste caso, perde-se o conceito de flexibilidade, pois SystemWeb não permite que as camadas mencionadas anteriormente neste mesmo post, sejam sobrepostas por novas e personalizadas implementações.

Custom Host (Host personalizado)

A ideia aqui é que seja possível ao usuário realizar seu próprio host para a aplicação, de forma semelhante ao que é possível fazer quando utilizamos Web API. Os exemplos disponibilizados no próprio site que apresenta a especificação do Katana, deixam esta ideia clara. Para fechar o ciclo de ideias, os disponibilizamos a seguir.

Listagem 1: O modelo de self host do Web API

A principal característica do código apresentado acima, é o fato de que tanto a configuração do pipeline de processamento de requisições quanto a chamada do server, ocorrem em um mesmo ambiente e isso prejudica o conceito de portabilidade. A Listagem 2 apresenta o modelo de self host proposto pelo Katana.

static void Main(string[] args)
{
    const string baseUrl = "http://localhost:5000/";

    using (WebApplication.Start<Startup>(new StartOptions { Url = baseUrl })) 
    {
        Console.WriteLine("Press Enter to quit.");
        Console.ReadKey();
    }
}

Listagem 2: O modelo self host proposto pelo Katana

A diferença entre as abordagens é clara. Note, o código que inicia as atividades do servidor é apresentado na Listagem 2, enquanto aquele que configura o pipeline está localizado em uma classe Startup (veja a Listagem 3). A classe Startup utiliza a interface IAppBuilder. Ela é de suma importância para que a camada de middleware possa funcionar corretamente.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();
        config.Routes.MapHttpRoute("default", "{controller}");
        app.UseWebApi(config);
    }
}

Listagem 3: A especificação da classe Startup

OwinHost.exe

Outro modelo disponível para “hostear” aplicações OWIN é o OwinHost.exe. Como o próprio nome sugere, trata-se de um executável pré-construído e disponibilizado no pacote Microsoft.Owin. Sua função? Iniciar o host e executar a aplicação. Este componente utiliza por padrão, o objeto HttpListener para “chamar” o host e na sequência, procurar a classe de startup. Como pré requisito, OwinHost.exe deve estar no diretório root do projeto.

Existem ainda alguns parâmetros que você poderá passar para o executor na linha de comando, para que você possa conseguir certo nível de personalização para o host (veja a Figura 2).

Figura 2: Opções disponíveis para chamar o executor OwinHost.exe

Server

Se o host é o cérebro por traz do Katana, podemos dizer que o server é o coração. Isso porque enquanto o primeiro é o responsável por “subir” o servidor e articular o pipeline de execução do mesmo, o segundo tem a responsabilidade de tratar as requisições e enviá-las ao pipeline de execução da aplicação, abrir os sockets de rede, dentre outras atribuições da mesma natureza.

Hoje, encontram-se disponíveis duas implementações de servidores:

• Microsoft.Owin.Host.SystemWeb

• Microsoft.Owin.Host.HttpListener

A primeira, como já mencionamos anteriormente neste post, estende o pipeline de execução do IIS (através dos componentes HttpModule e HttpHandler) já a segunda, utiliza (como o próprio nome sugere) a classe HttpListener, nativa na .NET framework. Aliás, é importante mencionar neste ponto que esta implementação, é aquela utilizada internamente pelo OwinHost.exe.

Middleware

Como já mencionamos anteriormente neste post, uma das funções do server é enviar as requisições realizadas pelo cliente para o pipeline de execução da aplicação que, como já sabemos, é definida na classe startup. Este pipeline de execução é o que a Microsoft chama de middleware. Aqui encontra-se de fato a aplicação OWIN.

Existe outro aspecto importante aqui. É no middleware que o delegate do qual falamos no primeiro post da série (Func<IDictionary<string, object>, Task>) ganha efeito prático. Ele é o responsável por tornar o pipeline “chamável” a qualquer momento. Para tornar mais simples o processo de composição dos componentes de middleware, a Microsoft disponibiliza dentre muitas implementações e helpers, um template para realizar tal operação. Observe o código apresentado pela Listagem 4.

Listagem 4: Um exemplo de composição de pipeline de pipeline

Como você deve ter notado, a classe ajudadora neste caso, é OwinMiddleware. O código é bem simples. Após herdar da classe OwinMiddleware, temos no interior da classe LoggerMiddleware a implementação de um construtor, que recebe como um de seus parâmetros, a referência para o próximo middleware no pipeline para só então, passá-lo ao construtor base.

O método Invoke é aquele que permitirá ao pipeline ser invocado em tempo de execução. Em sua implementação (que é uma sobrecarga), Invoke recebe um objeto IOwinContext, que nada mais é do que um tipo bem definido (fortemente tipado) para acessar requests, respostas e demais informações do ambiente.

Para adicionar a classe middleware recém criada no pipeline, é simples. Veja o exemplo apresentado pela Listagem 5.

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Use<LoggerMiddleware>(new TraceLogger());

   }
}

Listagem 5: Adicionando o middleware recém criado ao pipeline

Applications

Sob o ponto de vista da aplicação, as mudanças não são tão significativas assim. Aliás, a Microsoft faz questão de dizer que não se trata de um novo modelo de programação e sim uma mudança no modelo atual, que tem o objetivo de desacoplar a aplicação da infra estrutura de servidores de hospedagem.

Por exemplo, se um aplicação baseada em Web API for construída, quase nada muda no processo de desenvolvimento. O mesmo set de tecnologias (ASP.NET Web API) será utilizado. Isso (desenvolvimento) ocorrerá de forma independente de haver ou não um pipeline OWIN que utiliza componentes do Katana. Para não dizer que nada muda no processo de desenvolvimento, no modelo OWIN, estará disponível para o desenvolvedor a classe de inicialização (startup) para que ele (dev) possa compor o pipeline de execução.

As motivações da Microsoft para criar o Katana

Agora que você já sabe o que é e para o que serve o Katana, podemos falar um pouco sobre as motivações que levaram o time do ASP.NET a partir para este modelo de desenvolvimento “mais desacoplado”.

O ponto de partida para falar sobre as motivações da Microsoft para criar o Katana, é sem dúvida, entender os momentos anterior e atual da internet. Saímos de um modelo estático (apenas HTML e Javascript nas páginas), passamos por um modelo dinâmico (bancos de dados e linguagens de server side eram os protagonistas aqui) e chegamos no momento em que estamos hoje.

É desnecessário dizer que, no início de tudo, tanto o número de aplicações quanto o número de usuários (e portanto de requisições aos servidores web) era quase que infinitamente menor do que nos dias atuais. Apresento a seguir alguns números que corroboram esta afirmação:

• Número de usuários na internet (no mundo) em 1996: 36 milhões
• Número de websites na internet (no mundo) em 1996: 100.000
• Número de usuários na internet (no mundo) em 2002: 570 milhões
• Número de websites na internet (no mundo) em 2002: 3 milhões
• Tempo médio gasto nestes sites em 2002: 46 minutos
• Número de usuários na internet (no mundo) em 2012: 2.27 bilhões
• Número de websites na internet (no mundo) em 2012: 555 milhões
• Tempo médio gasto nestes sites em 2012: 4 horas

Os números falam por sí só. Hoje a internet passa de 3 bilhões de usuários, ficando ainda mais tempo gerando requisições e mais requisições. É evidente portanto, que um modelo de aplicação web que atendia as demandas há alguns anos é inadequado para atender as demandas de hoje. Aspectos como: uso de memória dos servidores web, processamento, escalabilidade e também, portabilidade tornaram-se cruciais para as aplicações web modernas.

Por estarem no topo da cadeia no mercado de tecnologia, empresas como a Microsoft, Google, Oracle, etc., acabam se tornando as grandes provedoras de tecnologias e metodologias que possibilitam aos usuários (em nosso contexto, desenvolvedores web), criarem aplicações atuais e robustas.

Falando especificamente sobre a Microsoft, no cenário de desenvolvimento de aplicações dinâmicas para a web, o popularmente conhecido ASP clássico, foi o primeiro esforço da empresa no sentido de proporcionar poder aos desenvolvedores os recursos necessários para atender as demandas do mercado na época de seu lançamento. Em seguida (2002), tido até hoje como um grande avanço (e de fato foi), veio a famosa plataforma ASP.NET, que introduziu os amplamente utilizados, web forms. A evolução natural? ASP.NET MVC, criado para atender demandas de uma web onde a arquitetura das aplicações importava, gerando impacto direto na estrutura interna da aplicação, o que fatalmente implica em uma aplicação mais robusta, segura e por que não, performática.

Muito embora os avanços com as tecnologias mencionadas anteriormente tenham sido inegáveis, haviam ainda dois pequenos “problemas”:

1. Dependência da biblioteca System.Web: A biblioteca System.Web é grande e complexa. Hoje, para que seja possível criar qualquer aplicação utilizando ASP.NET System.Web é pré-requisito. O problema é que trata-se de uma biblioteca grande, complexa, repleta de recursos mas que não necessariamente são utilizados para a aplicação. De forma, o time se perguntou: faz sentido carregar uma biblioteca tão pesada para utilizar apenas 20 ou 30% dela?
   
2. Dependência direta do IIS: O IIS é uma ferramenta poderosa mas, novamente fica a pergunta: preciso realmente de todos os recursos do container para executar minha aplicação? E mais, e se seu quiser sobrescrever alguma rotina do container para otimizar minha aplicação. Como fica? Com o Katana, o time do ASP.NET dá uma resposta a estas perguntas.

Enfim, o modelo OWIN e o projeto Katana são respostas da Microsoft para as novas demandas do mercado de desenvolvimento web. O objetivo final, é conseguir entregar uma aplicação web que mantenha a robustez proporcionada pela plataforma .NET mas com mais granularidade, possibilitando flexibilizar o servidor de execução, etc.

É muita informação para um post só. Desta forma, não quero me alongar mais aqui. Em nosso próximo “encontro”, agora que já possuímos os conhecimentos necessários, criaremos juntos uma aplicação baseada em OWIN e Katana. Ao visualizar a prática, tudo ficará mais claro para você.

Um forte abraço. Até a próxima!