Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Premier contact avec OWIN

Poster un commentaire

Sans le savoir, en utilisant WebApi ou SignalR vous vous êtes engagé dans une révolution silencieuse quant à la façon dont on va à créer des applications Web avec .Net à l’avenir.

Pour la première fois depuis 2002 le pipeline Web n’est plus obligatoirement le pipeline ASP.NET.
C’est un pipeline que vous allez pouvoir construire vous même pour le tailler à vos besoins. Votre code va devenir entièrement indépendant de l’environnement où il tourne et deviendra nativement portable et ouvert à toute sorte de projets open source.

 

Le pipeline ASP.NET va continuer à vivre bien sûr étant donné la quantité d’applications qui s’en servent. De plus le concept du pipeline ASP.NET reste encore valide dans nombres de cas. Mais d’autres modèles font s’ouvrir et il est possible que rapidement aspx et même MVC sous sa forme présente deviennent du vieux code.

L’agent responsable de cette évolution c’est OWIN.

OWIN est un acronyme: Open Web Interface for .Net. Il s’agit d’une spécification que l’on peut retrouver ici:

http://owin.org/

La spécification n’est pas très longue à lire. Faites le sans vous inquiéter que tout ne soit pas clair, cet article et les suivants vont y remédier.

OWIN est une spécification .Net, mais des implémentations existent déjà, en particulier Katana de Microsoft. C’est surtout celle-là que nous étudierons.
Alors partons ensemble à la découverte d’OWIN.

C’est quoi le problème?

OWIN prétend résoudre un problème, mais lequel?

 

Les applications Web .Net s’appuient sur un pipeline implémenté par les classes de l’espace de noms System.Web. que l’on pourrait résumer ainsi:

06-04-2014 18-17-12

Une caractéristique de ce pipeline est d’être très lié à IIS qui fait office aussi bien d’hôte que de serveur Http. IIS ou un de ses dérivés comme Cassini et IIS Express.

Une autre particularité de cette architecture est que le pipeline est fournit prêt à l’emploi, mais en mode tout ou rien. On peut tout au plus disposer de quelques points d’extensibilité dans le fichier global.asax ou en ajoutant des modules.

 

Cette architecture est très confortable et permet de gros gains en productivité. Ceux qui ont jadis travaillé avec des CGI me comprendrons.

Vous disposez d’un pipeline prêt à l’emploi sans avoir à le bricoler vous même.

IIS vous apporte nativement des services comme la gestion des processus, de la mémoire, du cache, l’authentification, les cookies, le serveur Http….

Il est clair qu’une technologie telle ASP.NET à réellement permis de booster notre capacité à développer des applications Web extrêmement complexes et exigeantes.

 

Tout cela marche très bien, mais nécessite tout de même une API qui d’évidence fait beaucoup de choses.

  1. Toutes les applications n’ont pas forcément besoin de cookies, de pouvoir monter en charge, de prendre en charge des composants ASP.NET.
    Mais on doit tout de même trimbaler la plomberie correspondante.
  2. L’omniprésence de ce pipeline rend pratiquement impossible des évolutions, pourtant naturelles, comme porter MVC ASP.NET ailleurs que dans des environnements Web.
  3. L’omniprésence de ce pipeline rend son évolution difficile sans risquer de casser beaucoup de code existant.
    Les modèles de développement actuels insistent beaucoup sur la testabilité. Tester une application ASP.NET est souvent difficile en raison des trop nombreuses dépendances.
  4. Le cycle de vie de cette API est celui de  .Net, soit une fois par an au mieux.
    C’est un cycle de vie trop lent pour les besoins actuels où l’on parle d’agilité et de packages Nuget
  5. Impossibilité de choisir son hôte ou son serveur Http, ce qui est un frein au déploiement multiplateforme de l’application.
    Et oui, ne l’oublions pas, l’Open Source est le nouvel Eldorado de Microsoft qui n’y est plus hostile:http://www.dotnetfoundation.org/On pourra même à l’avenir devenir MVP Open Source!

 

L’objectif d’OWIN est justement d’apporter une réponse à ces différents problèmes.

 

C’est quoi OWIN?

Tout d’abord OWIN est une norme, une abstraction. Il existe des implémentations comme Katana proposé par Microsoft.

OWIN s’appuie sur deux abstractions:

  • Un dictionnaire d’environnement

Le pipeline Asp.Net déclare une myriade de classes et de propriétés spécialisées:

06-04-2014 20-17-32

Ces classes sont très spécifiques ce qui ne facilite pas l’indépendance entre les modules et les technologies. OWIN simplifie les choses et se contente d’un dictionnaire qui rassemble le tout:

06-04-2014 20-29-48

