samedi 16 février 2008

Techdays 2008: Nom de code Volta

Volta session présentée par Erik Meijer himself


La webcast de cette session n'est pas encore en ligne, on peut voir une vidéo en attendant ici (Part I) et ici (Part II). Pour suivre l'actualité de ce framework, on peut lire le blog de l'équipe Volta.

Résumé de la session

S'appuyant sur sa propre expérience et en l'étayant avec le livre The Change Function: Why Some Technologies Take Off and Others Crash and Burn, Erik introduit le concept de Volta par sa facilité d'adoption : Minimiser la learning curve en réutilisant au maximum l'existant.

Bon ok, mais qu'est-ce que c'est Volta?

Des outils pour le développeur pour décider a posteriori de la séparation logiques des couches, mais également du mode synchrone/asynchrone, d'un mode Ajax ou classique.

Les exemples de la session sont assez similaires au starter du site Volta.

Commencez par créer une application Volta après avoir installé la version beta.

Notez une première différence avec une application classique, si vous dépliez la page .cs par défaut, elle contient une page Html.

Petite digression pour comprendre la structure d'une fichier Volta: Les classes héritent de la classe Page qui a un getter sur un Document qui donne accès aux éléments DOM de la page HTML:

public abstract class
Page{

protected Page();

public Document Document { get; }

public Window Window { get; }
}

Grace à cette propriété, on accède donc directement aux objets de la page Html:

Button button2 = Document.GetById<>("Button1");
Button button1 = (Button)Document["Button1"];
Comme nous allons le voir, Volta, par soucis de simplicité, fonctionne principalement par attribut, ce qui est une tendance générale. Ainsi pour spécifier la page de départ et le fichier css par exemple, on écrit:
[assembly: StartPage("Page.html")]
[assembly: VoltaFile("favicon.ico")]
[assembly: VoltaFile("main.css")]
public partial class VoltaPage1 : Page

Une fois terminée l'application appelant une page Html et une classe business, on passe en mode Client/Serveur en faisant tourner l'application non plus dans le process du navigateur mais dans celui du WebServer Volta, et ce, juste en posant un attribut sur la classe business:

[RunAtOrigin()]
Pour cela il faut avoir coché la case Enable Volta tier splitter dans les propriétés du projet, onglet Volta et ajouté

using Microsoft.LiveLabs.Volta.MultiTier;

En ouvrant le Volta WebServer, on peut tracer les logs. Pour le premier appel d'une simple page Html, plus d'une centaine de request Get... Erik nous a bien prévenu qu'il manque une phase d'optimisation...

Cette approche me rappelle un peu Mozilla Prism pour transformer le web en application.

Second Exemple

Passer d'un mode d'appel synchrone à un mode asynchrone sans utiliser le pattern classique Begin/End Invoke avec l'attribut

[Async()]
sur la méthode à appeler, puis on remplace l'appel en mode synchrone

greetingElement.InnerText = greeter.Greet(name);

en mode asynchrone :

greeter.Greet(name, message => { greetingElement.InnerText = message; });

Cependant, Volta étant encore en béta, le pattern de gestion des exceptions en mode asynchrone n'est pas encore clair.

Trick Asynchrone: dans le cas de demandes asynchrones successives, les réponses peuvent être incohérentes si l'une d'elles a été plus longue. Erik utilise un séquenceur dans lequel il timestamp les demandes et vérifie dans le callback de l'asynchrone si la réponse est celle de la dernière demande, sinon elle est supprimée.

Autre exemple, passer d'un mode compilé à un mode javascript: pas de problème, le javascript est produit par le framework. Ce tour de force est réalisé en plaçant une couche intermédiaire entre le code source et l'IL, le MSIL Volta qui traite les attributs et fourni l'IL correspondant.

Passer à l'ajax, c'est faire une application single tier avec un peu de refactoring, et donc d'abord ce concentrer sur le besoin métier avant de contruire une architecture répondant à un seul besoin technique.

Exemple d'un appel linq sur des tables clusters

Linq for MapReduce. On peut compiler linq pour des appels en parallèles vers des bases partitionnées. Je n'ai pas trouvé d'informations sur ce sujet.

Mais allons encore plus loin dans le 3-tier splitting façon Volta:

Pourquoi mettre la définition d'une fonction SQL dans la base quand on peut la mettre dans notre assembly .Net avec un simple attribut

[Server.SqlFunction()]

Le custom attribut s'occupe du reste!!
Et encore

[import()]

pour accéder au javascript via .Net et

[Export()]

pour exposer .Net au javascript.
La version est en beta mais on parle déjà de publier des services web aussi simplement que

[PublishAsService()]

Un autre avantage: le profiling end-to-end de l'application par une simple case à cocher des propriétés du projet "Enable End-to-end profiling" et tout ça en s'appuyant sur Microsoft service trace viewer de WCF, qui d'ailleurs s'execute automatiquement.

Conclusion

Erik est un personnage haut en couleur (tout comme sa chemise) passionnant (co-créateur de Linq) et porteur d'un projet intéressant par son approche: repousser la décision de l'architecture ou plutot partir sur une architecture simple et pouvoir la faire évoluer selon les besoins par simples attributs, et surtout ré utiliser l'existant, mais qui pose de sérieuses questions d'architecture.

Pour lire un autre point de vue sur la session sur le blog d'InsideIt.

Aucun commentaire:


Laurent Morisseau, auteur de ce blog, pour me contacter