Episode 6: Mathias découvre .Net!

En fait, je triche, les épisodes ne sont pas dans l’ordre chronologique.
Je n’ai pas découvert .Net après Java, mais en même temps.

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.

Episode 4 : Mathias découvre Spring (et un peu plus OSGI)

Dans l’Episode 2, je vous ai parlé de ma découverte de J2EE.
Si j’ai été émerveillé par la plateforme, j’avoue qu’elle était assez complexe.

C’est alors que la lourdeur des framework J2EE a donné naissance à une alternative qui s’est voulu plus simple : Spring.

J’aime bien Spring, je pense que vous le savez déjà :)
C’est pour moi en quelque sorte l’équivalent de l’esprit d’ALT.Net, mais en Java.

Ce fut alors la mode des IOC, et de l’approche orienté POJO. Quand j’ai découvert cela, je me suis rendu compte à quel point le framework d’Eclipse RCP pouvait être compliqué…
La gestion de dépendance et de publication/consommation de service devenaient extrêmement simple.

La ou Spring n’était qu’un framework, « SpringSource DM Server » est, quand à lui, un vrai serveur J2EE mais avec une architecture complètement différente de ses concurrents : il est basé sur le même moteur OSGI qu’Eclipse !

L’installation de nouvelles applications vous semble pénible ? SpringSource DM Server offre un « AppStore » pour installer un nouveau service et ses dépendances en 2 cliques!

Pour ceux qui ont lu mon billet sur WebMatrix, la fonctionnalité n’est pas tout à fait la même que c’elle du produit Microsoft.Vous pouvez ici installer bien d’autres choses que des applications Web: des ESB, des serveurs Web (car oui, en Java, on a le choix entre Tomcat, Jetty et autres), etc.
Vous voulez installer un serveur de Messaging ? Installer ActiveMQ en quelques cliques : http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

Vous trouvez plus d’infos sur http://www.springsource.com/products/dmserver/repository


En plus de tout ces avantages, SpringSource DM Serveur offre un interface d’administration d’un pure merveille, j’en bave quand je vois que Microsoft reste attaché à sa MMC…
Et comme si ça ne suffisait pas, SpringSource ont racheté Hyperic qui est une appli Web de Monitoring applicatif, ce qui rend l’administration de votre serveur  encore plus professionnel.

Petite conclusion:

  • l’IOC c’est cool, vive l’approche POJO
  • OSGI c’est de la bombe. Cela permet aussi bien de gérer des plugins dans un IDE, que des middleware dans un serveur d’applications
  • l’installation d’une plateforme applicative doit être simple et facile, autant que de lancer un Setup de EasyPHP ou de cliquer sur un lien d’un « AppStore »
  • vive les interfaces Web d’administration, à mort la MMC

Episode 3 : Mathias découvre Eclipse (et un peu OSGI)

Dans l’épisode 2, je vous ai dit à quel point les serveurs J2EE pouvaient être complexe dans la gestion d’application.
Il en est de même dans le monde des IDE avec la gestion des plugins.

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 ;)

Suivre

Recevez les nouvelles publications par mail.