Mercredi 12 novembre avait lieu la conférence OpenSource Exchange, organisée par Xebia et Skills Matter. C'était l'occasion de faire le point sur certaines technologies : et de "sentir" un peu les nouvelles tendances du marché.

La journée était découpée en sept séances d'une heure, animées chacune par un expert reconnu dans son domaine :

• SpringSource DM Server, par Michael Isvy (SpringSource)
• Exo Platform, par Tugdual Grall
• JEE6, par Antonio Goncalves
• Groovy, par Guillaume Laforge
• Glassfish v3 "Prelude", par Alexis Moussine-Pouchkine
• Portlets 2.0, par Christophe Laprun
• Hadoop, par Oktay Istanbullu.

Chose surprenante, malgré le programme intéressant et la facilité d'accès du lieu, sur 80 inscrits, seule une grosse quarantaine de personnes étaient présentes le matin, et une trentaine l'après-midi. On mettra ça sur le compte du pont du 11 novembre. L'accueil était quant à lui très correct, avec un petit déjeuner d'accueil, un coupon-repas pour le midi, et le traditionnel package composé d'un bloc-notes et d'un stylo aux armes de Skills Matter.

Ce billet contient le compte-rendu de la première séance sur SpringSource DM Server; les autres feront l'objet de billets ultérieurs.

SpringSource DM Server

Présentation réalisée par Mickaël Isvy, consultant sénior chez SpringSource.

Présentation

SpringSource DM Server est le nouveau fer de lance de SpringSource, la pièce maîtresse de leur nouvelle stratégie visant à se positionner sur le terrain de la productivité des développeurs (tout particulièrement face à JEE). Il s'agit d'un serveur léger, basé sur Tomcat + OSGi +Spring (le support de Jetty est prévu), dont l'objectif est de couvrir les fonctionnalités les plus utilisées sur les serveurs d'applications traditionnels.

L'adjectif "léger", toujours bien mis en évidence, est censé se retrouver à la fois côté développement et côté production. Côté développement grâce à une empreinte mémoire réduite, un démarrage quasi-instantané et la possibilité de recharger indépendamment les différents modules composant une application (grâce à OSGi) ; côté production, grâce aux services "enterprise" couvrant le monitoring, le déploiement automatisé sur une grille de serveurs, la mesure de performances...
L'installation du produit est simple : téléchargement, décompression, déclaration des variables d'environnement. Le seul prérequis est Java 5+.

Contrairement au framework Spring, sous licence Apache, DM Server sera publié sous licence GPL3. A ce propos, il est amusant de noter le côté pédagogique du site sur ce sujet, afin d'éviter les réactions épidermiques des DSI et des départements Achats mal informés:

Q : Does the GPL force me to release my own code if I run it on the SpringSource dm Server?
A : No. GPL requirements are only triggered upon distribution of code. Under the terms of the GPL, you are only required to release software under GPL if :
- You distribute (the GPLv3 uses the word “convey”) the software. This is clarified and narrowed in GPLv3 which specifically states that “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.” AND
- You modify the software or create a “derivative work”. The definitions for modification and derivative works can be complicated and should be reviewed by legal counsel.

Hello World : module web

Michaël nous a ensuite fait une démonstration pratique du produit, à travers le traditionnel Hello World, version web.

DM Server est apparemment déjà bien outillé, et le plugin Spring IDE d'Eclipse a été complété avec toute une palette d'outils comme un wizard de création de projet, une assistance pour la rédaction des manifestes OSGi, etc. Michaël a donc pu nous faire une démonstration live très facilement.

Lors de la création d'un nouveau projet de type "web bundle", il suffit de remplir le nom du projet, le contexte racine sous lequel l'application sera déployée et accessible, ainsi que le pattern de mapping pour le front-controller de Spring MVC. Ces informations servent alors à générer le manifeste OSGi du bundle, ce qui est habituellement fastidieux. Mais alors, quid du descripteur web.xml standard ? Il est désormais facultatif, et principalement utilisé pour surcharger des valeurs par défaut, par exemple pour configurer un framework web différent (Struts...).
Mickaël est resté sur la configuration par défaut, et le développement du contrôleur et de la JSP associée fut très classique : utilisation de l'annotation @Controller, quelques déclarations dans un fichier spring, et le tour était joué. Le lancement du serveur et le déploiement de l'application ont été réalisés à l'aide de la vue "server" classique d'Eclipse.

