OWIN! Qual seu propósito?

Introdução

Ao longo de muitos anos, dentro do desenvolvimento web Microsoft, todas as nossas aplicações funcionaram e continuam funcionando com base em 3 letras: IIS (Internet Information Serrvice) – O Servidor de aplicações WEB da Microsoft. Desde a primeira versão do IIS – antes chamado de Internet Information Server, lançada com o Windows NT – Substituindo seu antecessor: PWS (Personal Web Server), atualmente conhecido pelos desenvolvedores web como: Internet Information Services, o IIS vem sofrendo grandes mudanças e atualizações consideraveis para melhorias da plataforma e processamento de sistemas que funcionam baseados nele.

Essa dependência ainda hoje é muito forte, o que faz com que a maioria das aplicações ASP.NET necessitem de um servidor IIS e consequentemente um servidor Windows Server. Devido essa dependência dos sistemas ASP.NET precisam sempre de um servidor Windows Server + IIS, surgiu o padrão chamado: OWINOpen Web Interface for .NET. O OWIN tem como objetivo, preencher a lacuna que existia há anos no desenvolvimento web – Desacoplar Servidor (Server) e Aplicação(Application), oferencendo soluções como o projeto Katana ou o Nowin.

O que significa a tecnologia OWIN? Mas OWIN É uma tecnologia?

Primeiramente, não se trata de uma tecnologia. OWIN é um acronimo de Open Web Interface for .NET, segue abaixo a sua definição conforme especificado no site oficial:

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

Após dois anos de muito esforço dos colaboradores do projeto (2010-2012), OWIN finalmente foi concluido e está atualmente na sua versão v1.0. Ele não necessita de código e não fornece nenhum tipo de exemplo, mas sim padrões web a serem seguidos, com o objetivo padronizar a comunicação entre servidor e aplicação, chegando ao seu objetivo: Desacoplar a camada do servidor da camada da aplicação, o que faz não ter nenhum tipo de dependência com o servidor web, no caso o IIS.

Porque eu usaria OWIN?

Ao longo de muitos anos, os desenvolvedores web desejaram muito (pelo menos eu) que fosse possível rodar aplicações web utilizando ASP.NET em servidores não Windows. Com as explicações acima, acredito que você tenha imaginado algumas das grandes vantagens e o importante fator de utilizar o OWIN em seus novos projetos ASP.NET, não? Caso essas vantagens não tenham ficado evidentes para você, vou citar algumas que provavelmente não sejam tão claras.

OWIN foi inspirado no NodeJs, Rack e WSGI on Python, todos com um objetivo simples: Ser um servidor web leve, primeiramente (atualmente temos os padrões do OWIN aplicados executando cross-plataform, através do vNext).

Gostaria de deixar bem claro que o IIS é um dos servidores web mais testados do mundo e com alto grau de confiabilidade, o que garantirá longos anos de uso em conjunto com aplicações web ASP.NET. Mas, o IIS é um software que está 100% dependente do sistema operacional Windows, o que força qualquer liberação de atualização no IIS ter que atualizar o sistema operacional windows; isso gera uma alta barreira com a equipe de infraestrutura/operação, que precisa atualizar o sistema operacional para que a nova funcionalidade do IIS seja aplicada e fique disponível para uso do time de desenvolvimento. Para ficar evidente essa operação: O WebSocket ficou disponível apenas nas últimas versões do Windows, o que obrigou muitas operações a ter que atualizar o SO inteiro para que essa funcionalidade ficasse disponível.

O propósito do OWIN é que o código da sua aplicação não fique vinculado ao sistema operacional, o que acontece atualmente com as aplicações ASP.NET que são desenvolvidas dependentes do System.Web, uma biblioteca muito grande, 100% dependente do IIS e consequentemente do sistema operacional e altamente monolítica. Com o OWIN, você pode utilizar o que você quiser ao invés do IIS (ex. Katana ou Nowin) e quando necessário atualizá-lo você mesmo, ao invés de aguardar a atualização do SO. Além disso tudo que foi apresentado, se não estiver satisfeito, você mesmo pode construir seu próprio HOST e contará com a flexibilidade de montar seu próprio pipeline, através de mecanismos de Middleware do OWIN. Outro ponto a ser considerado com a utilização de implementações com base no OWIN é: PERFORMANCE e Cliente-Servidor desacoplados!

Ok! Mas quando eu devo utilizar OWIN? A resposta é: SEMPRE que você puder! J

O projeto Katana, que é uma implementação da Microsoft foi feita completamente baseada nos padrões OWIN (o que será ainda mais verdade na versão vNext), contudo precisa-se ter um pouco de cuidado com a escolha desses novos padrões. Alguns frameworks ainda não são compatíveis com os novos padrões, mas alguns dos principais já estão funcionando de acordo com as novas diretrizes: Web API, SignalR, estes podem ser ativados por meio de ativações dos Middlewares, enquanto o ASP.NET (versões anteriores a v5) não são compativeis. Outros frameworks de terceiros são compativeis com os padrões do OWIN, tais como: NancyFX e FubuMVC.

