Cette simplicité n’est pas toujours positive, on peut même dire que Microsoft est “maudit” par ce fléau: rester attractif pour les développeurs débutants.

En général, cela donne des frameworks “sales” avec un fort couplage du code métier avec les interfaces, impossible à tester unitairement bien sûr.

Pour pouvoir découpler tout cela, on distingue 3 couches:

• L’interface, appelée “view” ou “presenter”, c’est le moyen d’afficher l’information
• La logique métier, appelée “model”, c’est ce que l’on va pouvoir tester à l’aide de tests unitaires
• Les actions ou commandes, qui représente une action de l’interface par l’utilisateur qui va déclencher un traitement

Mais quand on sépare les responsabilités en plusieurs objets, on se retrouve avec un nouveau problème : comment coupler les vues, contrôleurs, etc. ? Comment “broker” les actions ?

Il y a une solution à cela: l’IOC. On peut dire aussi que le Databinding en est une autre.
Si Microsoft avait un train de retard sur les Framework IOC, ils connaissaient néanmoins déjà le problème depuis un moment, puisqu’ils l’avaient en partie résolu dans CAB.
C’est donc sans surprise que Microsoft nous livre son framework d’IOC “officiel” basé sur l’existant de CAB : Unity.

A la sortie d’Unity, j’étais déjà tellement convaincu par Spring.net que je n’ai jamais adopté le framework de Microsoft. De plus, les alternatives OpenSources étaient  bien présentes: Castle Windsor, Ninject, Autofac, etc.

A noter que les framework tel que CAB/RCP rendent vos clients lourds “extensibles”, ce qui veut dire qu’un plugin va pouvoir greffer de “vues” dans l’interface, et s’abonner aux “commandes”: chose tout à fait faisable avec de l’IOC.

Mais les frameworks IOC ne font pas tout, et ne suffisent pas à fournir une véritable architecture MVC pour client lourd, même s’ils peuvent nous y aider (voir mon poste précédent).

Pour résoudre le fléau du couplage fort entre l’interface et le code métier, Microsoft a sortie quelque chose de révolutionnaire: WPF et Silverlight!
Avec la venue de WPF et Silverlight, la communauté .Net OpenSource a commencé à se pencher alors sur le problème du MVC pour les applications lourdes. Divers frameworks apparaissent alors, comme Prism: http://compositewpf.codeplex.com/

Mais le MVC, comme on le connait dans le monde Web, ne s’applique pas bien aux clients lourds, surtout si on veut exploiter le Databinding et les événements.

Très franchement, je ne me suis jamais vraiment passionné pour WPF/Prism/etc. mais je voyais bien que quelque chose de gros était en train de venir…
J’ai ensuite assisté aux Techdays 2010 et j’en ai profité pour me mettre à jours sur le sujet.
Les sessions étaient d’ailleurs très accès sur Silverlight/WPF mais aussi sur le nouveau modèle MVVM (Model-View-ViewModel), et avec une bonne dose d’Unity bien sûr…
J’ai alors été très agréablement surpris par ces présentations, surtout celle qui montre comment supprimer tout le « code behind » des interfaces XAML avec des ViewModel et des Commands.

Pour mieux comprendre de quoi je parle, aller voir vite le screencast ici!!!

Bref, je ne sais pas si vous me suivez, mais l’IOC, le RCP, le MVC, la gestion de plugins, tout ça c’est intimement lié !

Petit à petit, .Net rattrape le retard vis-à-vis d’Eclipse RCP !
On peut même dire que .Net a pris de l’avance avec Silverlight/WPF, puisque la rédaction des interfaces en XML n’est qu’au stade de proposition pour Eclipse 4: http://wiki.eclipse.org/images/a/ab/XWT.pdf

C’était le 6 Janvier 2005, j avais blogué à ce sujet: j’avais découvert qu’avec Mono, il était possible d’exécuter un même programme EXE sous Windows comme sous Linux ! J’en avais la larme à l’œil…

Ce qui m’a le plus impressionné c’était de voir qu’il était possible d’exécuter du Java dans .Net grâce à IKVM ! Cela marchait tellement bien qu’ils ont réussi à exécuter Eclipse sous .Net ! Mais ce n’était qu’expérimental à l’époque…

