Die Zukunft von ASP.NET: Open Web Interface for .NET (OWIN)

Ohne Zweifel ist Open Web Interface for .NET (OWIN) ein Begriff, der in letzter Zeit viel an Popularität gewonnen hat.

OWIN ist eine offene Spezifikation, initiiert durch zwei Mitglieder des ASP.NET Teams (Louis Dejardin und Benjamin Vanderveen), die eine Standard-Schnittstelle für die Kommunikation zwischen Server und .NET-Anwendungen definiert. Die Version 1.0 der Spezifikation wurde im Oktober 2012 veröffentlicht und steht auf der Website des Projekts zur Verfügung.

Das grundsätzliche Ziel von OWIN ist es, eine Abstraktion zu erzeugen zwischen .NET-Anwendungen und dem Server, auf dem sie ausgeführt werden. Historisch sind diese Komponenten sehr stark gekoppelt.

Heute können wir uns nur folgende Architektur vorstellen:

• Wir schreiben .NET-Applikationen
• Basierend auf MVC oder WebForms Frameworks
• Diese laufen in eine ASP.NET Pipeline
• Und sie sind in IIS gehostet

Wir können uns nur schwer andere Architekturen vorstellen, oder? Weshalb ist das so? Das Problem ist, dass die Anwendungen Teil einer monolithischen Einheit sind, die schwierig zu zerstückeln ist. Dies hat einige Probleme oder Beschränkungen zur Folge.

Drei Szenarien als Beispiel:

1. Wir wollen MVC in Apache zum Laufen bringen. Dafür verwenden wir Projekt Mono. Nun, das Projekt Mono musste das ganze ASP.NET-Packet nachmachen, da MVC ein untrennbarer teil davon ist. Wäre MVC von ASP.NET entkoppelt, hätte man MVC als Modul migrieren können, ohne das ganze ASP.NET-Packet nachzumachen.
2. Stellt euch einen Windows-Dienst vor, der durch eine Browser-basierte Applikation konfiguriert werden soll. Ideal wäre, dass der Dienst selbst diese Konfigurations-Web-Applikation hosten und die Anforderungen bearbeiten würde, ohne Hilfe von IIS. Aber ASP.NET ist so stark von IIS abhängig, dass nur ein absoluter Experte so etwas zu Stande bringen könnte.
3. Habt Ihr gemerkt, wie viel Zeit zwischen den Versionen der  WebForms vergeht? Weil ASP.NET und WebForms untrennbar sind, muss eine neue Version von WebForms auf die ASP.NET-Zyklen abgestimmt sein.

OWIN-Architektur

Die OWIN-Architektur besteht aus einer Reihe von Komponenten, die eine Abstraktion der involvierten Elemente darstellen (Hosts, Servers, .NET-Applikationen). Folgende sind die Grundakteure in dieser Architektur:

• Host
  • Der Prozess, in dem unsere Applikation physisch gehostet wird (z.B. IIS, OwinHost.exe oder eine eigenentwickelte Konsolenanwendung)
• Server
  • Die Überwachungs-Applikation, die auf OWIN HTTP Anfragen hört und sie entsprechend weiterleitet
• Middleware
  • Komponenten, die in der Form einer OWIN Pipeline die Abfragen behandeln
• Framework
  • Rahmen, in dem wir unsere .NET-Applikationen schreiben (z.B. MVC, Web API oder SignalR).
• Application
  • Unsere Anwendungen, die unter einem der OWIN-kompatiblen Frameworks erstellt werden

Hier ist wirklich wichtig, dass vom Server aus nur OWIN gesprochen wird. Die OWIN-Systemarchitektur ermöglicht es z.B., dass eine Server-Anwendung mit SignalR 2.0 (bereits OWIN kompatibel) in einem Windows-Dienst oder in einer Mono/Apache-Plattform problemlos laufen kann.

