Après une version bonne pour une démo, j’ai voulu refactoriser le tout pour avoir quelque chose de viable.
Dans mon dernier billet, j’explique mon périple à la recherche d’un protocole de communication Inter-Processus, et j’ai choisi NDesk.DBus: l’implémentation full .Net de D-Bus.

La solution était sexy:

• Déclaration des services par interface, ne pouvant exposer QUE des types simples ou Struct. Cela force à réaliser qu’en matière de communication, une instance d’objet ne veut rien dire et qu’on communique que par DTO.
• Support des méthodes, propriétés et événements
• Channel par Socket/TCP ou par Pipe
• Communication optimisé binaire (pas d’XML ou de SOAP….)
• Exposition des services sur le Bus avec un contrat au format XML (comme un WSDL en quelque sorte)
• Cross-platform: provient du monde Linux mais existe sous Windows
• Un standard de communication Inter-Processus, de plus en plus utilisé sous Linux, remplaçant CORBA (avec Bonobo)

Mais voila, tout n’est pas rose, et DBus me donne du fil à retorde.
L’implémentation .Net n’est pas très propre:

• API pas très utilisable car quasiment tout est Internal
• Pas de doc?
• Ça manque de convention, le source n’est pas très lisible, j’ai envie de passer un coup de Resharper dessus
• Beaucoup, beaucoup de commentaire du genre “//temporary hack” ou “//TODO“… beaucoup de code commenté qui prouve que la personne a voulu faire bien mais n’a pas eu le temps
• Quand j’exécute DBusExplorer pour scanner mes services, cela plante 1 fois sur 2 mon client
• Je n’arrive pas à faire marcher un service ou un client dans un Thread!!! Cela me bloque totalement

Je me demande si je ne vais pas revenir à une solution .Net Remoting:

• implémentation .Net et Mono
• channel IPC (par Pipe)
• supporte les événements
• DBus est vraiment orienté “Desktop” comme le D l’indique. J’en fait donc une utilisation détournée.

Mais une autre solution peut aussi faire l’affaire: ProtoBuf, un protocole performant inventé par Google.

Je vais tacher de vous tenir plus au courant, histoire aussi de recueillir des opinions concernant mes choix.

Pas de conteneur d’application en .Net… ou presque

En fait, c’est suite à une frustration absolue datant du premier jour ou j’ai découvert .Net (car je faisais du Java, avant, dans mon temps libre…).
Après avoir lourdement digéré J2EE, les EJB, RMI/IIOP, j’ai été déçu de ne rien voir de tel en .Net.
Certains dirait que ce n’est pas une grosse perte En effet, J2EE n’a rien de simple, mais c’est quand même parfois puissant.

Je trouve stressant qu’une application .Net “d’entreprise” doit forcement dépendre des services Windows, des tâches schédulées, ou d’IIS. Déployer une application Java sur Tomcat est d’une simplicité déconcertante, et Microsoft propose un équivalent seulement dans le future Windows Server 2008 R2 avec Windows AppFabric.
Et encore, pour avoir vu la présentation aux Techdays, je suis plutôt déçu.

Gigaspaces? Un conteneur d’application malgré lui.

Ces derniers temps, de développe avec un DataGrid: Gigaspaces. Ce dernier est en Java, mais possède une API .Net. Je bénéficie alors de son infrastructure pour déployer facilement mes applications .Net.
En effet, ce dernier fonctionne sur le principe de “container” tournant sur plusieurs machines, sur lesquels on peut déployer X instance d’une application, appelé “Processing Unit”.
Comme Gigaspaces fournit une mémoire distribuée sur ces “containers” (c’est une peut l’objectif d’un DataGrid ), mes instances d’applications peuvent échanger des données via cette mémoire “partagée/distribuée”.

Gigaspaces fournie une notion de “Primary/Backup” ce qui permet de rendre une instance active/inactive en cas de crash.
Il est même possible d’activer des “moniteurs” pour rendre une instance inactive s’il n’y a plus assez de ressource (CPU/Mémoire/etc.) sur une machine, et activer une autre instance sur une autre machine. La répartition de la charge est donc super bien gérée, et presque transparente puisqu’on déploie un “zip” de notre application, et le service “Manager” se charge de l’installer sur les “containers”.

