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

juin 29, 2010 6 Commentaires

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

Classé dans Développement, DotNetServer Tag(s) associé(s) : , , , ,

Episode 2 : Mathias découvre J2EE

juin 29, 2010 5 Commentaires

En sortant de mes études, je me suis rapidement retrouvé dans le moule en adoptant Java. J’ai alors découvert les serveurs « conteneur de servlets » ou serveur J2EE, ce qui était quand même plus puissant que PHP…

Je vous ai parlé d’EASYPHP, avec lequel l’utilisateur avait une interface Web pour administrer sont serveur Apache: en 2 clicks n’importe qui peut créer un nouveau site web, sans connaitre le fameux "apache.conf"

Je suis fondamentalement contre la MMC de Windows, et je pense que IIS devrait aussi fournir une interface Web.
Encore aujourd’hui, je suis jaloux de la piètre interface de Tomcat qui permet de déployer à chaud une application web Java à distance avec une interface web, et de pouvoir gérer son cycle de vie (start/stop/reload).

Ca parait rien comme ça, mais il n’y a pas d’équivalent pour gérer les applications Web .Net, donc oui, je suis jaloux.

Tomcat n’est pas un serveur J2EE, on ne peut y déployer que des applications Web: WAR (Wab ARchive).
Mais un serveur J2EE est plus puissant: on peut y déployer des applications "service" (JAR/EAR) voir des tâches schédulées.
De plus, les applications offrent souvent des "MBean": Managed Bean. Ce sont des objets qui sont accessibles à travers une couche de service, et tout les serveurs J2EE offrent une interface Web pour les gérer.
Vous pouvez ainsi exposer la bean "HttpCache" avec le service "Clear" par exemple. Bref, c’est le paradis des admins.

Alors quand vous allez voir les pages Web d’administration de JBoss ou SpringSource, on se dit qu’il manque clairement quelque chose à la plateforme .Net.

Classé dans Développement, DotNetServer Tag(s) associé(s) : ,

DotNetServer

février 28, 2010 2 Commentaires

Comme je tarde à sortir mes posts sur les Techdays (et d’autres sujets, haha, surprise!), je vais en sortir un "tout petit".

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.
Lire la suite

Classé dans Développement, DotNetServer Tag(s) associé(s) : , , , , ,

Suivre

Recevez les nouvelles publications par mail.