Con ASP.NET 5 all'orizzonte (di recente è stata rilasciata la beta 8, l'ultima), diventa più impellente farsi trovare pronti per il rilascio ufficiale. Una delle novità è il supporto ad applicazioni web basate su OWIN. Quest'oggi cercheremo di capire di cosa si tratta e che implicazioni abbiano per noi sviluppatori.

OWIN è una specifica (http://owin.org) che descrive un'interfaccia standard per rendere un'applicazione web .NET disaccoppiata dal web server che la ospita. Un'applicazione web basata su OWIN, quindi, non è più legata ad IIS, ma può funzionare su un qualsiasi web server che sia conforme alla specifica. Questo apre scenari interessanti, come la possibilità di distribuire applicazioni su molteplici piattaforme, o di ospitarle in eseguibili secondo una modalità definita self-hosting.

A livello pratico, OWIN descrive un protocollo di comunicazione molto semplice: il web server e l'applicazione si scambiano informazioni attraverso un dizionario di tipo IDictionary, le cui chiavi rappresentano le varie parti di una richiesta HTTP (percorso, metodo, intestazioni, corpo) e della relativa risposta.
Tale dizionario è disponibile nell'applicazione web ai vari middleware, ovvero moduli operativi disposti in serie in una pipeline. Ciascuno di essi, dopo aver eseguito una propria logica, ha facoltà di invocare l'esecuzione del middleware immediatamente successivo, oppure di impedirne il proseguimento generando il contenuto della risposta.

I middleware possono avere complessità e responsabilità diversificate. Alcuni di essi sono creati per svolgere compiti trasversali, quali il logging o l'autorizzazione, mentre altri hanno il compito di generare il contenuto della risposta, sia esso prelevato da un file statico o frutto di un'elaborazione dinamica.
Nulla viene dato per scontato: in una pipeline OWIN sono presenti solo i middleware che lo sviluppatore vi configura. Questa rappresenta una sostanziale differenza rispetto allo sviluppo di applicazioni ASP.NET tradizionali, la cui pipeline era invece già popolata con alcuni HttpModule di uso comune, come ad esempio quelli inerenti alla Session e alla Forms Authentication, tra gli altri.

Lavorare con una pipeline OWIN ci fa guadagnare un controllo chirurgico sui componenti coinvolti nella nostra applicazione e questo ci permette di ottimizzarne le prestazioni.

Per iniziare a sperimentare con OWIN non dobbiamo attendere che ASP.NET 5 venga rilasciato ufficialmente. Infatti, possiamo provarlo sin da subito con ASP.NET Web API 2, che già da tempo può essere ospitato su web server OWIN-compliant.
Un esperimento interessante che possiamo compiere è quello di ospitare una Web API in un'applicazione console: in questo modo saremo in grado di distribuirla come file eseguibile e consumarla anche su PC privi di IIS.

Da Visual Studio 2015, iniziamo creando un progetto di tipo Applicazione Console per Windows.
Dalla Console di Gestione Pacchetti, lanciamo il seguente comando per ottenere la libreria (e relative dipendenze) che ci permetterà di preparare il nostro web server OWIN-compliant.

Install-Package Microsoft.AspNet.WebApi.OwinSelfHost

All'interno del progetto, creiamo una cartella chiamata Controllers ed aggiungiamo in essa una classe chiamata, ad esempio, CitiesController. Si tratta di un normale ApiController di ASP.NET Web API, del tutto simile a quello che avremmo in un'applicazione ASP.NET ospitata in IIS.

public class CitiesController : ApiController
{
  public IEnumerable<string> Get() 
  {
    //Restituisco dati staticamente a puro scopo esemplificativo
    return new[] 
    {
      "Roma", "Milano", "Torino"
    };
  }
}

Ora creiamo la classe da cui il servizio di routing di ASP.NET Web API viene configurato come middleware nella pipeline OWIN.
Per convenzione, chiamiamo questa classe Startup. Visual Studio 2015 ci permette di aggiungerla sfruttando un template apposito, chiamato "Classe di avvio di OWIN".

public class Startup
{
  public void Configuration(IAppBuilder appBuilder)
  {
    //Configuriamo la classica route di default
    HttpConfiguration config = new HttpConfiguration();
    config.Routes.MapHttpRoute
    (
      name: "Api",
      routeTemplate: "api/{controller}/{id}",
      defaults: new { id = RouteParameter.Optional }
    );

    //Configuriamo il middleware di routing di ASP.NET Web API
  //nella pipeline OWIN della nostra applicazione
    appBuilder.UseWebApi(config);
  }
}

L'interfaccia IAppBuilder definisce un metodo Use per configurare middleware nella pipeline. Tuttavia, a meno che non intendiamo scrivere middleware personalizzati, al suo posto useremo degli extension method appositi, come UseWebApi, atti a semplificare e rendere più leggibile la configurazione.

Non resta che predisporre l'avvio del web server dal metodo Main della nostra applicazione console. Per far ciò, usiamo il metodo generico WebApp.Start, indicando il nome della classe Startup come type parameter.

static void Main(string[] args)
{
  // Il web server si metterà ascolto sulla porta TCP 5000
  using (WebApp.Start<Startup>("http://localhost:5000/"))
  {
    Console.Write("Premi INVIO per teminare il programma...");
    Console.ReadLine();
  }
}

Avviamo il debug dell'applicazione console e, da questo momento, siamo in grado di interrogare la nostra Web API inviando richieste all'indirizzo http://localhost:5000/api/cities. Come è prevedibile, l'applicazione risponderà elencando i nomi delle città.