Un point important à noter est la gestion des librairies du projet, qui s'effectue par l'intermédiaire du manifeste OSGi. Toutes les librairies utilisées dans un contexte OSGi doivent êtres "OSGi-fiées", c'est-à-dire comporter le manifeste adéquat et répondre à certaines contraintes, ce qui peut constituer un frein sévère à l'adoption de cette technologie. SpringSource maintient aujourd'hui un repository de librairies opensource contenant déjà les plus utilisées (log4j, commons-*, etc.), et s'engage à adapter toute librairie dont les développeurs auraient besoin sur simple demande.
Cet engagement se veut rassurant, mais laisse quand même planer le spectre du "vendor lock-in" et limite potentiellement la liberté et la réactivité des équipes de développement, dépendantes de l'existence de versions "OSGi-fiées" des librairies qu'ils utilisent. A voir si les architectes et les DSI accepteront cette contrainte.

Un second point intéressant concerne la structure du projet :

• Par convention, les descripteurs spring sont placés dans le répertoire /META-INF/spring/
• Le contenu de l'application web est placé dans le répertoire /MODULE-INF/. Il suffit de mettre dedans ce que vous mettez d'habitude dans un répertoire "war" ou "webapp" dans votre environnement de développement : css, javascript, le répertoire /WEB-INF, etc.

Hello World : couche de service

La seconde démonstration se basait sur la première, et visait à présenter le développement d'un bundle non-web contenant la couche de service. Rien de particulier au niveau du code : après utilisation d'un wizard pour créer le projet, Mickaël a défini une interface de service simple et développé son implémentation.

Ce qui était intéressant en revanche, était la réflexion autour de l'exposition des services et des classes.
Dans un projet standard bien conçu, un service possède une interface publique et une implémentation privée, le but étant naturellement de protéger le code appelant des changements d'implémentation potentiels. Mais en pratique, pour des raisons d'organisation des packages, d'ouverture aux tests unitaires, etc., les classes d'implémentation sont toujours déclarées publiques. Rien n'empêche alors un développeur mal intentionné et/ou peu scrupuleux d'instancier directement la classe d'implémentation, ce qui constitue un risque important pour la sécurité et la maintenabilité du projet.
OSGi permet de résoudre ce problème : chaque bundle se comporte comme un univers indépendant et fortement encapsulé, qui expose uniquement ce que le développeur a explicitement déclaré comme étant accessible.

En pratique, cela signifie que chaque package java que le développeur souhaite exposer doit être déclaré grâce à la directive Export-Package dans le manifeste du bundle. On peut ainsi n'exposer que les packages contenant les interfaces des services, et pas ceux contenant leurs implémentations. Inversement, les bundles clients doivent utiliser la directive Import-Package pour y accéder.
Une fois ces problèmes de visibilité de packages inter-modules résolus, l'utilisation du namespace osgi dans les fichiers de configuration spring permet de définir, importer, exporter et injecter facilement des service (autrement dit, des beans) d'un module à l'autre : Spring se charge de créer les proxies nécessaires.

Encore une fois, le bundle a été déployé via la vue server d'Eclipse, en parallèle du bundle web. Le code du contrôleur du bundle web a été ensuite modifié de manière à faire appel à la couche service, puis également redéployé.

Gestion du cycle de vie des bundles

Un des gros avantages de SpringSource DM Server tient justement à la modularité des applications. Le fait de pouvoir déployer, démarrer et arrêter les bundles de manière indépendante accélère considérablement le cycle développement / déploiement / test, augmentant ainsi la productivité du développeur. La prise en compte à chaud, dans l'environnement de développement, des modifications effectuées sur le code y participe également.

En revanche, la question épineuse de la gestion des dépendances inter-bundles se pose désormais. Dans quel ordre les lancer ? Si on redéploie un module, faut-il relancer ceux qui en dépendent ?
DM Server semble résoudre cette question élégamment :

• Un mécanisme de timeout est mis en place lors des appels inter-modules. L'indisponibilité temporaire d'un module (par exemple, s'il est en cours de redéploiement), n'est donc pas gênante : dès qu'il sera de nouveau disponible, la reprise des appels sera automatique.
• Un nouveau format de packaging a été créé : le PAR (Platform Archive). Contenant tous les bundles composant l'application, il est capable de calculer leur graphe de dépendance et de les déployer dans le bon ordre. Il permet également quelques réglages niveau applicatif, notamment la centralisation des logs.

Conclusion

La présentation était intéressante, et très pragmatique. SpringSource DM Server semble avoir beaucoup de potentiel, même s'il doit encore faire ses preuves en environnement réel.
Mais je trouve certains points très intéressants, notamment l'encapsulation des dépendances, qui permet d'éliminer tout risque de conflit entre plusieurs versions d'une même librairie, et la modularisation réelle des applications, qui me semble intéressante d'un point de vue architecture logicielle.

L'outillage et la documentation semblent très complets également, ce qui renforce le sentiment de qualité. A tester, donc.

Note : merci à Michaël Isvy de m'avoir fourni les slides de sa présentation (PDF, 580ko) !