Après deux ans d’utilisation d’un FRAMEWORK Struts Spring Hibernate

il était temps de faire un bilan du déploiement d’applications JAVA EE basées sur les célèbres FRAMEWORKS STRUTS SPRING et HIBERNATE..

J’ai pu faire un état de lieux deux ans après de ce genre d’applications pour voir les différentes possibilités qui s’offraient en terme d’évolution ( AJAX, EJB3, …). Voici donc mon retour d’expérience:

ÉTAT DES LIEUX

CONSTATATIONS GÉNÉRALES

La plateforme Java EE a beaucoup évoluée depuis la mise en place du premier FRAMEWORK CCIP. En effet, les EJB3, et l’utilisation a grandement changé la donne. La plateforme Java EE5 évolue vers une plateforme préconisée par JBOSS SEAM:

A bien regarder elle n est pas complètement différente de celle déjà utilisée auparavant : à la place de STRUTS on a JSF, à la place de SEAM:SPRING et on a déjà HIBERNATE Tout est configuré sous la forme d’annotations et il n y a plus rien dans les fichiers XML. Avec SPRING on en est loin… De plus, la nouvelle architecture fournie par SUN nécessite de moins en moins de tiers FRAMEWORKS. STRUTS a été déployé pour pallier aux manques de l’ API SERVLET/JSP, HIBERNATE, pour les EJB 2.x. Dorénavant, il est de plus en plus possible de développer une application Java EE « out of the box ».

RETOURS D’EXPÉRIENCE DES PROJETS

Voici quelques retour d’expérience négatifs sur les projets mis en oeuvre à DIA:

  • On perd du temps sur le développement des composants GUI simples et redondants : tableaux a tri,recherche,…
  • La mise en production est complexe
  • Pas de procédure d’exploitation
  • Il faut être très rigoureux ( est ce un mal)
  • Requêtage HQL complexe
  • Il existe des problèmes sur le MULTI THREADING ( violation des sessions …)

La plateforme JavaEE 5: une solution à nos problèmes ?

Oui et non. Tout d’abord, la plateforme Java EE5 supprime beaucoup de fichiers de configuration et de classes inutiles(cf. EJB3) JSF facilite – à mon avis – le développement des GUIS mais ne gère pas les conversations sur plusieurs pages et les WORKFLOWS de pages. EJB3 peut simplifier le développement des couches basses d’accès aux données grâce aux annotations.

PRÉ-REQUIS ÉTABLIS

PRÉAMBULE

La définition de la nouvelle architecture n’ a pas été chose aisée? Loin sans faux. En effet, comme le l’ai décrit ci-dessus, la plateforme Java EE a subie une mutation extraordinaire des deux dernières années. Il a fallu donc les suivre et les évaluer afin de savoir si les différentes opportunités existantes actuellement étaient réellement viables dans notre contexte.

PERSISTANCE DES DONNÉES

Les FRAMEWORKS de persistance doivent être utilisés via l’API JPA/EJB3 (HIBERNATE ou TOPLINK). Outils testésOutils testésOutils testésOutils testésOutils testésOutils testésOutils testés

  • Implémentation EJB3 d oracle
  • Annotations d’ HIBERNATE

COUCHE DE PRÉSENTATION

STRUTS tel qu’ on l’utilise est déprécie. Il y a plein de limitations (non présence des formulaires STATEFULL,…) JSF est le standard actuel. Malheureusement, il faut se doter de librairies (payantes ou OS) pour rendre le développement le plus rapide possible. De plus, le choix d’un éditeur de type RAD est primordial, sinon le développement devient plus coûteux. La couche de présentation va de plus en plus interagir avec la couche métier via des requêtes AJAX. La JSR-299 demandée par JBOSS annonce déjà l’utilisation directe des POJOS dans les formulaires (WEBBEANS)

Outils testés:

  • StrutsSHALE
  • Backbase
  • Icefaces
  • JBOSS SEAM
  • GWT
  • ADF Faces
  • Echo2:
  • facelets
  • AJAX4JSF
  • netadvantage
  • AjaxTAGS

L’INVERSION DE CONTRÔLE