Especificações do OWIN

Como mencionado anteriormente sobre as especificações do OWIN, elas buscam um requisito: PERFORMANCE, e para ter esse requisito atendido a especificação é bem simples, seguindo um conjunto de camadas (Layers) conforme segue a imagema abaixo:

OWIN Layers















Abaixo seguem um pouco mais de detalhes sobre cada uma das camadas OWIN:

  • Host – Princpal responsável por inicializar a aplicação web.
  • Server – Atual servidor HTTP, a principal ligação entre a rede socket para ouvir as Requests e envia-las ao pipeline dos componentes OWIN Middlewares.
  • Middleware – Estes componentes ficam entre a aplicação e o código final da aplicação e gerencia as requisições enviadas através do pipeline OWIN. Estes componentes podem ser simples como sistema de Logger ou tão complexos como um sistema de autenticação/autorização (AspNet Identity), por exemplo.
  • Application – Aqui encontra-se o código específico da aplicação, construido em cima de um framework web.

Chaves OWIN (OWIN Keys)

O ambiente OWIN fornece algumas informações interessantes e muitas vezes importantes no cabeçalho de suas requisições ou respostas das requisições, além do estado do servidor. Porém, é de responsabilidade do servidor criar essas informações, preenche-las ou ler o corpo da requisição que chegou no servidor.

Em cada pipeline, cada um dos componentes e camadas expõem informações adicionais que são armazenadas em um dicionário. As chaves e o que cada uma delas traz de informações, encontram-se listadas abaixo:

Dados da Requisição [Request Data]:
Headers Requeridos
  • owin.RequestBody
  • owin.RequestHeaders
  • owin.RequestMethod
  • owin.RequestPath
  • owin.RequestPathBase
  • owin.RequestProtocol
  • owin.RequestQueryString
  • owin.RequestScheme
Chaves NÃO requeridas
  • owin.RequestId
  • owin.RequestUser
Dados da Resposta [Response Data]:
Headers Requeridos
  • owin.ResponseBody
  • owin.ResponseHeaders
Headers NÃO Requeridos
  • owin.ResponseStatusCode
  • owin.ResponseReasonPhrase
  • owin.ResponseProtocol
Outros Dados [Other Data]:
Headers Requeridos
  • owin.CallCanceles
  • owin.Version

Você pode encontrar outras opções de chaves no site da documentação oficial do aspnet.

Introdução ao projeto Katana

Desde que o estilo arquitetural REST chegou como uma nova forma de padronizar a transferência e troca de dados entre aplicações web, a forma de pensar e construir sistemas web começou a sofrer algumas mudanças e melhorias.

O Web API chegou para acompanhar essas novas tendências e padrões de desenvolvimento web, porém não foi somente isso que chegou para facilitar a vida para os desenvolvedores web que utilizam tecnologias Microsoft. Como o Web API tem a premissa de ser leve e com a crescente necessidade de criarmos sistemas ainda mais modulares, ainda existia a preocupação em como seriam separados os componentes de aplicações web modernas, como arquivos estáticos, web sockets, web APIs, arquivos html dinâmicos, e etc.

Para evitar a proliferação de processos, os quais teriam de ser iniciado, parado, e gerenciado de forma independente, era necessário um processo de HOST comum aos recursos e módulos adicionais pudessem ser facilmente adicionados. E assim nasceu o OWIN, para padronizar como as estrutuas e componentes web se comunicariam e poderiam ser facilmente conectados ao pipeline do HOST da aplicação web. Katana é o processo de hospedagem e servidor web construido pela Microsoft utilizando essas especificações (sendo evoluído em alguns aspectos na versão do AspNet 6 – vNext). Katana está disponível via pacotes que podem ser instalados via NuGet diretamente em seu projeto.

Conclusão

Neste artigo não tive a pretensão de me aprofundar em como o OWIN foi implementado no projeto Katana, mas sim em explicar um pouco sobre de onde vieram as necessidades de se criar o padrão OWIN, explicar o que ele é de fato, o que tornou-se e quais são as especificações OWIN. Recapitulamos um pouco sobre a origem do IIS – ou seja, muitos aqui poderiam ou ter esquecido ou poderiam nem ter ouvido no PWS. Mostramos algumas das chaves que são implementadas nos cabeçalhos de Request e Response e fizemos uma breve introdução sobre o projeto Katana.

OBS.: No AspNet 5, os nomes Owin e Katana foram incorporados no namespace: Microsoft.AspNet.xxx. Ex.: Install-Package Microsoft.AspNet.Owin.

No próximo artigo, vamos tratar com mais detalhe como desenvolver uma aplicação utilizando o projeto Katana, Self-Host, OwinHost, Multiplos ambientes e muito mais :).

Espero que tenham gostado e aguardem que teremos novidades!!!
Até a próxima

Comments