Je vous le dis simplement : hier soir vous auriez dû venir. Oui vous auriez vu tout d’abord un phénomène assez curieux. Arrivé à 19h30 je retrouve Antonio à l’extérieur, et à cet instant il n’y a pas encore beaucoup de monde. Avec 189 inscrits, Antonio préfère prendre les devants et demande une salle plus grande. A 19h50 c’est encore calme, une trentaine de personne. A 20h00 il y a plus de 100 personnes… A 20h15 la salle est presque complètement remplie. 189 inscrits sur le site du PJUG. Du coup Jean-François Hélie (Octo) et Christian Blavier (Octo) sont un peu impressionnés devant tout ce monde.
Les thèmes de la soirée : Spring Test Driven Development présenté par Octo, puis ensuite présentation de Spring Source, Spring Security 2 et de SpringSource Application Platform par Julien Dubois et Michaël Isvy de la société SpringSource France.
Après une introduction par Antonio, qui rappelle l’importance des sponsors pour le ParisJUG, Jean-François Hélie et Christian Blavier s’installent pour la démonstration du développement piloté par test sur Spring 2.5. Test Driven Development en anglais dans le texte.
Le projet sera le suivant : écrire en 45 minutes une application de Blog simple capable de lister et poster des articles. Jean-François est aux commandes d’Eclipse sur son MacBook (yeah Mac rulez…) et Christian fait les commentaires. Jeff a réalisé un exercice loin d’être évident devant tant de monde : il a codé sous nos yeux l’application en appliquant simplement les principes du TDD.
Christian explique que l’on commence par un test JUnit qui nous sert de cahier des charges. Dans ce test, le nom de la méthode exprime l’intention que l’on souhaite développer. En l’occurrence pour ce premier test, une méthode « shouldListArticles » si ma mémoire est bonne. Pour cela, Jean-François implémente un BlogDAOTest dans lequel il place son premier test. Ce que l’on voit est très technique. Un interlocuteur dans la salle qui n’est pas développeur décroche forcément. En même temps je me dis que c’est un excellent moyen de montrer à une personne peut-être moins technique cette méthode d’implémentation pilotée par les tests.
Impossible ici de reprendre le code complet de Jean-François. En une petite heure il aura écrit un DAO, un bean BlogService et son test et enfin un BlogController avec son test. L’accès à la base de données Hypersonic s’effectue à travers Hibernate. La partie rendu web est gérée par Spring MVC.
Du côté des tests, nous avons vu que Spring permet d’alléger la quantité de code à écrire, en particulier dans la partie « plomberie ». Quelques annotations comme @InjectIntoByType, @Mock, @TestedObject, @Service ou @Repository permettent de marquer le code et d’écrire des tests d’intégration simplement.
Nous avons vu l’utilisation de bouchon dans les tests. Jean-François parle d’Unitils (http://www.unitils.org/). Cette librairie open-source de tests unitaires facilite l’écriture de tests unitaires et d’intégrations. En particulier lorsque vous souhaitez tester des DAO sans faire d’accès à la base de données.
Durant la présentation, je pense à Seam. En fait je m’imagine à la place de Jean-François entrain de réaliser exactement le même exercice avec Seam Framework (JBoss Seam). La chose qui manque pour l’instant à Spring c’est une couche de rendu Web plus puissante. C’est ce qu’offre déjà Seam avec l’intégration d’IceFaces et de RichFaces, ainsi que de Facelets pour la gestion propre des pages. Cependant Julien Dubois expliquera plus tard dans la soirée qu’il y a des projets chez Spring afin d’y intégrer un moteur Ajax puissant d’ici à la fin de cette année. J’ai vu que Spring Web Flow propose une intégration avec JSF, ce qui en fait répond à mes interrogations.
En conclusion pour cette partie, avant tout bravo à Jean-François et Christian. La présentation était pointue, concrète et donne envie de suivre ce chemin pour l’implémentation d’applications webs autour de Spring 2.5
Après un petit break d’une quinzaine de minutes où j’ai croisé pas mal de monde, Julien Dubois et Michaël Isvy de SpringSource ont pris la parole. Julien est responsable de SpringSource pour la France et membre de l’OSSGTP. Il est aussi le coauteur de « Spring par la pratique » aux éditions Eyrolles dont j’ai parlé dans plusieurs articles sur le Touilleur. Michaël Isvy est formateur et consultant chez SpringSource, ainsi que contributeur sur Spring Security 2.
Spring c’est 2.5 millions de téléchargement par mois. Les offres d’emplois avec « Spring » dépassent les offres purement J2EE aux USA. Julien résume assez bien la philosophie de Spring : « dites-nous de quoi vous avez besoin, nous vous le fournirons » qui tranche un peu avec « voilà tout ce que vous pouvez faire, à vous de ne prendre que ce dont vous avez besoin ». D’ailleurs un excellent petit clin d’œil aux « vieux » éditeurs J2EE qui vivent d’une rente établie en 2000 avec l’architecture J2EE EJB 2.1. J’ai vu deux personnes de BEA dans la salle qui rigolaient et qui donc semblaient d’accord. Et j’ai gagné un superbe tee-shirt dans la série questions-réponses sur Spring.
Ce matin sur Monster.fr j’ai fait un test assez simple. J’ai tapé simplement un mot clé sur la zone de recherche et j’ai listé les résultats.
Dites-moi ce que vous en pensez :
Mot clé Nombre d’offre d’emplois affichés :
Spring..............145 EJB..................84 Seam..................1 JBoss................83 J2EE................634 Websphere...........201 TDD...................2 RIA..................11 Weblogic............157 .NET................600 Java...............1097 C++.................609 Scrum................17 Agile................48
Source: Le Touilleur Express sur Monster.fr mercredi 11 juin 2008
Premier constat : il y a plus d’offres d’emploi contenant le mot clé Spring que le mot clé EJB sur Monster.fr. On constate que Java arrive en tête devant .NET, ce qui me rassure et me fait très plaisir. J’aime bien .NET mais si vous voulez, mon truc c’est plutôt Java.
Après la présentation de la société SpringSource, qui assure des formations, du support et des missions de consulting en France, Michaël Isvy présente Spring Security 2. Première information pour moi, béotien de Spring pour l’instant, c’est que Spring Security 2 était connu sous le nom de… Acegi Security 1.0. Spring Security 2 c’est donc Acegi 2 si vous voulez.
Ce module de Spring couvre les manques de l’architecture J2EE actuelle sur la sécurité sans cependant introduire des dépendances avec un serveur d’application. Spring Security est développé par Ben ALEX et Luke TAYLOR. La version 2.0.2 est sortie le 5 juin dernier. Parmi les fonctionnalités de Spring Security j’ai noté
– support de l’authentification par cookie
– possibilité de bloquer 2 authentifications simultanées avec le même profil
– Support d’OpenID (Google, SUN, IBM…)
– Support de la JSR 250 (EJB3) et donc de la partie sécurité des EJB 3.
– WS-Security pour les Web Services
Voir le site pour plus de détails : http://static.springframework.org/spring-security/site/
Nous avons vu quelques exemples qui donnent envie de s’intéresser à Spring Security 2 pour les applications webs.
Ensuite Julien a présenté SpringSource Application Platform. Il s’agit d’un moteur d’exécution (PAS d’un serveur d’application) basé sur Tomcat, Spring et OSGi. Il permet de faire fonctionner une application Spring en utilisant le moteur de modules d’OSGi. D’ailleurs j’ai noté un jeu de mots de julien « OS-JEE-Aïe… » pour OSGi.
A mon sens c’est une grosse annonce, un gros projet et qui va faire bouger l’écosystème des éditeurs J2EE. S2AP (SpringSource Application Platform) a décidé de prendre le système de modules d’OSGi car celui-ci est mature et c’est ce que le marché demande.
Julien Dubois explique ensuite qu’entre les membres d’OSGi et les membres de la JSR 277, il y a des discussions assez franches. La spécification JSR 277 porte sur Java Module System. La JSR 316 de JEE6 regroupe 27 spécifications comme l’explique Antonio. Les discussions portent sur le fait qu’OSGi qui est aussi une JSR et la JSR 277, certaines parties sont identiques. OSGi est déjà en production puisqu’Eclipse s’en sert alors que la JSR 277 est encore en phase de définition. Julien explique que le Java Community Process (JCP) n’est pas le seul groupe à avoir le droit de faire des spécifications contrairement à ce que l’on pense. La fondation OSGi est aussi autorisée à proposer ses propres spécifications. C’est ce qu’elle a fait avec la JSR 291 justement… Et cela provoque des frictions entre les 2 groupes d’expert de chacune de ces 2 JSR.
SpringSource Application Framework met un coup de pied dans la fourmilière. Sa licence GPL v3 provoque des débats riches et passionnés dans la communauté Spring. Julien explique cependant que même si la licence est GPL v3, une application web déployée sur le conteneur S2AP n’est pas obligée de devenir GPL à son tour. C’est clairement expliqué dans la GPL v3. Un site internet qui tourne sur un serveur GPL v3 n’est pas obligé d’être lui-même en GPL. Par contre, un développement pour ajouter une fonction particulière à un serveur d’application ne pourra pas être propriétaire et doit être rendu à la communauté open-source. J’avoue que je suis perplexe mais que je pense que tout ceci est plutôt positif pour nous, en tant que développeur et intégrateur. N’étant pas moi non plu avocat, je ne m’avancerai pas trop dans le débat pour l’instant.
Sinon pour continuer, j’ai lu sur InfoQ que l’an passé, Sun a voté contre la JSR-291 (OSGi) et propose de prendre la JSR-277 qui quoique plus ancienne, est encore en phase béta. La JSR-291 est en production, la 4ème implémentation de référence est disponible. Si vous codez avec Eclipse, vous vous en servez sans le savoir. Cependant Sun (enfin une partie de Sun) soutient la JSR-277 car celle-ci propose une modularisation au niveau de Java SE lui-même, là où la JSR-291 se présente comme un module fonctionnel à la maven en quelques sortes. Il semble aussi que les membres de l’OSGi sont assez inquiets ou furieux que la JSR-277 ne reprenne pas stricto sensu leurs idées déjà implémentées dans OSGi…
J’imagine que si l’expert group de JPA n’avait pas travaillé avec Hibernate, que la spécification WebBeans n’était pas la suite de SeamFramework, nous aurions les mêmes discussions animées. Mais au-delà de ces discussions, le fait que Spring propose en plus maintenant un vrai serveur basé sur OSGi fait que l’on risque un schisme entre les pro-JSR277-SUN et les pro-JSR291-OSGi-Spring…
Les dernières discussions chaudes du côté de la JSR-277 : Peter Kriens membre de la JSR-277 explique que SUN pilote dans son coin cette spécification et que l’Expert Group de la JSR est là pour valider à postériori, sans aucuns débats. Il explique que la proposition des modules Java (JAM) n’est pas une bonne proposition et qu’il serait plus logique de reprendre les propositions de la JSR-291… Ambiance…
(voir http://www.infoq.com/news/2008/05/jsr277-osgi)
Bon pour revenir à nos moutons, car là je m’éloigne, Julien a expliqué que S2AP propose un système modulaire (OSGi donc) qui permet à un développeur de ne redéployer qu’une partie de son application. Par exemple il sera possible de ne mettre à jour que le Contrôleur d’une application Web, sans devoir mettre à jour le reste de l’application. Cela répond à des besoins exprimés par les développeurs : facilité de déploiement, moins d’attente et possibilité en production de changer à chaud qu’une partie de l’application. En effet c’est un vrai cas industriel, même si les développeurs dans la salle semblaient sceptiques. Bon j’avoue que chez nous c’est encore l’âge de pierre, et que l’histoire de ne changer qu’une partie de l’application, j’attends de voir. Certains développeurs fonctionnels ne savent pas se servir de Weblogic ou compiler en mode « exploded » pour travailler avec un JBoss. Par contre je vous explique une chose : ils vous mettent une petite claque en finance et en modélisation des données du marché. Donc chacun son boulot. Mais du coup, j’avoue être sceptique pour l’histoire de « je ne déploie qu’une partie de mon code qui a changé » même si cela semble plus simple. Julien explique que nous pourrons arrêter à jouer à la sauce de JAR dans le WAR pour faire tout et n’importe quoi.
La beauté de S2AP est qu’il n’y aura pas de dépendances dans notre code sur OSGi. La complexité d’OSGi est gérée par S2AP. Nous nous concentrons sur le code métier et pas sur la plomberie. « Dites-nous de quoi vous avez besoin et on s’en occupe ».
Je passe une discussion sur JEE 6 et les 3 profils (A, B et C). Mais clairement S2AP vise la compatibilité avec les profils A et B de JEE6, pas le profil C qui contient des dinosaures comme EJB 1 et 2/x.
La béta 6 de S2AP est disponible et SpringSource annoncera la sortie de la version 1.0 très bientôt. Malgré mes clins d’œil pour que Julien lâche une date, il a répondu « désolé Nicolas, tu ne pourras pas bloguer dessus ce soir… ».
En même temps avec la tenue aujourd’hui et demain de SpringOne à Anvers, je pense que nous devrions avoir une petite annonce très bientôt !
Pour plus d’informations :
http://www.springsource.com/products/suite/applicationplatform
J’ai noté ensuite les questions/réponses mais nous sommes plus dans le débat qu’une vraie discussion de fond. Je crois qu’il faudra que je vous présente les idées d’OSGi dans un prochain article car il y a pas mal de choses à dire.
Pour faire simple et expliquer OSGi : les modules sont la représentation à l’exécution de ce que Maven2 propose à la compilation. Un package applicatif qui tourne dans un moteur OSGi isole ses dépendances de ses voisins. Chaque partie de votre application web pourra par exemple utiliser sa version d’un parseur XML sans problèmes.
Sur ce je vous laisse, je crois que je vais finir par acheter un Pulse SmartPen de LiveScribe.com pour prendre des notes.
0 no like