La glu effectuée par l IoC avec SPRING est devenue indispensable. D’autres FRAMEWORKS proposent ce même mécanisme en plus simple (Ex. JBOSS SEAM) Cependant,SPRING a très bien implementée, la séparation des interfaces et de leurs interfaces et semble t il mieux fait que sous JBOSS SEAM. Par contre SEAM gère les états des JAVABEANS Outils testés

  • Spring 2.0
  • JBOSS SEAM

LA PROGRAMMATION ORIENTÉE ASPECT

Ce type de programmation a été initié à la CCIP par la biais de SPRING. On a pu en voir tous les gains que ce paradigme proposait. Fort heureusement, d’autres composants implémentent l’AOP.

MAVEN

Maven1 est aussi déprécié, il faut passer a maven2

OUTILS DE TEST

L’un des points faibles de JUNIT est qu’il ne gère par le Multi-threading. Dans la nouvelle architecture, un composant héritant de JUNIT devra gérer cet aspect.

LES ARCHITECTURES POSSIBLES

Différentes architectures sont possibles. Je n’ai retenu que deux qui sont pour moi pertinentes:

Architecture de type SPRING

  • JSF SHALE
  • SPRING
  • HIBERNATE /EJB3

Cette architecture est le prolongement logique de l’existant à DIA. La migration serait aisée. Malheureusement, les problèmes liés aux multiples fichiers et autres descripteurs de déploiement serait toujours présente.

Architecture de type JAVA EE 5

  • JSF
  • JBOSS SEAM
  • EJB3

C’est à mon avis l’architecture la plus à même de répondre à nos problématiques. Elle offre la puissance des annotations (plus de descripteurs de déploiement, plus de fichiers de configuration…) et offre toutes les fonctionnalités demandées (interfaçage avec des BPM, définition de conversations entre plusieurs écrans,…).

FRAMEWORKS AJAX

De nombreux FRAMEWORKS AJAX ont été testés. Il n’y a malheureusement aucun standard actuel qui nous permette de faire un choix définitif. C’est pourquoi, les solutions GWT et ECHO2 ont été écartées. Elle sont trop éloignées du modèle défini par SUN.

L’ARCHITECTURE FINALE

CHOIX DU SERVEUR D’APPLICATIONS

En ce qui concerne le projet GEFI, le serveur d’applications sera JBOSS AS pour répondre à des problèmes de budget et de redistribution La version déployée sera dans un premier temps la 4.0.5GA. Dès que la première version de la branche 5 sera disponible, elle sera évaluée et déployée car elle intègre nativement tous les composants que je vais décrire ci-après.

ARCHITECTURE LOGICIELLE

L’architecture de type Java EE 5 sera utilisée. Elle permettra,j’espère, de répondre aux problématiques de facilité de développement. Nous aurons donc les composants suivants:

  • EJB3
  • JSF
  • Facelets
  • ajax4jsf+RichFaces
  • SEAM
  • TestNG

AVANTAGES ET DÉFAUTS

AVANTAGES

Limitation du nombre de FRAMEWORKS

La nouvelle architecture va beaucoup plus coller au modèle préconisé par SUN. Il en résultera une meilleure clarté au niveau des développements. De plus, nous pourrons bénéficier de plus de support (par exemple sur les EJB3) auprès du support du serveur d’applications.

Productivité

Voici dans la configuration actuelle les actions à mener dans le cadre de l’ajout d’une nouvelle fonctionnalité (hormis les phases de test et de déploiement)

Donc pour une fonctionnalité, nous avions à modifier près de dix fichiers (certains n’ont pas été décrit dans le processus). Dans la nouvelle architecture, nous aurons la cinématique suivante :

DÉFAUTS

Une nouvelle architecture

Tout d’abord on quitte l’architecture existante pour une autre. Les applications existantes pourront aisément migrer sur JBOSS AS. Malheureusement, elles ne pourront pas migrer vers ajax4jsf ni utiliser les EJB3. Cela fait certes une deuxième plateforme à utiliser, maintenir et exploiter.

Capitalisation des précédents projets

Les développements et expériences ne sont pas capitalisés. Je dirais oui et non. L’expérience acquise sur HIBERNATE pourra être réutilisée sur les EJB3 car le moteur des EJB3 de JBOSS AS est HIBERNATE.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *