IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Compte-rendu des Rencontres Spring 2008

Le 13 Novembre 2008 à Paris La Défense s'est déroulée la première édition des Rencontres Spring. Celles-ci sont nées d'un partenariat entre SFEIR et SpringSource. Ces conférences furent animées par de grands noms :

  • Juergen Hoeller, principal développeur de Spring
  • Mark Thomas, principal contributeur au projet Apache Tomcat
  • Peter Cooper-Ellis, vice president of engineering chez SpringSource
  • Guillaume Laforge, chef de projet de Groovy
  • Julien Dubois, directeur régional de SpringSource France
  • Didier Girard, directeur technique de SFEIR

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Le 13 Novembre a eu lieu à la Défense à Paris, la première édition des Rencontres Spring. Celles-ci sont le résultat d'un partenariat entre SFEIR et SpringSource.

Cet évènement fut l'occasion de rencontrer diverses personnalités Spring tels que Juergen Hoeller (le développeur de Spring), Mark Thomas (le principal contributeur de Tomcat), Peter Cooper-Ellis (vice-president of engineering de SpringSource) ou encore Guillaume Laforge (chef de projet de Groovy).

Concernant ce dernier, ce fût de plus l'occasion de discuter de l'acquisition de G2One (Groovy / Grails) par SpringSource.

II. Conférences

Keynote

Pourquoi Spring ?

Orateur : Didier Girard
Fonction : CTO SFEIR

Les conférences se sont ouvertes sur la keynote de Didier Girard qui a tenté de mettre en avant les raisons en faveur de l'utilisation de Spring.

Les premiers avantages de Spring sont bien connus : L'inversion de contrôle et l'AOP.
Si, historiquement, c'était sans conteste un gros avantage de Spring par rapport à J2EE, cette différence n'est plus aussi franche, JEE proposant maintenant lui aussi l'IoC et un support de la Programmation Orientée Aspect.

Mais alors pourquoi Spring ?
Pour répondre à cette question, Didier nous a fait un rappel du fonctionnement d'une application JEE.

Une application JEE se base sur les spécifications JEE qui sont un standard et censées permettre l'indépendance entre l'application et le serveur JEE.

Mais en pratique, une dépendance existe tout de même. Sans entrer dans le débat d'une dépendance technique, Didier nous prouve l'existence d'une autre dépendance par le biais de l'équipe de la production.

En effet, la production est par définition " conservatrice ". Une fois un système installé, testé et éprouvé par leur soin, elle va tout faire pour le garder tel quel le plus longtemps possible. Résultat: même si de nouvelles spécifications arrivent (JEE 5 par exemple), la production va tout faire pour bloquer le changement. La conséquence est que l'équipe de développement continuera à travailler sur l'ancien serveur et ne bénéficiera pas des apports de la nouvelle spécification.

Et c'est la que Spring apporte une solution intéressante !
En effet, dans le cadre d'une application Spring, c'est l'application qui apporte le " conteneur ". Par conséquent, utiliser Spring 2.0 ou Spring 2.5 est totalement transparent pour la production. Celle-ci ne s'opposera donc pas à une migration vers une version de Spring qui permettrait à l'équipe de développement d'être plus productive.
En pratique ce changement devra tout de même être validé par l'équipe d'architecture, mais en général cette équipe est propice au changement aussi.

Téléchargez les slides de la présentation (pdf)

Connaissez-vous SpringSource ?

Orateur : Julien Dubois
Fonction : Directeur régional SpringSource France, co-auteur de Spring par la pratique

Julien Dubois a ensuite pris la parole en tant que Directeur régional de SpringSource en France. Il a profité de la conférence pour annoncer officiellement la nouvelle version de son livre Spring par la pratique, qui paraitra début 2009.

Concernant SpringSource, Julien a rappelé que SpringSource est la société distribuant les projets Spring (Spring Framework, Spring Batch, Spring Security, ..), et possède des employés à travers le monde : USA, UK, Pays Bas, …
SpringSource SARL, la filiale française, étant quant à elle présente en France depuis avril 2008.