Darüber hinaus ist es dank OWIN möglich, dass künftig separate Release-Zyklen der verschiedenen Produkte häufiger aktualisiert werden, ohne auf die Ankunft der neuen Versionen der Plattformen zu warten, auf denen sie laufen.

OWIN-Wörterbuch als Datenträger

Die von OWIN vorgeschlagene Form, wie Server und Frameworks kommunizieren, ist ganz einfach: Ein Datenwörterbuch mit standardisiertem Schlüssel. Alle Interaktionen zwischen diesen beiden Komponenten wird durch IDictionary<string, object> Objekte gelöst. Wenn eine Anfrage eintrifft, erstellt der Server ein Wörterbuch dieser Art mit Informationen aus der Abfrage und gibt es weiter  in die Pipeline (ähnlich wie der heutige Anforderungskontext HttpContext.Current in ASP.NET). Wenn z.B. eine Pipeline-Komponente das HTTP-Verb abfragen will, verwendet sie nicht den traditionellen Request.HttpMethod, sondern den Schlüssel «owin.RequestMethod» in OWINs Wörterbuch.

Folgend sind erforderlichen Schlüssel im OWIN-Wörterbuch aufgeführt:

Stream

IDictionary<string, string>

string

string

string

string

string

string

Stream

IDictionary<string, string>

CancellationToken

Auf der Website des Projekts werden weitere optionale Schlüssel aufgelistet.

OWIN-Lebenszyklus

Die OWIN-Spezifikation definiert klar, wie der Lebenszyklus von Anwendungen aussehen sollte, die auf diesem Standard basieren.

Beim Starten des Systems erstellt der Host ein erstes Wörterbuch des Typs IDictionary<string, object>, das mit Initialisierungs- und Umgebungseinträgen durchgeführt wird. Diese Information wird an einen ausgewählten Server ausgehändigt, der es mit Kontextwerten erweitert.

Danach sucht der Host den Boot-Code und ruft die Anwendung mit diesem Wörterbuch als Parameter auf. So hat die Anwendung die Möglichkeit, den Inhalt des Wörterbuchs zu lesen oder zu verändern und somit z.B. die Pipeline zu konfigurieren.

Eines der interessantesten Dinge bei OWIN ist seine Modularität: Im Gegensatz zur früheren ASP.NET-Architektur kann man mit OWIN nur die Komponenten einbeziehen, die gebraucht werden. Brauchen wir WebAPI? Dann fügen wir WebAPI hinzu. Nützt unserer Anwendung auch SignalR? Dann fügen wir SignalR hinzu. Brauchen wir ein auf Cookies basiertes Sicherheitssystem? Dann fügen wir das entsprechende Authentifizierungsmodul hinzu.

Sobald die Pipeline mit den gewünschten Middleware-Modulen konfiguriert ist, erhält der Host als Antwort einen Application delegate, auch AppFunc genannt. Dieser ist ein Vertreter der Methode, die für die Bearbeitung von Anträgen zuständig sein wird:

using AppFunc = Func<IDictionary<string, object>, Task>;

Auf diese Weise ist der Host in der Lage, Abfragen zu bearbeiten.

Für jede Anforderung erstellt der Server das Wörterbuch, bevölkt ihn und ruft die AppFunc-Methode mit diesem Wörterbuch als Parameter auf. Die Anforderung gibt einen Task zurück (auf deren Beendigung der Server wartet) und durchläuft die Pipeline entlang der konfigurierten Module.

Jedes Modul in der Pipeline kann:

• Eine Aufgabe durchführen und weiterleiten
• Die Anfrage verarbeiten und eine Antwort durch die Pipeline schicken
• Eine direkte Antwort erzwingen (z.B. ein Authentifikationsmodul, das eine Weiterleitung erzeugt)
• Einfach nur weiterleiten und erst am Schluss die Antwort verarbeiten

In diese Richtung liegt mit Sicherheit die Zukunft von ASP.NET, bleiben Sie also am Ball!