Mais voila, Gigaspaces c’est du lourd, du payant, et du Java.
Mon but est d’offrir quelque chose de similaire sans la performance de Gigaspaces ni sans la richesse de son API autour du cache.
Mon but est de pouvoir déployer une application Web, en uploadant un ZIP depuis une page d’administration, que cette dernière soit déployer sur X instances d’un coup, et qu’elles travaillent ensembles à l’aide d’un cache (Memcache et un très bon cache est suffisant pour mon besoin), d’une queue ou de service RPC.
Mon but est aussi de fournir un environnement d’exécution pure .Net, indépendant de l’OS, indépendant d’IIS/MSMQ/DCOM/etc, et donc compatible Mono/Linux.
C’est le “Write once, run anywhere” de Java, mais en .Net.

DotNetServer ou la quête du saint graal

J’ai donc commencé à voir comment héberger mes applications Web dans un container, à l’aide d’XSP…chose faite.
J’ai ensuite voulu calquer au modèle OSGI pour le “conteneur d’application”, avec séparation des applications par AppDomain, gestion de dépendance entre les applications, et cycle de vie de ces dernières.
Et enfin, j’ai cherché un moyen efficace de publier/souscrire à des services entre les applications.

J’ai passé ma journée à cherche un mécanisme de communication inter-AppDomain (ou inter-processus):

• PIPE/Mémoire partagée/Sémaphore: … je vais éviter de re-inventer la roue…
• .Net Remoting: la solution officiel de Microsoft pour une communication Inter-AppDomain, même s’ils disent que .Net Remoting est obsolète pour laisser place à WCF
• WCF avec le NAMED-PIPE: WCF n’existant pas sous Mono, je n’y pense même pas, surtout que c’est un peu une usine à gaz
• RMI/IIOP: pourquoi pas, mais c’est une solution plutôt distribuée (basé sur .Net Remoting).
• COM/DCOM: Solution Microsoft pure, étant même préconiser par Microsoft à la place de remoting (car plus de sécurité, transaction distribué, etc.). Mais pure Microsoft/Windows = pas pour moi
• XPCOM: en gros, dans la famille Corba, je veux le fils, celui qui n’est pas chez Microsoft. C’est peut-être une solution à envisager, mais Corba est abandonné dans le monde Linux pour du DBus
• DBus: protocole inventé pour une communication inter-processus sous Linux, pour remplacer l’ORB de Gnome ou DCop de KDE. C’est clairement un équivalant à COM, sans être un “Corba’like”, et c’est devenu standard sous Linux. De plus, une implémentation pure .Net existe.

Je me suis donc lancé sur DBus, tout comme J2EE à choisie RMI/IIOP… l’avenir me dira si j’ai fait le bon choix.

Bref, cela donne pas grand chose pour l’instant, mais voici le prototype:

