Warning: Use of undefined constant simple_breadcrumb - assumed 'simple_breadcrumb' (this will throw an Error in a future version of PHP) in /homepages/18/d232980052/htdocs/wp-content/themes/one-page-theme/single.php on line 11

Pour un Spring Break ?


Présenter encore le framework Spring ne serait que "paraphraser" nombres d'articles Internet ne tarissant d'ailleurs plus d'éloges sur le joyau de Rod Johnson (Fondateur de Spring). Spring s'est imposé en quelques années comme la boîte à outils sophistiquée de tout développeur Java en mal de flexibilité de code, de testabilité unitaire, de dépendance modulaire réduite, d'extensibilité, d'intégration à d'autres frameworks, etc ... Ceci étant dit, même si plusieurs modules complémentaires (AOP, DWR, WebFlow, etc ...) sont venus se greffer au fur et à mesure et ont contribué à la richesse de Spring, il est utile de rappeler rapidement le principe de base, à savoir l'inversion de contrôles et notamment l'injection de dépendances.

L'inversion de contrôles, les premières herbes de l'eldorado Spring

Contrairement à l'utilisation d'une librairie, où les appels sont lancés depuis le flot d'exécution du programme, l'inversion de contrôles permet de déléguer au framework utilisé la responsabilité d'exécuter un bout de code, sans contrôler les endroits, ni le moment où celui-ci l'effectuera. Ce principe s'apparenterait dans la vie de tous les jours, au client d'une banque qui opte pour le virement automatique sur son compte d'épargne plûtot que de le faire lui-même tous les mois. Ce concept n'est cependant pas vraiment nouveau en informatique. Il est utilisé par exemple par le conteneur EJB pour gérer le cycle de vie des instances d'EJB ou par le framework Junit pour initialiser (via la méthode setup) ou nettoyer (via la méthode teardrown) le contexte d'exécution du test. Pour ceux qui veulent plus d'information sur ce principe, voici le célèbre article de Martin Fowler à ce sujet.

Spring étend le principe d'inversion de contrôle pour gérer habilement la dépendance entre les objets utilisés dans un programme Java. Le conteneur "léger" est le composant qui se charge alors d'instancier et d'injecter les implémentations (beans) dont une classe a besoin pour s'exécuter. Ce mécanisme permet par simple paramétrage (via des fichiers de configuration XML) d'injecter une implémentation différente sans modifier le comportement de la classe qui l'utilise.Ce principe fondamental, nommé injection de dépendances et couplé à d'autres fonctionnalités (gestion de la programmation orientée aspect avec Spring AOP, intégration aisée avec les frameworks de persistance et de présentation, etc ...) a permis à Spring de se lancer sur le chemin du phagocytage progressif des normes d'implémentations J2EE et de proposer une réelle alternative à l'utilisation de serveurs d'applications.

Premières critiques à l'horizon ...

Premièrement, Spring est probablement le meilleur framework Java d'aujourd'hui, mais la principale critique demeure justement dans le fait qu'il s'agisse d'un framework. Faire le choix d'un framework "propriétaire" aussi ouvert qu'il puisse être, n'est pas sans conséquences sur l'évolutivité du système d'information. Malgré les contributions expertes et éclairées de l'équipe de Rod Johnson pour faire évoluer ce framework, le consortium de la JCP (Java Community Process) n'entend pas abandonner les spécifications J2EE et surtout d'en faire des standards. Une nouvelle norme des spécifications J2EE (EJB 3.1) vient d'ailleurs de voir le jour, cette norme permet de se débarrasser des lourdeurs des normes précédentes et surtout d'utiliser le principe d'injection de dépendances qui a fait le succès de Spring. De fait, n'importe quel développeur certifié J2EE devra maîtriser ses différentes normes et surtout l'interopérabilité avec les versions précédentes. A contrario, les compétences Spring peuvent être parfois très spécifiques vu l'étendue et la diversité des fonctionnalités qu'il intègre. Deuxièmement, les entreprises ont beaucoup investi (peut-être à tort) dans les serveurs d'applications J2EE, car séduites par leur capacité à offrir clé-en-main plusieurs solutions pouvant être des exigences fortes du SI. Il s'agit par exemple de la gestion de la sécurité, la distribution de charges, la perte minimale de données, etc ... Le débat qui oppose Spring aux EJB (toutes normes confondues) est certainement fondé, mais penser qu'on pourrait se passer des serveurs d'applications J2EE et revenir aux moteurs de servlets sur lesquels sont déployés des factory de beans Spring, n'est pas viable au vu des exigences de plus en plus fortes des systèmes d'informations.

