Seam : Repenser l’architecture des applications web ?

Seam est un framework qui permet de simplifier le développement des applications web complexes. Seam utilise la plupart des concepts de la spécification JAVA EE 5 qui vise à faciliter le développement et l’intégration des applications entreprises. Seam fournit un modèle de composant, une API et des annotations pour faciliter l’intégration des standards Java EE 5 telles que JSF (Java Server Faces), EJB 3, et JPA (Java Persistence API).

Dans ce billet, nous allons essayer d’évaluer ce framework en menant une étude comparative entre deux prototypes basés sur le même socle fonctionnel. Un premier prototype en JSF/EJB3/JPA et un deuxième se basant sur le même socle technique mais intégrant Seam. L’étude va porter sur plusieurs critères tel que la maturité de la solution, la pérennité, la complexité de mise en œuvre, le coût de développement etc.

Au programme :

• Présentation de Seam
• Le prototype ContactBook
• La solution JSF/EJB3/JPA
• La solution Seam
• Comparatif des deux solutions
  • Architecture applicative
  • Code technique
  • Délai et facilité de mise en œuvre
  • Solution
• Conclusion

Présentation de Seam

Seam est un framework JEE 5 dont la première version est sortie en décembre 2005. Il se base essentiellement sur les standards EJB3 et JSF pour construire des applications web. L’objectif principal de Seam consiste à éliminer la complexité tant au niveau de l’architecture que de l’interface de programmation (API). Il se base sur les annotations JDK 1.5 et sur l’utilisation des POJO conformément à l’évolution de JAVA EE 5.

Il offre de nombreuses avantages :

• Meilleure Intégration (JSF/EJB3/JPA).
• Nouveaux contextes : conversation, business process et page.
• Gestion automatique des composants de l’application.
• Intégration simple des flux de pages.
• Intégration simple de JBoss JBPM.
• Accès distant simplifié.

Ce framework offre de nombreuses facilités au niveau de la mise en œuvre des applications web, et se présente de plus en plus comme un futur standard. Pour les utilisateurs qui ne sont pas encore prêts à utiliser les EJB, Seam supporte également des classes POJO et des classes Hibernate comme composants.

Nous allons essayer de vérifier la pertinence des éléments avancées par les créateurs de Seam en menant une étude comparative entre deux prototypes, un se basant sur les EJB3 et JSF et un se basant sur le même socle technique mais utilisant Seam comme framework d’intégration des deux technologies.
Pour ceux qui veulent se documenter plus n’hésitez pas à consulter le billet suivant.

Le prototype ContactBook

Le prototype ContactBook est une application web de gestion des contacts. Son périmètre fonctionnel couvre les fonctionnalités essentielles d’une application de gestion. Ces fonctionnalités sont réparties en deux domaines :

• Gestion des utilisateurs.
• Gestion des contacts.

ContactBook est une application web relativement simple. Elle permet à un utilisateur de gérer ses contacts. Chaque utilisateur répond à un profil (nom, prénom, adresse mail et numéro de téléphone). Chaque utilisateur doit s’identifier auprès du système pour utiliser l’application ContactBook.

ContactBook est une application internationale. Un utilisateur doit pouvoir choisir sa langue « de travail ». Un mécanisme de changement de gestion multilingue est donc proposé à l’utilisateur. Deux langues sont proposées : l’anglais et le français. La langue par défaut est le français.

La solution JSF/EJB3/JPA

cette solution se base sur une architecture 3 tiers avec jsf pour la couche présentation, ejb3 pour la couche métier et jpa pour la couche des données.

La couche présentation est constituée d’un ensemble de composants JSF. Les JSF Backing Beans ou les Managed Beans sont utilisés pour faire le lien entre la couche présentation et la couche métier, ils permettent ainsi de récupérer les données saisies par les utilisateurs, les valider et les véhiculer à la couche métier. La couche métier est un ensemble de composants EJB session qui encapsulent le logique métier de l’application. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

La solution Seam

Cette solution se base sur les mêmes composants que l’architecture précédente mais utilise Seam comme framework d’intégration des différentes frameworks et technologies utilisés dans le projet.

La couche présentation est constituée d’un ensemble de composants JSF. Les EJB session jouent un double rôle puisqu’ils permettent l’échange des données entre la couche présentation et la couche métier, la validation des données, et la gestion des transactions et des sessions des utilisateurs. Les EJB entités représentent le modèle des données. Ceux-ci seront directement persistés dans la base de données grâce à l’api de persistance utilisée.

Comparatif des deux solutions

Architecture applicative

Pour commencer, nous allons mener une comparaison au niveau de l’architecture applicative des deux solutions proposées :

Notation : Faible(1), Moyen(2), Élevé(3), Excellent(4)