En découvrant .Net, j’ai tout de suite pris conscience du retard par rapport à Java, et j’ai alors voulu m’y atteler.
J’ai alors commencé à réaliser un framework « RCP » comme celui d’Eclipse, mais full .Net. Voici le résultat à l’époque :

On pouvait réaliser des plugins qui fournissent des vues qui s’encrent dans différents endroits, que ce soit dans la fenêtre principale ou dans un onglet d’édition.
J’en était plutôt fier, encore aujourd’hui… j’ai bien envie de le porter avec les technos modernes d’aujourd’hui…

C’est aussi à cette époque que j’ai découvert Spring, et au même titre Spring.Net, que j’ai utilisé dans mon entreprise pour réaliser, avec Romain, un framework MVC Winforms.

J’ai aussi découvert d’autres framework IOC, et par la même occasion CAB de Microsoft (Composite Application Bloc), mais sans en être convaincu.

A l’époque, on commençait à parler d’OSGI, mais je n’avais pas assez de connaissance dans le domaine

En conclusion, je restais sur ma fin avec .Net, et j’en étais même frustré. Mais j’ai toujours été convaincu que c’était aussi “une terre d’opportunités” et que je pouvais faire quelque chose…
L’IOC, le MVC pour client riche, RCP, OSGI… les idées émergeaient déjà, mais n’était pas matures.

Tout en étudiant J2EE, je suis tombé amoureux de mon IDE Java préféré : Eclipse. Pas seulement pour sont utilisation, mais aussi pour son architecture.

En effet, la réalisation de plugins pour Eclipse se fait de manière ultra puissante. A tel point que le « noyau » d’Eclipse peut être complètement extrait pour faire sa propre application qui n’a rien à voir avec un IDE : c’est le framework RCP (Rich Client Platform).
J’ai d’ailleurs à l’époque réalisé une application RCP pour la gestion de budget d’achat de livres pour les bibliothèques.

Malheureusement, la pauvreté des composants graphique en Java faisait du tors à cette plateforme.
Mais je restais subjugué par le moteur de plugins :

• Les plugins sont isolés afin que si un plugin crash, les autres continuent leur vie
• Les plugins sont aussi isolé coté sécurité : un plugin ne peut pas accéder aux codes d’un autre plugin si ce dernier ne l’a pas explicitement rendu « publique »
• Les plugins peuvent publier et consommer des services, avec un model très élégant
• Il y a une gestion de dépendance entre les plugins, avec la prise en compte des versions
• L’installation et la mise à jour des plugins se fait d’une simplicité déconcertante

En fait, si la gestion des plugins est si balaise c’est car elle provient d’un standard de « développement par composant » : OSGI.

L’alliance OSGI est un organisme de personnes qui se mette d’accord ensemble sur des specs concernant les frameworks OSGI. C’est encore la que Java écrase .Net par sa maturité : il n’y a pas de monopole, il y a bien plusieurs acteurs derrière un « standard » ouvert qui va connaitre de multiples implémentations.

OSGI est donc un framework complexe de gestion de « modules » qui exposent des « services ». N’hésitez pas à lire le WIKI qui explique ça très bien : http://en.wikipedia.org/wiki/OSGi

En conclusion, Eclipse est une plateforme riche en plugins grâce au coté Open-Source de l’IDE, à l’API de plugins très bien faite mais aussi à l’aide du plugins pour développer des plugins

Qu’en est-il du coté .Net? VisualStudio a-t-il le même succès concernant le développement ce plugins? Offre-t-il une architecture de plugin aussi puissante? On verra ça dans un autre épisode

Cloud Computing: introduction avec Azure et Amazon

Grâce à la présentation chez Fastconnect par Romain, j’ai pu découvrir les joies de Azure. C’est la solution Cloud de Microsoft qui est bien sûr très orientée .Net + VisualStudio.

On parle ici de “Plateform as a Service” puisque Azure nous offre de quoi héberger nos applications (web ou service) à l’aide d’une architecture “cloud”.
On développe des applications qui effectuent des calcules distribués sur X machines, ou on héberge X sites web ASP.Net dont la charge est répartie entre eux.
En plus d’offrir une architecture “scalable”, on a droit à certains services “bas niveau” comme le service de stockage de données binaires (full REST), une queue ou un stockage “à la BigTable“. On peut ensuite bénéficier de services plus “haut niveau” comme “Live Search” ou “Live Calendar“.

