Paris m’accueille parée de bleu pour cette formation Spring que j’espérais enrichissante. Le 1er jour ne m’aura pas déçu!

Le formateur nous a donné pour commencer les différents points développés durant cette formation:

1. Paysage web actuel
2. Fondamentaux Spring (2ème jour)
3. Intégration de différents frameworks au moyen de Spring (2ème et 3ème jour)

Paysage actuel

Autrement dit quels frameworks sont à notre diposition actuellement pour réaliser nos applications web¹? Le bilan est une longue liste partageable en 3 couches:

• Présentation: Struts 1.x/ Struts 2.x - Jsf - Gwt - Cocoon
• Persistance: Hibernate - iBatis - EJB - JDBC
• EAI: JMS - WS

L’idée ici est de montrer que le paysage est plutôt chargé et que si nous désirons utiliser plusieurs de ces frameworks (ou d’autres) il serait pratique de pouvoir facilement les emboîter. Bon c’est pas trop difficile à deviner, dans notre cas Spring sera la solution dédiée. Solution qui s’affirme plus clairement de jour en jour à (pratiquement) toute solution JEE.

Voici donc la première chose à retenir: Spring est (quasi de-facto) le socle de base d’une solution JEE utilisant plusieurs frameworks de différentes couches.

Objectif: modulaire

Le formateur nous le fait comprendre rapidement: une solution non modulaire est une solution destinée à l’échec. Et attention, la modularité technique (apportée grâce au modèle MVC) n’est pas une finalité! Ce que nous désirons ici en tant que concepteur d’applications c’est d’avoir également une modularité fonctionnelle. Autrement dit la possibilité de réutiliser certains services sur plusieurs applications avec le moins de codage possible (Plug and Play).

Le bienfait de raisonner de cette manière? Le code produit devient facilement réutilisable et la maintenance sera un régal comparé à ce que l’on peut trouver sur certains projets… En effet passer par exemple de Hibernate v2 à v3 nous demandera de modifier uniquement le module persistance de notre application sans impacter le restant du code. De plus, d’un côté fonctionnel, nous pourrons par exemple réutiliser un service d’authentification de manière transparente sur une autre application… Et donc de ce fait, une meilleure visibilité, une meilleure productivité et une réelle valeur ajoutée grâce aux différents services réutilisables.

Etude de cas

Durant cette formation, nous mettons en oeuvre une étude de cas chère aux français: la gestion des congés (bon au final on s’est penché uniquement sur le module d’authentification). Nous avons ainsi débuté la conception de cette étude de cas en utilisant une distribution d’Eclipse que je ne connaissais pas personnellement, topcased. Cette distribution est fourni avec une perspective UML gratuite et open-source permettant de créer tous les diagrammes UML utiles à la conception d’applications.

Pour cette phase de conception je découvre encore un nouvel élément: Le cycle en Y. J’y reviendrai plus tard…

Comme décrit dans ce cycle, les livrables peuvent être dispatchés sur une architecture distribuée. Sur ce point, le formateur nous a précisé quelque chose d’intéressant concernant les machines virtuelles Java et leur capacité à monter en charge. En effet, un réflex lorsqu’une application à de la peine à tourner pourrait être de rajouter des ressources physiques (RAM et/ou processeur). Il faut cependant garder à l’esprit qu’une JVM ne pourra pas dépasser un certain plafond puisque le Garbage Collector effectuera son boulot sur une quantité de mémoire toujours plus grande et prendra ainsi toujours plus de temps à le faire. Ce plafond atteint, il ne servira à rien de lui donner plus de mémoire, la seule solution alors est d’ajouter un (ou plusieurs) nouveaux serveurs. A tenir en compte lorsqu’un serveur vendu avec une licence de plusieurs milliers de francs est choisi…

Conception

L’approche lors de cette formation a été à mon avis optimale. L’idée était de découvrir Spring en débutant par mettre en place son fonctionnement de base nous-même afin d’en discerner le comportement et par la même occassion les bénéfices d’une telle architecture.

Après un bref résumé du modèle MVC et de son utilité dans la conception d’applications, la première étape dans cette découverte a été de mettre en place le modèle de conception Factory Method. Nous nous sommes ainsi retrouvés avec une factory sur les couches persistance et service comme le montre le schéma ci-contre. En mettant en place ce modèle nous garantissons la possibilité de changer d’implémentation de façon centralisée. De plus, il devient possible en suivant cette architecture de reprendre la couche service, persistance et entité et de réutiliser ce module dans une autre application. Nous avons donc là une modularité fonctionnelle!
On approche une solution modulaire mais comme nous le verrons prochainement on peut encore faire mieux et c’est lors du 2ème jour de cette formation qu’on l’a vu.

1. Je focalise bien sûr ici sur les solutions Java JEE [↩]