Les dépendances introduites dans le code technique par Seam, ainsi que le modèle d’architecture imposé par ce framework rend la réutilisation de ses composants très faible par rapport aux composants sans Seam qui sont réutilisables dans l’état.

Seam couvre la plupart des besoins techniques liés au développement d’une application web, ce qui permet de simplifier le développement avec JEE5. Seam fournit aussi des outils pour faciliter la vie des développeurs. Sans Seam les développeurs doivent prendre en charge tout les problèmes liés à l’intégration des différentes briques JEE5.

Il est plus difficile d’intégrer des composants réutilisables dans une application Seam, car il faut les convertir en composants Seam. Sans Seam nous avons moins de contraintes pour intégrer des composants réutilisables dans l’application.

Seam est un framework complexe qui nécessite un grand cout d’entrée, mais qui permet de résoudre beaucoup de problèmes liés à l’intégration des différents frameworks du marché. Seam nous facilite la tâche en s’intégrant parfaitement avec plusieurs frameworks et implémentations des spécifications JEE5 (EJB3, JSF, Spring, GWT, IceFaces …).

L’architecture de la solution Seam est moins souple que l’architecture de la solution JSF/EJB3/JPA, c’est à la fois un avantage et un inconvénient. Un avantage car il y a moins de problèmes à résoudre lors de l’implémentation de la solution. Un inconvénient car le choix de Seam peut être impactant par la suite. Par exemple il serait difficile de passer de JSF à un autre framework web qui n’est pas pris en charge par Seam, Ce qui freine l’évolutivité à long terme.

Code technique

Pour voir l’apport de l’intégration de Seam sur le code technique, nous avons utilisés le plugin Metrics pour calculer quelques
métriques :

Nous avons constaté que l’intégration de Seam a permis de réduire considérablement la quantité du code technique. Comme il n’y a pas de distinction entre un composant backing bean et un composant Seam. Une page JSF peut donc invoquer directement un composant Seam sans passer par un backing bean ce qui permet de supprimer le code technique des backing beans.

Seam fournit aussi des annotations pour JSF, le cycle de vie des composants, les exceptions, l’asynchronicité, le databinding, l’intégration avec plusieurs apis du monde JEE etc. Ces annotations permettent de produire un code élégant et très compact. Beaucoup prétendent que l’utilisation de Seam ne nécessite pas de configuration XML ce qui est faux, l’intégration des briques et des apis tierces avec Seam nécessitent leurs propres configurations.

Seam est un framework très productif qui permet de réduire considérablement la quantité du code technique nécessaire pour développer une application web mais les dépendances introduites par Seam rend le code technique difficile à maintenir et difficilement réutilisable sans Seam.

Délai et facilité de mise en œuvre

Cette comparaison va nous permettre de comparer les deux prototypes au niveau de la mise en œuvre :

Notation : Très Facile (1), Facile (2), Moyen (3), Difficile (4), Très difficile(5)

La préparation du projet Seam est très simple car nous avons utilisés l’outil seam-gen pour générer la structure du projet avec des exemples de code fonctionnel. Avec Seam, la configuration est fournie dans le projet générée avec seam-gen ce qui n’est pas le cas dans le projet EJB3-JSF. La cohabitation des différentes briques JEE est prise en charge par Seam. Les backing beans n’existent plus, les pages JSF invoquent directement les composants Seam. Sans Seam, il faut coder tout les backing beans et les mapper avec les pages JSF. C’est un cout de développement de plus pour les développeurs. Néanmoins, il ne faut pas oublier que Seam introduit ses propres dépendances dans votre code ce qui le rend moins évolutif et difficilement réutilisable dans d’autres projets qui n’utilisent pas Seam.

Solution

Pour comparer les deux solutions développées, nous allons nous baser sur des critères spécifiques aux frameworks de présentation et des critères généraux :

La solution JSF/EJB3/JPA

La solution Seam

Conclusion

Seam permet d’effondrer les couches artificielles entre la couche présentation et la couche métier. Il permet ainsi de rapprocher les composants métiers de la couche web.

Dans la solution JSF/EJB3/JPA, il est nécessaire d’utiliser des backing beans JSF pour lier la couche présentation à la couche métier. En Seam il n’y a plus de couches d’intégration, mais il faut voir les choses autrement car Seam s’appuie sur une architecture 2 tiers. Lorsque l’on a plusieurs niveaux, il est préférable de les séparer en plusieurs couches pour avoir une meilleure visibilité du code et une séparation des responsabilités. Un autre problème réside dans le fait que Seam introduit une forte dépendance entre les différentes couches de l’application.

Seam a apporté une vraie valeur ajoutée à notre projet JSF/EJB3/JPA et nous a permis de gagner en productivité. Toutefois, le modèle d’architecture imposé par Seam et les dépendances techniques introduites dans nos briques nous laissent à réfléchir, mais il reste une solution très envisageable pour développer des applications entreprises.