Microsoft KATANA Self-Host

Microsoft KATANA Self-Host

Microsoft KATANA Self-Host

Quando pensamos em customizar um host de uma aplicação web Asp.Net, logo nos vem a cabeça: Como podemos fazer todo o trabalho que o IIS faz, sem que ele exista ou sem que ele esteja instalado em uma máquina usando Windows? Respondo rapidamente a essa pergunta: usando a implementação do projeto Microsoft KATANA Self-Host! Essa implementação é tão simples, quanto a que mostrei no artigo sobre Kanta usando IIS *(aqui). A classe *Startup por exemplo, continua com a mesma codificação que apresentei no outro artigo, mas o que muda tanto, além de não utilizarmos mais um assembly monilítico, e que faz valer o uso deste tipo de Host? O que muda é que agora podemos criar nossa própria aplicação seja um Serviço Windows *(Windows Service)* ou uma aplicação Console (Console Application) utilizando o mesmo pipeline do Owin em uma estrutura muito mais leve e mais clean em sua implementação Smile.

ATENÇÃO: *Apesar de termos algumas vantagens sob a escolha de uma aplicação usando o conceito Self-Host, lembre-se que isso não substitui o IIS em sua totalidade. Algumas funcionalidades que são encontradas no IIS, tais como: *SSL, Event Logging, serão perdidas e, caso você precise delas, terá que implementar você mesmo.

Criando o projeto

Agora que já temos um entendimento sobre os princípios básicos do Owin e dos porquês sobre a implementação do projeto Katana, Let’s go to code. Abra o Visual Studio 2015, desta vez vamos criar um novo projeto do tipo Console Application. Com sua aplicação criada, precisamos adicionar as referências específicas ao mecanismo Self-Host Katana: Microsoft.Owin.SelfHost (PS.: Para quem quiser entrar direto no mundo do AspNet 6, a Microsoft adequou o nome do pacote para Microsoft.AspNet.WebApi.OwinSelfHost). Abra o Package Manager Console e execute o comando abaixo:

PM> Install-Package Microsoft.Owin.SelfHost

Quando o comando acima terminar de executar, você vai observar que foram instalados alguns pacotes necessários para que a aplicação possa ser configurada em modo Self-Host. Abaixo estão listados os pacotes que foram instalados (As versões listadas foram instaladas no momento em que eu escrevi este artigo):

Pacotes
  • Microsoft.Owin.Host.HttpListener.3.0.1
  • Owin.1.0.0
  • Microsoft.Owin.3.0.1
  • Microsoft.Owin.Diagnostics.3.0.1
  • Microsoft.Owin.Hosting.3.0.1
  • Microsoft.Owin.SelfHost.3.0.1

Os pacotes listados acima, estão apresentados na imagem abaixo:

image

Seu primeiro Host customizado

O trecho de código abaixo é o sufiente para que já tenhamos um servidor local, rodando independente do IIS. A classe WebApp encontra-se no namespace: Microsoft.Owin.Hosting.

using Microsoft.Owin.Hosting;  
using System;

namespace KatanaCustomSelfHost  
{
    class Program
    {
        static void Main(string[] args)
        {
            using (WebApp.Start<Startup>("https://localhost:8090"))
            {
                Console.WriteLine("Servidor Katana (vNext) online !!!"); Console.ReadLine();
            }
        }
    }
}

Agora é só teclar F5 e voilà:

image

No trecho de código acima, quem faz toda a mágica acontecer é o método genérico WebApp.Start<>. Ele precisa apenas que seja informada a classe de Startup que será utilizada e assim teremos o nosso servidor web funcionando perfeitamente. Mas é só isso?! Sim e Não. Sim, porque não precisamos de mais nada além do código acima para levantar o servidor web. Não, porque precisamos agora configurar a classe Startup com os devidos componentes, middlewares dentro do pipeline de execução para que tenhamos uma aplicação funcional. Vamos ao que interessa: Code, Code Code !!!! Open-mouthed smile

Para transformar a aplicação em algo funcional, será preciso adicionar algum componente que forneça um comportamento ao pipeline do Owin. Para isso, vamos alterar o método Configuration() da classe Startup. Como toda boa aplicação MVC, essa não será diferente! Vamos adicionar a nossa boa e velha tela Welcome Page, como sendo nosso primeiro componente built-in do novo modelo do ASP.NET, conforme segue o código abaixo:

using Owin;  
namespace KatanaCustomSelfHost  
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.UseWelcomePage();
        }
     }
}