Troisièmement, comme toute boite à outil sophistiquée, ce framework nécessite une attention particulière et n'est surtout pas adapté aux mains non aguerries. La montée en compétences sur un framework qui manipule des notions aussi abstraites et de surcroit éternellement enrichies peut avoir un impact non négligeable sur la courbe d'apprentissage de la technologie par l'équipe projet.

Enfin au delà de tous ces aspects ayant finalement plus attrait à la conduite du changement du SI, l'utilisation technique de Spring Framework peut être particulièrement périlleuse si le contexte de son utilisation n'est pas adapté ...

Et Techniquement ?

L'avènement de Spring a vu s'accentuer le phénomène connu sous le nom de "fashion codestyle". Il s'agit, indépendamment de la réelle valeur ajoutée , d'utiliser la technologie pour le simple plaisir de l'utiliser. Les "fashion codestyle victims" ont alors tendance à ériger Spring en réponse à de réels problématiques de conception applicative. De la même façon que l'avènement des framework de mapping Objet/Relationnel (Hibernate, TopLink, etc ...) ont à tort relégué au rang inférieur l'écriture de code SQL (étant pourtant le dernier niveau de couche), Spring Framework ne doit pas devenir le tapis qui cache la poussière des mauvaises pratiques de conception et de programmation. Pour prendre un exemple concret, Spring n'améliorera ni la flexibilité, ni l'évolutivité d'une application où les couches applicatives (présentation, service s, domaine) sont fortement imbriquées entre elles . Il risque d'ailleurs d'en dégrader la maintenabilité.

Une autre des problématiques classiques d'utilisation de Spring est le cycle de vie et la cardinalité des instances de beans injectés par le conteneur "léger". Par défaut, les beans (classes d'implémentation) injectés par le conteneur de Spring sont conçus selon le célèbre pattern Singleton, pattern qui permet de créer une seule et unique fois une instance d'une classe et renvoyer toujours cette même instance aux classes qui la requièrent pour s'exécuter. On rentre donc dans Spring par défaut dans un contexte statique. Il peut alors se poser des problématiques liées aux traitements effectués dans une même classe. Ces traitements peuvent non seulement être eux-même différents, mais aussi appelés par plusieurs threads concurrents différents. Utiliser l'opérateur "new" pour instancier de nouveaux objets, brise la chaîne de dépendances des beans, car la nouvelle instance créée n'est plus géré par le conteneur de Spring mais directement dans le programme. La solution offerte par Spring est de regrouper ces beans dans des "FactoryBeans" spécialisés et de les déclarer en scope "prototype" en lieu et place de la Factory par défaut où les beans sont des singletons. On rentre alors dans la complexité des configurations déclaratives où toute erreur peut avoir un impact (parfois difficilement décelable) sur le comportement global de l'application. On notera que dans certains cas, utiliser l'opérateur "new" peut être une rigidité "acceptable" si on veut garantir un fonctionnement sans effets de bords engendré par une mauvaise configuration.

Au delà du risque engendré par une mauvaise configuration dans les fichiers XML du contexte Spring, la multiplication non maitrisée de ceux-ci peut poser de réels problèmes de maintenance et surcharger inutilement la machine virtuelle d'objets jamais utilisés. Autant l'injection de dépendances peut-être très utile pour injecter des implémentations différentes entre les différentes couches d'une architecture multi-niveaux , autant l'utilisation au sein d'une même couche nécessite un certain recul pour éviter d'introduire plus de complexité que de flexibilité. Cette complexité pouvant croitre avec la taille du projet.

Cependant ...

Le framework Spring a encore de beaux jours devant lui avec l'arrivée de Spring Dynamic Module Server (Spring DM). Ce serveur d'applications se veut une alternative aux serveurs J2EE, il permet d'héberger les applications Spring et se base sur la technologie OSGI permettant le déploiement dynamique (et sans interruption) d'applications et la gestion du versionning des applications ainsi que des services.

Le spring Break aura donc été de "très" courte durée . On reviendra...

Contactez-nous

42 rue de Maubeuge
75009 Paris

Suivez-nous

Tous textes sous licence Creatice Commons CC-BY - Mentions légales Licence Creative Commons