Mis à part les projets du portfolio, le business de SpringSource est fortement basé sur le support.
Tout d'abord, tous les clients du support accèdent automatiquement à divers produits commerciaux : monitoring, environnement de développement,…
De plus, en cas de problème, ils ont un contact direct avec les bonnes personnes (commiters sur le projet Spring posant problème) en cas de soucis.

Julien a profité de parler du support pour évoquer la nouvelle politique de maintenance qui a fait tant de polémiques, et il a résumé celle-ci par une phrase :

Accès à des versions packagées, certifiées et validées pour les Anciennes versions des projets

Julien a terminé sa keynote en parlant de leur dernière acquisition (G2One) avant de laisser la parole à Guillaume Laforge

Téléchargez les slides de la présentation (pdf)

SpringSource rachète G2One

Orateur : Guillaume Laforge
Fonction : Chef de projet de Groovy, co-auteur de Groovy in Action, Spec Lead JSR-241

Avant toute chose, Guillaume s'est brièvement présenté. Il est le chef de projet de Groovy, le leader de la JSR-241 (la spécification de Groovy) et initiateur du framework Grails. Il est par ailleurs co-auteur du livre Groovy in Action.

Il a ensuite introduit Groovy. Celui-ci est un langage dynamique pour la JVM (au même titre que JRuby ou Scala). C'est un projet OpenSource sous licence Apache (et le restera !) qui est hébergé par la communauté Codehaus.

Ce langage est très proche de Java, et permet donc à n'importe quel développeur Java de faire le Switch facilement. Guillaume met d'ailleurs l'accent sur cette intégration transparente avec Java comme le principal intérêt d'utiliser Groovy et non un autre langage dynamique.

Ce fût ensuite à Grails d'être présenté. Celui-ci est un Framework de développement Web fortement inspiré par Ruby On Rails ou Django. Il se base sur le principe de " Convention over Configuration ", c'est-à-dire qu'un certain nombre de règles (manière d'organiser ou nommer des fichiers, utilisation d'une nomenclature des méthodes, …) remplace une tonne de fichiers de configuration.

Pour permettre cela, Grails est fondé sur des produits OpenSource de grande renommée : Spring bien sûr, mais aussi Hibernate ou Quartz.
Malgré son coté jeune (la première release date de février 2008), plusieurs grands sites lui ont d'ores et déjà fait confiance : linkedin.com et sky.com

Guillaume a fini sa présentation sur les avantages pour Groovy et Grails d'être sous la bannière de SpringSource. Le premier d'entre eux est clairement la visibilité. Devenir un produit SpringSource va permettre à Groovy/Grails non seulement d'être connu, mais aussi de gagner la confiance des entreprises.

Pour la communauté, SpringSource possédant une équipe de développement spécialisée en Eclipse, il est fort probable de voir arriver un support officiel pour ces produits, l'offre actuelle étant particulièrement pauvre (à coté du support de JetBrains par exemple).

Concernant Spring, et même si Guillaume ne le promet pas, il est fort probable de voir plus d'intégration de Groovy dans les projets du portfolio.

Téléchargez les slides de la présentation (pdf)

Roadmap des projets Spring

Orateur : Peter Cooper-Ellis
Fonction : SVP Engineering at SpringSource

Avant de rejoindre SpringSource, Peter Cooper-Ellis a travaillé chez Bea et c'est à lui qu'on doit la réussite du serveur d'application Weblogic. En tant que Vice-président of Engineering and Product Management, il s'occupe évidemment de la gestion des produits de SpringSource.

De ce fait, il est venu nous présenter ceux-ci qu'il classe en trois catégories :

  • Développement : portfolio, STS, modèle de programmation Spring, Groovy/Grails
  • Déploiement : SpringSource Entreprise, SpringSource ERS, SpringSource Dm Server, Performance Pack
  • Support : SpringSource AMF, abonnement au support, formation et consultance

A coté de la partie marketing, la roadmap non définitive de fin 2008 / 2009 nous a été présentée :

  • Fin 2008
    • Spring .Net 1.2
    • Spring Integration 1.0
  • 1er trimestre 2009
    • Spring 3.0 (REST, EL, Java 5)
    • Spring DM 1.2
    • Spring IDE 2.5
    • Groovy 1.6
    • Grails 1.1
  • 2ème trimestre
    • Spring Dm 2.0 (RFC 124)
    • Spring Batch 2.0
    • Spring ROO
    • Spring Security 2.5
    • Spring Web (Flex)