Par comparaison, Amazon avec EC2 propose un service “Cloud” orienté “Hardware as a Service” car on loue ici à des machines virtuelles, vierges ou avec des choses pré-installé (comme Linux Apache Msql PHP). La puissance de ces machines est aussi “scalable” à la demande, et on ne paie que ce que l’on utilise.
A la différence d’Azure, où la partie “Hardware” est complètement masquée (IIS7, WindowsServer2008, etc.). Azure offre une interface web d’administration pour surveiller l’utilisation du CPU ou de la mémoire, et on peut rapidement changer le nombre d’instances d’un site web à la demande.
Ceci dit, Amazon offre aussi des couches techniques comme le service de stockage Amazon S3.

Bref, le Cloud ce n’est pas qu’un hébergeur de site web ou une Dedibox, c’est surtout le fait de bénéficier des serveurs des gros mastodontes tel qu’Amazon ou Microsoft pour louer la puissance dont on a besoin, et profiter d’applications et de services pré-installés utilisables tout de suite. C’est aussi la possibilité d’utiliser des services techniques (Database, etc.) ou haut niveaux (Map, Calendar, etc.).

Nouvelle solution de Cloud avec Aptana

Azure offre de quoi développer un site ASP.Net Scalable rapidement, mais je vais faire le chieur en voulant développer une application Rails sous Eclipse!

C’est la que j’ai découvert Aptana Cloud.

La solution d’Aptana est la suivante :

• Comme Azure, Aptana masque la complexité et l’installation des machines virtuelles. On a donc du “Plateform as a Service”. On a droit à une machine pré-installée avec Apache, MySQL, SFTP, SSH, SVN, etc.
• Comme Azure, Aptana offre un IDE (Eclipse) avec un grand nombre de plugins pour développer, déployer et administrer le Cloud rapidement et facilement.
• Comme Azure, Aptana offre une interface Web pour gérer sa machine, la puissance consommée et ce que ça nous coûte en fin de compte. Aptana fournit aussi la possibilité d’héberger un site en “staging mode”, puis quand on est sûr de soi, on a la possibilité de le basculer en “public mode”.
  
• Comme Amazon, la puissance et les prix sont scalables: on ne paye que ce dont on a besoin et on peut changer la puissance à la volé (le site indique $20 par mois, c’est parce qu’une machine de 256mo de RAM avec 5GB de disque coûte $0,027/heure)

Les points négatifs :

• Pas d’architecture applicative “scalable”: contrairement à Azure qui permet de changer en 3 clicks le nombre de processus ou le nombre d’instances d’un site. On dépend ici de la scalabilité de la machine virtuelle. Aptana est en partenariat avec Joyent qui héberge ces machines.
• Pas de services “haut niveau” comme ceux de Google (Google Maps, Google search, etc.) ou de Microsoft (Live Calendar, etc.). Mais rien ne nous empêche de les utiliser…
• Services bas niveau limités: MySQL est OK, mais si l’on a besoin d’un stockage performant et distribué, on utilisera en plus les services d’Amazon (S3) ou Google (BigTable).

Voici pour moi les PLUS d’Aptana:

• Plugins Eclipse de qualité avec un éditeur HTML/Javascript bien meilleur que celui par défaut (de WTP)
• Permet de faire des applications HTML classiques, PHP, Rails, Java, mais aussi Python, Adobe AIR, iPhone, Nokia WRT.
• En quelques clicks dans le Wizard de création du projet, permet de choisir des frameworks Ajax parmi les plus connus (jQuery, Dojo, ExtJS, et j’en passe).
• Fournit une documentation riche à l’aide de vidéos sur Aptana TV.
• Offre un nouveau type de développement full HTML+Javascript : Jaxer.

En résumé, Aptana offre mieux que de simples machines virtuelles :

• un IDE puissant pour développer différents types d’applications
• des machines virtuelles scalables pré-installées pour déployer dessus
• une interface claire pour les administrer (statistiques, etc.)

Le Cloud donne des idées, et Aptana est une solution qui m’a l’air bien sérieuse. Je me suis laissé séduire grâce à l’offre d’essai gratuite, et je pense qu’à l’avenir j’utiliserai ce type de solutions si je veux développer et héberger un site Web.

J’ai cité Jaxer dans les PLUS de la solution d’Aptana, mais j’en parlerai dans mon prochain billet