Silverlight et DLR à TechEd
La conférence TechEd 2007 réunit chaque année plusieurs milliers de développeurs .NET. C'est pour Microsoft l'occasion de présenter ses produits actuels ou futurs. Cette année, les sujets phares furent Silverlight, Entity Framework, Linq, DLR et Astoria. Lionel Laské, auteur DNG, nous fait une synthèse des différentes sessions qu'il a suivi. Au menu, Silverlight et DLR.
Silverlight
Les sessions du TechEd sur SilverLight
n'étaient pas nécessairement les plus réussies, preuve
probablement du manque de maturité de Microsoft sur le
produit. C'était quand un même un des sujets à ne pas
manquer cette année.
Si l'on simplifie à l'extrême, qu'est ce que SilverLight ? un ActiveX embarqué dans IE qui exécute un sous-ensemble de la CLR .NET. Avec SilverLight 1.0, on pouvait afficher dans cet ActiveX uniquement du WPF (via un fichier XAML) et communiquer avec lui via du JavaScript. Sachant les fonctionnalités avancées de WPF (qui reposent notamment sur DirectX), cela permet déjà de réaliser des interfaces graphiques difficilement envisageables avec du web ou de l'AJAX. C'est d'ailleurs ces capacités qui sont aujourd'hui mises en avant par Microsoft, notamment parce que le produit se positionne en concurrent de Flash. Une des sessions présentait par exemple BluePortal, un starterkit pour construire un portail d'hébergement vidéo dont l'interface va beaucoup plus loin que YouTube (voir un exemple d'utilisation sur le site http://premium.quiksilverlive.com/). Le site de QuickSilver est le fruit d'un partenariat avec Microsoft qui a profité de l'occasion pour démontrer concrètement les capacités de rendu visuel mais aussi d'intégration techniques du duo Silverlight/.NET (fermes de serveurs de streaming, applications WPF pour alimenter le backend, etc ...)
Même si tout reste à faire pour séduire les
designers, la construction de pages SilverLight en
utilisant conjointement Visual Studio et Expression
Blend est assez séduisante. On ouvre directement le
projet VS.NET dans Blend et vice verca. Et grâce à la
création de "storyboard", le développeur a en quelques
clicks la possibilité d'animer ses créations et le
sentiment de devenir un designer (le talent en moins…).
SilverLight 1.1 va plus loin puisqu'il permet
d'exécuter du code .NET dans le composant hébergé.
Autrement dit, c'est désormais toute la puissance du
.NET Framework que vous pouvez embarquer dans votre
composant SilverLight. De plus, SilverLight 1.1 permet
la communication bi-directionnelle entre le code
JavaScript et le code .NET. Une intégration qui permet
de réaliser par exemple des échanges d'événements (un
bouton de la page HTML qui déclenche un traitement dans
le composant SilverLight ou vice-verca).
Si Microsoft parle beaucoup des
fonctionnalités "sexy" de SilverLight, il faut
comprendre que c'est finalement de vraies applications
riches .NET que l'on peut réaliser avec SilverLight.
D'ailleurs depuis SilverLight 1.1, on peut désormais
appeler du HTTP, des web services ou même un composant
WCF. Quand on sait que Microsoft travaille
actuellement sur un Composite Application Block pour WPF
(http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx),
on se dit que SilverLight est une belle arme pour la
future bataille qui va se jouer autour des SaaS.
Dynamic Language Runtime (DLR)
Plusieurs sessions du TechEd évoquaient
directement ou indirectement la DLR. La DLR est une
surcouche du .NET Framework 3.5 facilitant
l'implémentation et l'interopérabilité des langages
dynamiques. La DLR est finalement aux langages Python et
Ruby ce que la CLR est à C# et à VB.NET. Particularité
de la DLR, elle est Open Source et librement
téléchargeable sur le site CodePlex avec les premières
implémentations qui l'utilisent: IronPython et IronRuby.
Deux autres implémentations proposées par Microsoft
devraient arriver rapidement, un JavaScript et un
VBScript.
La DLR peut être hébergée dans une application
.NET quelconque (ce ne sont que quelques assemblies),
elle fait partie intégrante de SilverLight 1.1 et peut
également être utilisée pour l'exécution de pages
ASP.NET (nous y reviendrons).
Difficile de décrire en quelques mots le
fonctionnement de la DLR, nous y reviendrons plutôt dans
un article spécifique. Globalement, pour permettre
l'interopérabilité, la DLR propose de décrire de manière
abstraite le fonctionnement d'un langage. Ainsi en
utilisant des règles de résolution pour les appels de
fonctions, les opérations et les conversions, on fait
comprendre de manière déclarative à la DLR le
fonctionnement de chacun des langages. Une fois cette
étape de déclaration réalisée, l'ensemble du mécanisme
repose sur la construction d'arbres syntaxiques.
Lorsqu'on veut exécuter un programme d'un langage de la
DLR, on exécute un parseur qui va générer un arbre
syntaxique au format de la DLR. C'est cet arbre qui va
être utilisé par la DLR pour l'exécuter le programme,
après une génération préalable en code IL.
L'interopérabilité est assurée entre les différents
langages de la DLR puisqu'ils partagent la même
représentation d'un arbre syntaxique, de la même manière
que les langages de la CLR partagent la même
représentation du code IL qu'ils génèrent.
Un interpréteur en ligne de commande est
présenté comme exemple. Il permet de saisir la
définition d'une fonction en IronPython, de l'exécuter
puis , sans sortir du programme, de lancer une commande
IronRuby qui appelle la fonction IronPython. De la même
manière on peut dans le même programme manipuler les
types et fonctions de la CLR pour lesquels la DLR
propose des règles de résolutions standards. Plusieurs
exemples sont montrés pour manipuler depuis IronPython
des APIs aussi diverses que les APIs du TabletPC, la
Speech API, ou des composants COM.
Plus fort: un exemple d'interpréteur ligne de
commande est réalisé mais cette fois depuis une fenêtre
web SilverLight. L'apothéose est atteinte quand ce même
interpréteur se transforme en un véritable IDE avec une
mini gestion de projets et un debuggeur qui s'exécutent
entièrement en Web. Imaginez Visual Studio Express en
mode web !
Mais à quoi cela sert-il de reposer sur un
langage dynamique ? Il est clair que le choix du langage
de développement est surtout une question de
sensibilité, les speakers présentent néanmoins quelques
exemples qui montrent la puissance syntaxique du python
sur le C# (à vous d'apprécier):
En C#:
int i =
Convert.ToInt32(Request.QueryString[“Name"]);
En IronPython:
i =
int(Request.Name)
En C#:
LocationsPicker
lp =
(LocationsPicker)
FormView1.FindControl("LocationPicker1“);
En
IronPython:
lp = FormView1.LocationPicker1
D'autres pistes sont évoquées pour démontrer
la puissance d'un langage dynamique: par exemple la
possibilité de générer à la volée le proxy pour un web
service (au lieu de faire "Add web reference…" et de
lancer la compilation) ou, de la même manière, de
générer dynamiquement une couche d'accès aux données. La
vraie question se pose côté applicatif: ce sont
probablement les applications dont le besoin fonctionnel
évolue très rapidement, voir même évolue pendant leur
exécution qui bénéficieront le plus de l'utilisation
d'un langage dynamique: mais est-ce la majorité des
applications ?
C'est avec l'intégration dans ASP.NET que l'on comprend le mieux l'objectif de Microsoft avec la DLR. En effet, IronPython propose l'installation d'un plug-ins permettant de l'utiliser comme langage de développement pour le code behind des pages ASP.NET. Mais attention, il ne s'agit pas simplement d'ajouter un langage: avec l'installation de ce plug-ins c'est tout le fonctionnement interne d'ASP.NET qui est modifié lorsqu'on choisi IronPython comme langage. Plus de génération à la volée d'une assembly et plus de chargement dynamique d'assembly: la DLR prend directement la main et, comme le montre le schéma suivant, on se retrouve quasiment dans un mode de fonctionnement proche du... PHP.
Et n'est ce pas cela l'objectif de la DLR:
ramener dans le giron de Microsoft tous les développeurs
qui préfèrent aujourd'hui utiliser les langages de
script, et donc délaisser .NET. Si on ajoute à cela que
la DLR et ces nouveaux langages sont livrés en Open
Source, ne peut-on pas imaginer qu'une implémentation de
PHP sur la DLR sera la prochaine annonce de Microsoft ?
|
Lionel Laské est architecte et chef du service Nouvelles Technologies à C2S. C2S est la société de services informatique du groupe Bouygues. C2S est spécialisée dans les technologie .NET et est Microsoft Gold Certified Partner. C2S est également à l'origine d'une offre de migration des applications NS-DK/NatStar vers .NET. |
 |