Téléchargez les slides de la présentation (pdf)

Tomcat en production

Orateur : Mark Thomas
Fonction : Un des principaux contributeurs du projet Apache Tomcat

Ce fût ensuite au tour de Mark Thomas de prendre la parole. Cette conférence fût des plus intéressantes, même si, une fois n'est pas coutume, elle était plus à destination des administrateurs système que des développeurs.

Mark Thomas est l'un des principaux commiters du projet Apache Tomcat. Il a résolu plus de 1500 bugs dans celui-ci sur une période de 5 ans.

Avant de rentrer dans des moyens concrets pour tuner Tomcat, Mark a tout d'abord voulu expliquer le processus à suivre pour détecter et corriger un goulot d'étranglement :

  1. Bien comprendre l'architecture du système
    Autrement dit, savoir ce que l'on teste, connaître les différentes ressources.
  2. Stabiliser le système
    Ne pas modifier le code durant la phase de tuning, car cela peut engendrer des effets de bords qui invalideront les résultats
  3. Se donner des objectifs clairs
    Il est primordial de savoir ce que l'on cherche à atteindre pour une application, afin de piloter l'optimisation dans le bon sens.
  4. Mesurer les performances actuelles
  5. Identifier le goulot d'étranglement courant
    Il peut y avoir plusieurs goulots, mais il ne faut travailler que sur le plus important
  6. Fixer la cause du problème
    .. et pas les symptômes.
  7. Répéter le processus jusqu'à atteindre les objectifs fixés

Mark a ensuite présenté différents moyens d'améliorer les performances de Tomcat.

Le premier point porta sur la gestion des fichiers de logs, la configuration par défaut n'étant pas optimale pour un environnement de production. La première optimisation consiste à élaguer la configuration afin d'écrire les logs uniquement dans des fichiers, exit donc la sortie sur la console, mais en ajoutant par ailleurs une rotation des fichiers afin d'éviter les fichiers de plusieurs Go.

Si cela est suffisant dans certains cas, dès qu'il y a beaucoup de traitements et donc beaucoup de traces écrites, un nouveau goulot d'étranglement apparaît : l'écriture sur disque. La solution, dans ce cas précis, est de passer sur du logging asynchrone. Autrement dit, les traces ne sont plus écrites directement sur disque mais stockées dans une pile mémoire. Celle-ci sera utilisée ensuite par un processus qui la videra en écrivant de manière optimisée sur le disque (écriture par bloc par exemple).

Il faudra cependant limiter la taille de cette pile afin de ne pas avoir de problème de surconsommation de mémoire. Si la capacité devait être atteinte, le logging redeviendrait temporairement synchrone.

Le gros point suivant que Mark présenta fût les différents connecteurs HTTP pour Tomcat :

  • Java blocking IO
  • Connecteur natif (APR)
  • Java non-blocking IO

Le premier est le plus vieux de tous, et le plus stable. Cependant, il n'est pas toujours optimal. Il n'est pas des plus rapides pour les connexions SSL car il se base sur une implémentation Java (JSSE) de SSL.
Son autre point faible est le mode http Keep alive.

Pour rappel, sans ce mode, une connexion http fonctionne comme ceci :

  • Ouverture connexion TCP
    • Envoi d'une requête HTTP
    • Réception réponse HTTP
  • Fermeture connexion TCP

Autrement dit, pour chaque requête, une connexion TCP est créée et fermée, ce qui peut parfois être lent. Pour résoudre ce problème, un mode keep-alive permet de fonctionner autrement :

  • Ouverture connexion TCP
    • Envoi d'une requête HTTP 1
    • Réception réponse HTTP 1
    • Envoi d'une requête HTTP 2
    • Réception réponse HTTP 2
    • ...
    • Envoi d'une requête HTTP N
    • Réception réponse HTTP N
  • Fermeture connexion TCP