Agora é só pressionar F5, abrir o browser de sua preferência e informar a url: https://localhost:8090 e voil:

image

Como você pode observar, o self-host está executando e nada mais foi necessário, além da inclusão do componente que habilita a página “Welcome”. Bom, toda aplicação ASP.NET tem uma tratativa de erros, certo? Bom, aqui no Katana (vNext) não será diferente. Só que para adicionarmos uma página padrão de gerenciamento de erros (Error Handler), temos que habilitar mais um outro componente! Vocês estão começando a perceber que o novo modelo de implementação de aplicações ASP.NET está ficando completamente MODULAR?! Bom, vamos adicionar um pouco mais de complexidade a nossa aplicação. Para isso, utilizei o mesmo exemplo da página "Welcome", só que agora o trecho de código abaixo:

using Owin; namespace KatanaCustomSelfHost { public class Startup { public void Configuration(IAppBuilder app) { app.UseWelcomePage("/"); app.UseErrorPage(); app.Run(context => { var parametroVersaoQS = context.Request.Query["versao"]; try { var parametroVersao = int.Parse(parametroVersaoQS); } catch { throw new System.Exception("Erro ao converter o número da versão"); } return context.Response.WriteAsync("Olá Mundo, eu sou o servidor Katana (vNext) de versão: " + parametroVersaoQS); }); } } }  

O código acima está simulando um erro na aplicação, quando tenta receber o parâmetro "versao" via QueryString e tenta convertê-lo para um número inteiro. Caso a conversão não seja bem sucedida, a aplicação levantará uma exceção e o sistema de gerenciamento de erro padrão do Katana (vNext) tratará a mensagem de exceção e exibirá a tela abaixo:

image

O sistema de tratamento de erro, como você pode observar, exibiu a tela com o stack trace da pilha de erro (Lembre-se: Estou mostrando apenas essa tela com essa pilha de erro de forma didática, para facilitar a apresentação do recurso), contendo informações do pipeline Owin que foi executado, como pode ser observado pelo último comando a ser executado: MoveNext(), isso quer dizer que o Pipeline tentou executar o próximo middleware; como não havia mais nenhum para ser executado, o pipeline para por ai e termina a execução.

Observando a tela de erro, você poderá encontrar outras abas contendo informações sobre: Query (Parâmetros informados na URL), Cookies, Headers (Cabeçalho) e Environments (Variáveis de ambiente), como mostra a imagema abaixo:

image

Usando Tracing

Como alguns recursos do IIS não estarão presentes em formato built-in no tipo de aplicação Self-Host, precisamos implementar nossos próprios mecanismos de trace, de tal forma que nos possibilite identificar e rastrear alguns comportamentos dentro do nosso Host. A classe Trace encontrada no namespace System.Diagnostic pode ser util para capturarmos e escrevermos essas informações no console do Host (Lembrete: Essa opção é apenas para apresentação do recurso de Trace, em um ambiente de produção temos outras opções para capturar essas informações). Abaixo segue uma implementação simples utilizando a classe Trace:

using Owin; using System.Diagnostics; namespace KatanaCustomSelfHost { public class Startup { public void Configuration(IAppBuilder app) { app.UseWelcomePage("/"); app.UseErrorPage(); app.Run(context => { Trace.WriteLine(context.Request.Uri); var parametroVersaoQS = context.Request.Query["versao"]; try { var parametroVersao = int.Parse(parametroVersaoQS); } catch { throw new System.Exception("Erro ao converter o número da versão"); } return context.Response.WriteAsync("Olá Mundo, eu sou o servidor Katana (vNext) de versão: " + parametroVersaoQS); }); } } }  

Após executar a aplicação temos o seguinte resutado:

image

Conclusão

Nesta segunda parte do artigo sobre Katana (atualmente chamado vNext), vimos como a microsoft hoje se está preocupada em cada vez mais fornecer outras possibilidades para os desenvolvedores de aplicações web poder desenvolver suas aplicações sem ter que depender 100% do IIS e do assembly monolitico System.Web. Nunca se imaginou que fosse possível ter controle quase que total da execução de uma aplicação web, desenvolvendo seu próprio servidor web em formato Self-Host. Apesar do projeto ser uma aplicação console, também mencimamos aqui que é possível transformá-lo em um Windows Service, por exemplo.

O código fonte utilizando neste artigo encontra-se no meu repositório do GitHub

Espero que tenham gostado e até a próxima. Aproveite também para deixar seu comentário aqui no blog.

Comments