Un certain nombre de clefs dont le nom démarre par owin sont définies dans la spécification. Certaines sont obligatoires d’autres non. Des composants peuvent définir leur propre clef également.

L’intérêt d’un dictionnaire est de ne pas dépendre d’un modèle objet .Net définit comme HttpContext par exemple.

  • Un délégué

OWIN définit un délégué AppFunc ainsi:


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

AppFunc est l’interface entre les différents composants OWIN. Il s’agit de la signature d’une fonction qui attend en paramètres le dictionnaire d’environnement et retourne une Task.

  • On appelle délégué applicatif toute implémentation de AppFunc.
  • Un composant OWIN (dit encore middleware ou composant applicatif) est toute classe qui implémente AppFunc.
  • L’enchaînement des middlewares constitue le pipeline OWIN.

 

Cette architecture présente de nombreux avantages pour le développeur:

  1. Il y a un très petit nombre de dépendance de type (comparez avec ASP.NET) ce qui simplifie fortement la montée en compétence sur OWIN
  2. L’architecture est résolument asynchrone
  3. un délégué applicatif représente une unité d’exécution atomique et le dictionnaire d’environnement est le seul lien entre middlewares. De ce fait il est très facile d »enchaîner les composants pour créer des pipelines éventuellement complexe avec des étapes conditionnelles par exemple.

 

En résumé l’architecture OWIN est la suivante:

06-04-2014 20-43-33

Important: OWIN distingue l’hôte du serveur Http. Contrairement à l’architecture ASP.NET ces deux composants peuvent être choisis indépendamment.
OWIN se veut agnostique avec son environnement et en particulier avec son hébergeur. Une application qui n’est pas hébergée par IIS est dite self-hosting dans la terminologie WCF.

 

Le deuxième avantage apporté par OWIN est que l’on arrive pas avec un pipeline en mode « on prend tout ou rien ». C’est à vous d’ajouter les modules dont votre application a besoin.

Le pipeline OWIN peut comporter autant de middleware que vous le souhaitez, mais il n’en comporte aucun par défaut. C’est ce qui assure une grade flexibilité, la légèreté de l’environnement et surtout la possibilité d’utiliser des briques personnalisées ou venues d’autres environnement.

06-04-2014 20-58-28

OWIN est un moteur de pipeline: vous définissez votre pipeline personnalisé, OWIN l’anime pour vous.

A titre d’exemple voici un exemple de différentes façons dont on peut héberger une application Web Api avec OWIN:

 

https://amethyste16.wordpress.com/2014/03/30/web-api-deux-modes-dhebergement/

 

On peut maintenant modifier un des schémas précédents pour montrer comment fonctionne le pipeline OWIN:

07-04-2014 22-40-56Le schéma montre un exemple d’application OWIN dont l’hôte et le serveur Http sont (éventuellement) différents. Le pipeline est composé de 4 modules avec l’application qui s’enchaînent les uns les autres en se transmettant le dictionnaire de données via l’interface AppFun..

 

 Instanciation du pipeline

L’instanciation du pipeline fait aussi partie de la spécification OWIN au chapitre 4. C’est l’hôte qui s’en charge.

Une fois que l’hôte démarre, les tâches suivantes sont successivement accomplies:

07-04-2014 23-13-25

 

La première étape consiste à construire l’interface IDictionary. Celle-ci sera complétée tout au long du pipeline par les différents middleware rencontrés. L’hôte renseigne à minima les champs obligatoires prévus par la norme (étapes 1 à 3).

Le code de démarrage n’est pas décrit par OWIN.

Dans Katana, par défaut, il s’agit d’une classe appelée Startup dotée de cette signature:


public sealed class Startup
{
public void Configure(IAppBuilder app)
{
// construction du pipeline
}
}

 

Nous en reparlerons en détail dans d’autres articles.

Le code de démarrage va construire le pipeline en instanciant chaque middleware les uns à la suite des autres. Les middleware vont éventuellement compléter Properties.

Une fois le pipeline construit, le serveur récupère la main et est prêt à recevoir des requêtes Http et à le traiter.

 

Où trouver des middlewares?

 

Un seul mot: Nuget!

Pour voir toute la richesse des composants déjà disponibles:

http://www.nuget.org/packages?q=owin

 

 Bibliographie

http://owin.org/

http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana

http://msdn.microsoft.com/en-us/magazine/dn451439.aspx

http://piusnjoka.com/2013/11/25/what-really-is-katana-and-owin/

 

Une vidéo par un des concepteurs d’OWIN:

http://vimeo.com/57007898

Mais aussi:

http://channel9.msdn.com/Shows/Web+Camps+TV/The-Katana-Project-OWIN-for-ASPNET

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s