Dans ce mode, la connexion reste ouverte entre le client et le serveur pour N requêtes.
Mais le souci dans le connecteur IO bloquant, est qu'un thread est dédié à une connexion et qu'un nombre maximum de thread est fixé. Donc si ce nombre est X et que X clients se connectent en keep-alive, tous les threads sont utilisés et tout nouveau client se verra refusé.

Heureusement, le connecteur non bloquant résoud ce problème.
Par contre il utilise toujours l'implémentation JSSE, et donc reste moyennement performant pour les connections SSL.

D'où l'intérêt du connecteur natif. Celui-ci utilisant la librairie OpenSSL pour la gestion des connexions sécurisées, les performances sont bien meilleures. Il est tout aussi performant dans la gestion des connexions keep-alive.

Voici un tableau qui résume assez bien les cas d'utilisation de l'un ou l'autre connecteur

Exigence Préférence de connecteur
Stabilité BIO ==> NIO ==> APR
SSL APR ==> NIO ==> BIO
Faible accès concurrent BIO ==> APR ==> NIO
Haut accès concurrent
Sans keep-alive
BIO ==> APR ==> NIO
Haut accès concurrent
Avec keep-alive
APR ==> NIO ==> BIO

Mark a ensuite expliqué deux autres moyens d'optimiser les performances :

  • Utilisation d'un cache pour les ressources
  • Tuning de la JVM (Garbage collector, taille du heap)

Toujours dans la problématique des performances, il est ensuite passé sur un autre sujet intéressant, le loadbalancing ainsi que le clustering de Tomcat.

Concernant le load-balancing, toute la configuration est totalement gérée du coté d'Apache, et particulièrement le mod_proxy_http. Il faudra configurer celui-ci correctement afin de rediriger les requêtes d'une même session http vers le bon Tomcat. Pour cela, une table de routage se base sur le JSessionId qui est l'identifiant unique de la session.

Cette configuration est déjà très intéressante, mais en cas de panne d'un des serveurs Tomcat, toutes les sessions de celui-ci seront perdues. Pour résoudre cela, il est nécessaire de configurer un cluster. La configuration d'un cluster par défaut se résume à une ligne dans le fichier de configuration de Tomcat.

Mark a conclu sa conférence par une série de petites astuces et conseils. C'est ainsi qu'il recommande l'utilisation de Tomcat clustérisés durant la phase de développement si l'on sait d'avance que cela sera le cas en production. De nombreux problèmes pourront ainsi être traités dès le départ.

Téléchargez les slides de la présentation (pdf)

Spring 3.0

Orateur : Juergen Hoeller
Fonction : Leader du projet Spring

La conférence de Juergen Hoeller fût certainement celle la plus attendue de l'auditoire. Allions nous enfin avoir plus d'information sur la future nouvelle version de Spring ?
Et Juergen Hoeller à décider de faire durer le suspens !

Il a tout d'abord rappelé ce que la version 2.5 apporta :

  • Configuration basée sur les annotations :
    • Propre à Spring : @Autowired, @Transactional, @Service,@Repository.
    • Mais aussi les standards : @PostConstruct, @PreDestroy, @Ressource, ...
  • Nouveau support tout les tests
  • Nouvelle API pour Spring MVC, elle aussi basée sur les annotations
  • Nouvelle API pour le support des portlets
  • ..

Après ce rappel, il a tout de même enfin parlé de Spring 3.0. Cette version nécessitera obligatoirement Java 5, mais reste compatible avec J2EE 1.4 et JEE 5.

Puis il présenta une des grosses nouveautés : les expressions languages.

Celles-ci permettront d'injecter dans un bean, une référence dynamique vers un autre bean, ou une propriété de celui-ci :

 
Sélectionnez
<bean id="monbeanA" class="test.monBeanA" init-method="initializeData"/>

<bean id="monBeanB" class="test.monBeanB">
	<property name="maPropriete" value="#{monBeanA.unePropriete}"></property>
</bean>

Dans cet exemple, la propriété " maPropriete " de monBeanB sera toujours la valeur de la propriété " unePropriete " de monBeanA. Le mot " toujours " a son importance.