On voit ici que j’ai démarré un “bundle” qui est une instance d’XSP, le serveur ASP.net (qui dans cet exemple héberge 2 applications Webs http://localhost:456/App1 et htpp://localhost:456/App2).

J’ai aussi démarré le bundle “MyAnotherBundle“, qui dépend de “MyBundle” qui dépend de “DBusBundle“.
Ces derniers se chagent car ils ne l’étaient pas encore.

• Le bundle DBus est simplement un démon DBus, qui offre un bus de message, un peut comme un broker dans Corba.
• Le bundle MyBundle va alors publier des services auprès de DBus.
• Le bundle MyAnotherBundle va alors consommer les services de MyBundle (il affiche le résultat de la fonction “sayHello” de MyBundle).

Comme je gère moi même les AppDomains, je configure leurs chemin de résolution de dépendance. Comme ça, chaque Bundle est installé dans un dossier, et n’a pas besoin de contenir TOUTES LES DLL qu’il a besoin, afin de ne pas les dupliquer entre les applications. Les DLL communes sont alors dans un dossier LIBS.

Conclusion

C’est loin d’être parfait et c’est un premier jet. Je ne sais pas si je vais avoir autant de motivation qu’aujourd’hui pour mener le projet à bien.
J’ai même découvert qu’un projet similaire existe: http://www.dotnetpowered.com/appserver.aspx mais il est mort depuis bien longtemps, et les sources sur le CSV ne sont plus disponible. Espérons qu’on n’en dise pas autant de mon projet dans plusieurs années
Mon projet est ambitieux, mais si ça vous plait de jeter un oeil aux sources, voir même contribuer, n’hésitez pas à faire votre branche des sources GIT: http://github.com/grozeille/DotNetServer
Le README explique un peut plus mes intentions, ou les schémas dans la doc, il faudrait maintenant que je rende ça plus attirant dans le Wiki de github (ainsi qu’un nom plus cool, comme le nom d’un animal?)

La particularité et le défi de MonoTouch, c’est que le processeur de l’iPhone ne supporte pas une opération nécessaire à la compilation à chaud (JIT), qui est la base des langages sur une VirtualMachine (.Net et Java). L’application Mono est alors compilée nativement, avec une suppression des bibliothèques du framework inutilisées.

Et Java alors, est-ce que la communauté compte faire quelque chose?
Et bien une startup, Flexycore, l’a déjà fait: iSpectrum! Et le produit est gratuit pour les projets Open-Source!!! Ce qui n’est pas le cas pour MonoTouch.

Voici un aperçu de ce qui est possible:

Certes, la démo n’est pas “bandante”, mais derrière, il y a le support de J2ME, du JavaScript, les API de l’iPhone (comme le GPS) et bientôt l’API OpenGL ES.
Est-ce le retour de Java pour les jeux mobiles?

J’y ai notamment contribué pour ajouter le support de Gendarme, l’outil d’analyse de code de Mono (équivalent à FXCop/StyleCop).
J’aurais aimé y contribué plus que cela (si j’avais eu le temps…) pour par exemple corriger les bugs sous IE ou les bugs sur les rapports FXCop/StyleCop avec des chemins relatifs.
Ces corrections de bugs me serrait très utiles dans le cadre de mon projet chez mon Client, puisque nous avons fait le choix d’utiliser Hudson comme plateforme d’intégration continue “multi-techno” (Java/C#/C++/Php).

Même si les développeurs Java exploite Hudson avec Sonar pour avoir un beau Dashboard sur des métriques de codes sources, nous exploitons les plugins d’Hudson pour les métriques .Net. En effet, le plugin Violation nous permet d’avoir des graph et des seuils d’alerte sur les rapports FXCop & Style. Nous combinons ça au plugin de rapport de tests NUnit, le plugin de rapport de tests Selenium, ainsi que le plugin Warning pour analyser les Warnings/Error à la compilation, et le plugin Task Scanner pour ne pas oublier de TODO dans le code En plus de cela, on génère un rapport NCoverExplorer (HTML) accessible directement depuis Hudson.

Et vous? Comment faites-vous vos métriques dans l’intégration continue? Est-ce que vous connaissiez Gendarme et est-ce que vous l’avez déjà utilisé?

J’ai posé la question lors de la soirée ALT.Net en présence de Jean-Baptiste Evain, à savoir si on ne va pas se retrouver avec 2 standards : .Net et Mono.
ATTENTION, je ne parle pas des spécifications de la VM ou du langage C#, mais des assembly fournies en standard avec le SDK.

Pour comparer avec le monde Java, Sun établi des spécifications (JSR), et certifie une JDK car elle contient les “fonctionnalités” demandées. C’est indispensable pour le “Write once, Run anyware“.

Mais pour l’instant, Mono reste sur les traces de Microsoft, et il n’y a pas de volonté de standardisation commune, Microsoft faisant le standard de facto.

On dit même Mono être à la traine, car une application .Net ne marchera pas forcement sur Mono (à vérifier avec MoMA).
Mais on se rend déjà compte que seulement la 2ème mouture de Mono fournit son lot de nouveautés, et que l’inverse peut se produire (application Mono ne marchant pas « out of the box » sur la SDK de Microsoft).

• Que nous réserve la version 3 ?
• Mono va-t-il suivre un autre chemin (orienté jeux) ?
• Va-t-on assister à une compétition (positive) .NetDK vs MonoDK ?
• Pourra-t-on dire “je préfère l’implémentation de System.Collection.Generic.List de Mono, plutôt que celle de Microsoft” ?
• Les développeurs choisiront-ils la version Libre pour que leurs applications soit le plus compatible possible, et pour être multi-plateforme (comme développer des WebServices sans utiliser WCF n’existant pas encore sous Mono) ?
• Microsoft vont-ils intégrer le travail de Mono dans le .NetDK officiel ?

Un autre point : l’API de Linux est riche (oui oui!) et je trouve incroyable le nombre de binding Mono pour cette dernière :

• DBus : framework de communication inter-application orienté message
• GStreamer : framework multimedia
• Cairo : framework vectoriel 2D
• Telepathy : framework de chat (xmpp, sip, etc.)
• GTK : remplaçant des winforms ?
• etc.

Ils existent plusieurs applications Mono-Linux qui ne sont pas « portables » sous une autre plateforme, car trop liées aux API natives. Mais la communauté a la volonté de les faire porter sous Mac/Windows (Tomboy,  Banshee), et ça passe forcement par une migration de ces API natives.

Assiste-t-on à un Linux qui envahi notre Windows/Mac grâce à Mono ??

On peux se demander “oui, mais pourquoi faire?” et je ne trouve pas de réponse à la question. En effet, il arrive souvent qu’une application .Net possède du Legacy et donc des dépendances COM ou P/Invoke. Dans ce cas, on ne peut pas la migrer (pour tester si une migration est possible: http://www.mono-project.com/Moma)

Mais comme je suis exigent en terme d’interface, je n’aime pas avoir une application “alien” qui ne ressemble pas à mon environnement Linux (GTK/QT). Certes, il est prévu d’avoir un meilleur support du moteur de thème lors du prochain GSoC, donc wait and see.

Rappelons que les Winforms sont une sur-couche .Net de l’API WIN32. Cette dernière n’existant pas sous Linux et MacOS, j’en profite alors pour féliciter les équipes de Mono pour leur implémentation “from scratch”.

D’un autre coté, l’implémentation WPF chez Mono avance plutôt vite. D’ailleurs, la première release de Moonlight vient de sortir. Il n’y a pas de dépendance WIN32 dans ce cas, et je vois plus l’avenir des applications .Net dans ce sens. Mais l’approche WPF est d’avoir un thème propre à l’application, comme c’est le cas pour les sites Web, on obtient la même interface sous Linux et Windows (et MacOS). Mais finalement je trouve que ces interfaces ne s’intègrent à aucun des 3 environnements.

J’avais déjà rédigé un billet sur la guerre entre les technologies de “présentation” dans le domaine du Web (Ajax/Flash/etc.). Je ne vous l’apprend pas, le monde “Desktop” et “Web” convergent. L’idée est plutôt simple: aujourd’hui on doit exécuter un OS qui héberge des applications “Desktop”, et on doit exécuter un navigateur pour les applications Web. On obtient une certaines confusion entre la barre des tâches pour les application et les onglets pour les sites Web. Tout ceci est beaucoup mieux expliqué sur ce blog.

Mais de plus en plus, le navigateur ne sert qu’à exécuter un plugin (Silverlight/Flash/Java) qui lui charge l’application.
L’objectif est de lancer une application Web comme une application “Dekstop”, en exécutant le dis plugin en standalone, ou de passer par un “mini navigateur” (qui ne sert que pour le rendu HTML+Ajax, sans navigation etc). C’est en tout cas ce que propose Adobe Air ou Mozilla Prism.

Il va donc être difficile de distinguer une application “Desktop” ou “Web”. Ceci me fait un peu penser aux Widgets du Dashboard sous MacOS (ou autre plagia).

Au même titre que le Web se rapproche du Bureau, les applications “lourdes” copient les techniques du Web question apparence. Il y a des tentatives d’utilisation de CSS en Swing/SWT, mais l’exemple le plus flagrant est la description de l’interface à l’aide de XML comme dans XAML.

On obtient ainsi des applications “Desktop” ne copiant pas du tout le style standard de l’OS, mais ayant son propre thème telle un site Web.

Le résultat peut s’avérer très jolie, très ergonomique, mais très “inconsistant” avec les autres applications. Pourquoi devrais-je apprendre une nouvelle interface? Pourquoi ne pas utilise un standard? Pourquoi ne pas me laisser choisir mon thème dans l’OS plutôt que de me l’imposer pour une application donnée?

Personnellement, je ne suis pas fan de toutes ces interfaces différentes, et je ne suis pas le seul.
Pour revenir sur l’OS Linux, un grand effort est fourni pour rendre les interfaces homogènes. On peut par exemple citer le projet Portland allant dans cette direction. Je peux alors apprécier ces efforts puisqu’il m’est devenu difficile de distinguer une application QT dans mon environnement GTK (essayez Skype sous Linux pour vous en convaincre).

Je voulais aussi citer Redhat comme, à mon humble avis, les pionniers en matières d’homogénéisation avec leur thème Bluecurve identique sous KDE est Gnome. D’autre projets ont suivis dans le même genre comme Tango.

Enfin, les interfaces graphiques sont en pleines évolutions ces derniers temps, avec l’exploitation des cartes graphiques récentes, offrant des “eye candy” très alléchants. Le monde GTK est en pleine réflexion pour les futures versions, et les thèmes supportent de plus en plus d’effet.
Je préfère de loin cette approche ou l’OS propose un système de thème avancé (avec des techniques proches du CSS) et l’applique à toutes les applications, rendant le tout homogène. Néanmoins, je distinguerai toujours les applications type “Widget” qui ressemblent plus à de “mini-site” ou “application Web” qui elle ont une apparence propre à elles.

Comment seront les interfaces des OS du futures? Va-t-on vers un gros bordel graphique, ou une homogénéisation? WPF va-t-il percer sous Linux? Quels vont être les applications Winforms qui vont être migré sous Linux?

Au début, il y avait le néant… puis l’informaticien inventa la page HTML! Dans sa foulé il inventa le Javascript… puis les applets Java… pas de chance, l’informaticien était en avance sur son temps…

Puis le Web s’est vu enrichir de nouveau média (Youtube, Deezer, etc.) Toute cette magie est possible grâce aux génies de Macromédia inventeurs du Flash! (racheté par la suite par Adobe)
Le web est devenu plus beau, plus fun… et plus lourd tout de même.
Flash est aujourd’hui la techno incontesté pour les médias riches. Elle était aussi en avance sur son temps: les sites entièrement Flash était encore trop lourd pour les débits de l’époque. Ce n’est aujourd’hui plus un problème, mais si tous les sites ne sont pas en Flash, je l’explique pour plusieurs raisons:
Premièrement, cette technologie était boudé par le monde Linux qui se retrouvé avec un produit propriétaire, des versions en retard par rapport à celles sur Windows, et même souvent bugguées.
Les adeptes des standards W3C ne voient pas non plus Flash d’un très bon œil et préfère se concentrer sur la norme HTML+ECMASCRIPT (autrement dit: Javascript).

C’est la que le Web 2.0 atteint son paroxysme: les sites Web d’aujourd’hui exploitent à fond le Javascript (Ajax, GWT, Scriptaculous, etc.). Cela donne des pages Web plus riches, plus interactives, plus animées, et plus légères!
Car oui, le bon vieux HTML avec un peu de Javascript c’est plus léger que du Flash. Certains dénonceront simplement les mauvais codeurs ActionScript qui sont souvent des graphistes reconvertis et qui font des choses non-optimisés…
Ceci dit, cette performance n’est possible que grâce aux effort fournis par les navigateurs Web qui supportent de mieux en mieux le Javascript.
Mais voila, les vidéos ou encore d’autres choses ne sont pas possibles en HTML+Javascript aujourd’hui, et c’est pourquoi que Flash est encore très utilisé (surtout concernant la vidéo).

C’est la que Microsoft riposte avec Silverlight et ça va faire mal.
Imaginez: un plugin similaire à Flash, mais plus performant (WPF utilisant gracieusement DirectX) avec des langages plus faciles à coder (C#, XAML, etc.) et des outils de développement/design très soignés (la série des Expression).

Mais la communauté pro-libre/pro-standard n’en reste pas la: HTML5 est censé combler les lacunes vis-à-vis de Flash ou Silverlight.

Sun veut aussi être de la partie, après l’échec des applets, il tente nous proposer JavaFX.
Les principales raisons de l’échec des applets sont:
- Java c’est gros et lourd à télécharger… imaginez un JRE de 30mo à l’époque des 56k!
- Ce n’est n’était pas non plus très performant, surtout en matière d’affichage.
- Il n’existe aucun outil pour graphiste pour faire des applets! C’est la que Macromédia avec Flash avait marqué un point.
- Ce n’est n’était pas libre… donc difficile à faire adopter par la communauté des développeurs.

Mais Sun propose des solutions:

• Java Kernel: le principe est simple, il faut que le téléchargement d’une JRE soit négligeable (tout comme Flash). Pour ce faire, l’utilisateur télécharge une version “minimale” de la JRE, qui téléchargera des paquets supplémentaires seulement s’il y en a besoin.
• Java2D/Swing plus performant, ainsi que l’accélération avec DirectX (elle existait depuis peux de temps, mais désactivé par défaut car trop buggué). Cela permet aussi des effets comme la transparence etc.
• JavaFX: ou comment créer un langage de description d’interface, pour créer plus simplement des animations etc.
• Java est open-source: à quand Java installé par défaut sous Linux? (Même si c’est maintenant un paquet officiel d’Ubuntu)

Le seul hick qui va faire très très mal: toujours pas d’outil puissant pour les graphistes.
On peut aussi se demander pourquoi avoir inventer un n-ième langage de script, là où tout le monde optent pour le XML comme descripteur d’interface.

On remarque que “Open-source” est maintenant synonyme de “standard”, et ça Adobe l’a compris. Fort se sa popularité, l’ouverture forcement va booster son engouement.
Microsoft n’est pas en reste dans ce domaine: depuis son alliance avec Novell, ils travaillent tous deux pour promouvoir .Net sous Linux même si l’équivalent à Silverlight en libre, Moonlight, est encore loin de voir le jour…
On pouvait pointer du doigt le manque de sérieux en matière de développement avec ActionScript, mais avec Flex ce n’est plus vrai.

Avec toutes ces technos, on se demande si le navigateur ne servira plus qu’a charger un plugin Flash/Java/Silverlight, et déléguera le travail de rendu à ceux la. Mozilla sonne l’alarme et explique l’importance de HTML5.

Les paries sont lancés:
Les prochains sites-web, en Flash? HTML5+Javascript? Silverlight/Moonlight? JavaFX?

Je voulais tester Cygnome en en faire mon shell par défaut sous windows…. je n’y arrive pas.

De même pour Xorg. La Warty d’Ubuntu est fournie avec XFree, mais je voulais tester les effets d’ombres et de transparences avec Xorg…. mais je dois m’armer de patience.

Bref, je passe à autre chose. Mes projets sont :

• continuer mes recherches sur lwjgl
• re-coder ma petite appli .Net à la WhereIsIt avec sérialisation XML (SOAP ?)
• re-coder mon projet de licence en .Net avec Maverick.

En ce qui concerne le serveur ASP.Net, je me suis amusé avec Apache2 couplé à Cassini (ou le serveur XPS de Mono) grâce à mod_proxyredirect ^^

Puis je ne sais pour quel raison, je teste la ligne de commande suivante :

>mono Helloworld.exe

Et hop! Le programme ce lance ! Pouvoir exécuter des applis compilées avec le framework mono ça devient de plus en plus sympa