Publié par

Il y a 10 années -

Temps de lecture 10 minutes

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

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.

archi

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 :

Critère JSF/EJB3/JPA Seam
Réutilisation des composants 3 1
Facilité de mise en œuvre 2 3
Intégration des composants déjà mis en place 4 1
Investissement nécessaire 1 3
Intégration avec d’autres technologies 1 3
Evolutivité de l’architecture 3 1

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 :

Critère JSF/EJB3/JPA Seam
Nombre de classes 20 12
Nombre d’interfaces 7 5
Nombre de méthodes 259 138
Nombre de méthodes statiques 3 1
Nombre d’attributs des méthodes 104 82
Nombre de fichiers XML 5 7
Nombre de lignes XML 177 246
Nombre total de lignes de code 1605 1080

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 :

Critère JSF/EJB3/JPA Seam
Durée totale du projet en jours/homme 21 15
Préparation du projet 4 1
Configuration 5 3
Mise en œuvre 4 2

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

Fonctionnalité Oui/Non +/- Description Commentaires
Critères spécifiques aux frameworks de présentation
Validation des données Oui JSF Validator Solution éprouvée
Toolbox interface graphique Oui Taglibs JSF Solution éprouvée
Multi-langue Oui Support i18n standard Solution éprouvée
Implémentation MVC Oui Solution éprouvée
Modèle événementiel Non
Critères généraux
Maturité + Standards JEE5.0
Evolutivité + Architecture ouverte et flexible
Complexité de mise en œuvre Assez complexe à mettre en œuvre
Cout de développement – – Couteux en temps de développement
Cout de maintenance – – Couteux en maintenance

La solution Seam

Fonctionnalité Oui/Non +/- Description Commentaires
Critères spécifiques aux frameworks de présentation
Validation des données Oui Hibernate Validator Solution éprouvée
Toolbox interface graphique Oui Taglibs JSF et librairies Seam Solution éprouvée
Multi-langue Oui Support i18n standard Solution éprouvée
Implémentation MVC Oui Solution éprouvée
Modèle événementiel Non
Critères généraux
Maturité – – Forums légers
Evolutivité – – Très dépendant de l’évolution du framework
Complexité de mise en œuvre + Assez facile à mettre en œuvre
Cout de développement + + Framework très productif
Cout de maintenance Assez couteux en maintenance

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.

Publié par

Commentaire

6 réponses pour " Seam : Repenser l’architecture des applications web ? "

  1. Publié par , Il y a 10 années

    Merci pour ce post. Je propose une autre solution : passer sous Apache Wicket. Une utilisation correcte des modèles permet de résoudre les problématiques classiques rencontrées dans les applis web en se rapprochant réellement d’un modèle de développement type « client lourd ».

  2. Publié par , Il y a 10 années

    Bonjour,

    Quid des conversations qui est un des grands plus de ce framework comparé au stockage en session ?

  3. Publié par , Il y a 10 années

    La mention du livre « Seam framework » 2nde édition enrichirait votre article.

    Je suis d’accord sur le fond de l’article , quand vous mentionnez les dépendances techniques.

    Je pense que la facilité d’intégration de RichFaces/ajax dans les pages (les concepts de régions ..) ainsi que l’intégration du composant RESTeasy gagnerait a être mentionné.

  4. Publié par , Il y a 10 années

    merci pour cette presentation tres interresante pour les debutants interressé par seam

  5. Publié par , Il y a 9 années

    Pourquoi trouvez vous la maintenance coûteuse tant en seam qu’en jsf/ejb/jpa?

    Et pourquoi vous trouvez la réutilisation des composants difficile dans seam? je pense que pour rendre un composant compatible seam, il suffit d’ajouter quelques annotations.
    Enfin je ne comprend pas pourquoi vous dites que l’architecture des applications seam est 2 tiers! le nombre de couches d’une application dépend du concepteur, et non du framework!

  6. Publié par , Il y a 9 années

    Premier point : maintenance couteuse ?
    Si vous lisez bien l’article vous pouvez qu’il y a une différence entre la note attribué au niveau de la maintenance pour chacune application : (–) couteuse et (-) assez couteuse ce qui signifie qu’une application jsf/ejb/jpa est plus couteuse en terme de maintenance qu’une application Seam.
    Deuxième point : réutilisation des composants ?

    Un composant est une brique logicielle réutilisable par plusieurs applications. Un composant constitue un agent autonome, capable de s’organiser pour répondre aux besoins d’autres composants. Un composant Seam est représenté par une classe java du type POJO ou EJB 3.0 qui contient des annotations propres à Seam. Que faire au cas ou je veux réutiliser un composant EJB 1 ou EJB 2 … ? Est-ce que le faite d’ajouter des annotations Seam permet de l’intégrer facilement dans mon application Seam ? Pour moi c’est non d’où la complexité d’intégration des composants réutilisables dans une application Seam. Toutefois, si vous avez réussi à le faire n’hésitez pas à le partager avec la communauté ;)

    Troisième point : Architecture d’une application Seam ?
    D’après la documentation, Seam permettrait de rapprocher la couche applicative (JSF) et la couche services (EJB3). De ce fait, il n’y a plus d’intérêt à partir sur une architecture en 3 couches … mais personne ne peut empêcher un concepteur de créer 30 couches si ça lui semble correcte ^^.
    Je dirais aussi que la qualité d’un concepteur (ou d’un architecte) ne dépend pas de nombre de couches crées pour résoudre une problématique mais plutôt de la simplicité de sa conception et la facilité de son intégration par les développeurs.

Laisser un commentaire

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

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.