Il était déjà possible d'injecter une valeur provenant de la propriété d'un autre bean grâce à la classe PropertyPathFactoryBean. Mais la différence, c'est que la valeur injectée était statique. Autrement dit, si durant l'exécution la propriété monBeanA.unePropriete changeait, la propriété monBeanB .maPropriete elle ne l'était pas. Les deux valeurs n'étant ainsi plus identiques.

Avec les EL, ce n'est plus réellement la valeur de unePropriete qui sera injectée dans monBeanB mais un proxy qui à chaque utilisation fera l'équivalent de ceci :

 
Sélectionnez
	Return applicationContext.getBean("monBeanA").getUnePropriete;

Au final, même si la valeur change dans le bean cible, les autres qui lui sont liés continueront de travailler sur la bonne valeur.

L'autre grosse nouveauté sera le support de REST dans Spring MVC. Le but de ce support est d'être intégré directement dans l'API de Spring MVC. Ce n'est donc pas un remplaçant de JAX-RS.
Différents formats de représentation seront possibles : JSON, XML ou ATOM.

Le support de la validation du modèle sera aussi ajouté. Les annotations de Hibernate Validators seront utilisables ainsi que les futures annotations de la JSR 303.

Celles-ci seront à la fois utilisées pour la validation, mais aussi par Spring MVC pour faire du rendu. Par exemple, l'utilisation de @ShortDate sur un champ de type date aurait comme conséquence que ce champ s'afficherait sous forme de date, sans l'heure, automatiquement.

Spring 3.0 apportera aussi le support de Portlet 2.0.

Concernant la roadmap, Spring 3.0 M1 était annoncée pour fin novembre mais fût légèrement en retard pour être livrée dans le panier de Saint Nicolas.
Spring 3.0 RC1 quand à elle est prévue pour Mars 2009 et la version finale pour Avril 2009.

Téléchargez les slides de la présentation (pdf)

Table ronde

Intervenant Société
François Cherpion HSBC
Alexandre Navarro Société Générale Banque d'Investissement
Ben-Amar Kacimi Voyages SNCF Technologies
David Duquenne Improve
Guillaume Laforge G2One / SpringSource

Les conférences se clôturèrent comme prévu par une table ronde avec des grands utilisateurs de Spring.
Durant celle-ci, nous avons pu voir que le framework est utilisé dans divers domaines et sous diverses formes.

Que ce soit comme fondation d'un framework 'maison', que ce soit dans un environnement temps réel ou encore dans des applications à très haute charge, Spring trouve toujours sa place.
Son utilisation étant souvent synonyme de gain et de meilleure qualité de code.

Une question intéressante fût celle concernant Spring dm Server. Didier a en effet demandé aux utilisateurs présents si ce serveur serait potentiellement utilisé ou non.
Certains étudient clairement la solution (SGCIB) car la possibilité de recharger à chaud un module sans devoir stopper l'application est très intéressante.

Mais il en ressort qu'il va être assez difficile de faire comprendre aux 'décideurs' en quoi l'investissement est intéressant.

III. Après midi

Après les conférences, SFEIR et SpringSource ont organisé la première édition de Speed-Consulting.

A l'instar du speed-dating qui propose des rendez vous rapides, le speed-consulting propose de rencontrer des grands noms pendant un court moment pour avoir des informations ou des conseils de leur part.

En pratique, c'est rencontrer jusqu'a 5 personnes sur des sessions d'une vingtaine de minutes pendant lesquelles vous avez le droit de poser des questions sur n'importe quel sujet : Spring, JEE, OSGi ou encore l'acquisition de G2one.

Les personnes présentes furent :

  • Didier Girard
  • Julien Dubois
  • Guillaume Laforge
  • Peter Cooper-Ellis
  • Juergen Hoeller

IV. Conclusion

Pour une première édition, les Rencontres Spring furent un réel succès ! La salle fût pleine, les conférences très intéressantes.
L'annonce de l'acquisition de G2One, l'arrivée de Spring 3.0, les premiers mois de Spring dm Server, tout était présent pour que cela réussisse.

Espérons que SFEIR et SpringSource récidiverons cet exploit l'année prochaine !

V. Liens

VI. Remerciement

Je tiens à remercier Ricky81 pour son aide précieuse dans la relecture de ce compte rendu.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Copyright © 2008 Gildas Cuisinier. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.