I. Introduction▲
Java EE 5
Aujourd'hui de nombreux projets Java EE sont construits autour de spécifications communes.
EJB
La technologie EJB ou Enterprise JavaBeans est une architecture de composants logiciels côté serveur pour la plateforme de développement JEE. Cette architecture définit un cadre pour la création de composants distribués (déployés sur des machines distantes).
La spécification EJB permet de séparer l'abstraction de données des services de l'application. Elle incite de plus à développer des composants réutilisables et autonomes et permet une gestion affinée des transactions métier grâce à JTA.
Intégrés à la plateforme JEE en 2001 en version 2.0, les EJB ont pour but de fournir une technologie de composants distribuables et transactionnels. La lourdeur d'EJB 2.0, puis 2.1, fût à l'origine d'une levée de boucliers de la part d'un certain nombre d'acteurs du monde Java.
En 2004, Rod Johnson et Juergen Holler lancent le framework Spring, qui constitue un substitut à EJB 2.1 en proposant la création de composants (bean) transactionnels et supportant l'injection de dépendance.
En 2005, EJB 3.0 voit le jour. Il n'a pas grand-chose à voir avec son prédécesseur si ce n'est le nom. En effet, EJB 3.0 est une technologie très puissante, et beaucoup plus facile à mettre en œuvre que son ancêtre.
JPA via Hibernate
Hibernate est un Framework java de mapping objet relationnel, implémentant JPA. Il permet de faire le mapping entre objets Java et objets stockés en base relationnelle. De plus il en assure la persistance.
Hibernate a été écrit sous la responsabilité de Gavin King qui fait partie de l'équipe JBoss et qui est aussi le fondateur de Seam.
Il permet un gain de productivité énorme dans le sens où il utilise la structure d'objets annotés avec JPA pour créer et modifier les tables.
Concrètement, cela veut dire qu'Hibernate permet de manipuler les données d'une base de données relationnelle sous forme d'objet.
JSF
JSF ou Java Server Faces est un framework Java pour le développement de clients riches pour les applications web. Contrairement à la majorité des frameworks MVC à base d'actions, JSF est basé sur la notion de composant gérant des événements, il reprend le modèle d'autres frameworks pour l'IHM tel que Swing ou SWT ou l'état d'un composant est enregistré lors du rendu de la page pour être ensuite restauré au retour de la requête.
Malheureusement lorsqu'il voit le jour en 2004, JSF est marqué par un certain nombre de défauts qui ont considérablement ralenti son adoption (complexité à mettre en œuvre, lourdeur des fichiers de configuration XML, impossibilité d'utiliser du code HTML, pas de mécanisme de templating). Facelets apportera une solution aux deux derniers points.
Ces défauts ont considérablement ralenti l'adoption de JSF tout en favorisant l'émergence de frameworks orientés composant comme Wicket. Aujourd'hui avec Seam les derniers défauts de JSF sont levés et l'arrivée de JSF 2 permettra d'unifier toutes les technologies utilisées pour rendre JSF pleinement exploitable pour le développement web.
Bien que très puissants, JSF et EJB 3.0 sont très éloignés. Créer une application JEE 5.0 nécessite donc beaucoup de code pour les faire cohabiter.
Seam a été conçu pour combler ce vide et faire la jointure entre ces deux technologies. Toutefois, Seam intègre aussi un conteneur de composant permettant de se passer des EJB (ou même, d'utiliser Spring) tout en conservant un moteur transactionnel.
II. Unification de Java EE▲
Une application multitiers est donc typiquement fabriquée à partir d'un ensemble de composants : services transactionnels, services de sécurités, persistance des données, envoi de messages asynchrone, composant d'interfaces graphique, etc.
Parmi eux on l'a vu, on peut citer surtout EJB3, JPA (via Hibernate), JSF,EL, JMS, JAAS, iText, Groovy, JBoss Rules, Ajax, etc.
Vous connaissez tous une partie ou l'essentiel de ces technologies, au moins de nom.
Néanmoins, le problème qui revient de manière récurrente lorsqu'on entame un projet autour de ces spécifications est tout d'abord : que choisir parmi la quantité invraisemblable de technologies de Java EE ?
Ensuite il faut limiter les choix, car l'intégration et la communication des différents aspects technologiques au sein du projet peut vite devenir très, voire trop complexe.
L'intégration est donc l'un des problèmes les plus ardus dans le développement d'applications d'entreprise. En effet, tout d'abord la configuration du projet intégrant ces spécifications est souvent laborieuse et longue.
Néanmoins de projet en projet on refait encore et toujours ces mêmes étapes.
Et bien aujourd'hui nous allons vous présenter une solution à cette problématique : Seam.
Seam est d'abord parti du principe que la spécification java EE 5 incorpore deux composants d'architecture qui sont des clefs pour créer des applications web : JSF et EJB3.
JSF est le standard de JEE5 pour la couche présentation qui fournit à la fois l'interface utilisateur, modèle de composant et gestion événementielle côté serveur.
EJB3 est le standard de modèle de composant pour créer des composants métier sécurisés et évolutifs , qui accèdent aux ressources de manière transactionnelle.
Mais EJB3 englobe aussi Java Persistence API qui définit un standard de modèle de persistance pour faire le mapping objet relationnel.
Néanmoins les deux architectures ont un souci, elles nécessitent des intermédiaires pour communiquer, un code qui va servir à les assembler (les coller) autant d'un côté configuration XML que code Java (les backing beans JSF).
La connexion des EJB aux pages JSF est tout à fait faisable, mais sous certains aspects, trop complexe.
Seam a pris en charge cette responsabilité et permet à JSF et EJB3 de fonctionner enfin directement ensemble.
En partie grâce à cela, Seam s'est positionné lui-même comme un prototype de la future spécification Java EE 6.
Trois JSR (JSR = Java Specification Request) importantes ont été acceptées :
JSR 299 les Web Beans dont le but est d'unifier les managed bean de JSF avec le modèle de composant EJB ;
JSR 314 JSF 2.0 ;
JSR 303 : Bean Validations.
Cependant ne soyez pas inquiet d'une éventuelle limitation : Seam ne va pas vous rendre complètement dépendant d'EJB et de JSF.
En effet côté vue, vous pourrez changer alternativement pour Wicket, Tapestry, GWT ou Flex et autres à la place de JSF.
Et côté métier Seam permet le support des JavaBeans comme composants transactionnels et de plus l'intégration du conteneur de Spring est tout à fait possible, et ce toujours dans cette volonté de simplicité d'intégration et de configuration.
Vous devez voir le but de Seam comme celui de fournir au développeur une seule source de technologie.
L'idée initiale de Gaving King, créateur d'Hibernate et de Seam, était de mettre en place une fondation qui autoriserait le contexte de persistance (Session Hibernate ou EntityManager de JPA) à traverser les couches et autoriserait les EJB Statefuls à répondre directement aux composants d'interface JSF.
Pour supporter cette vision, Seam encourage donc l'adoption d'une architecture Stateful pour gérer la continuité des interactions utilisateur ou événementielles.
Le nom Seam (couture en français) a été choisi pour le projet, car il apporte une fondation qui intègre JSF et EJB 3 ensemble et assemblés, et leur permet de communiquer simplement dans le même conteneur.
Dans le processus de résolution des problèmes entre JSF et EJB3, les architectes de Seam ont inclus la possibilité d'inclure les POJO comme des composants métier, et de ne pas se limiter aux EJB.
Les composants Seam sont donc des POJO simplement enrichis d'une annotation simple et intègrent des services implicites ou déclarés communs aux EJB tels que les transactions, les intercepteurs, la gestion des threads et de la sécurité.
Pour les composants non EJB (pojo, javabeans, springs beans), Seam se charge de traiter les annotations Java EE 5 ou leurs synonymes de l'API Seam en les redirigeant sur les services autogérés, grâce à ses propres surcharges.
Seam est aussi parti du principe de réduire, voire de supprimer la configuration XML longue, difficile à relire et récurrente aux applications JEE utilisant JSF et EJB3, et tant qu'à faire ils l'ont fait pour l'ensemble des éléments intégrés au framework.
Tout cela vous permet entre autres de reconsidérer votre choix d'utiliser les EJB si vous n'avez pas particulièrement besoin de toutes leurs possibilités, en effet vous n'êtes pas obligé d'utiliser JBoss Application Server pour déployer une application Seam en dépit de ce que vous pourriez avoir entendu.
En effet bien que la documentation de Seam recommande l'utilisation de JBoss (n'oublions pas que Seam est soutenu par JBoss), Seam est peut-être le framework respectant le plus Java EE 5 et de ce fait il est compatible avec de nombreux serveurs d'applications.
Weblogic, WebSphere, OC4J, Tomcat (si vous n'utilisez pas EJB) Glassfish.
Avant de passer à une présentation plus détaillée, j'aimerais vous présenter un petit listing des améliorations apportées par Seam à la plateforme Java EE 5 :
- éliminer les lacunes de JSF qui ont fait l'objet d'innombrables débats ;
- permettre la communication entre JSF et les composants métiers transactionnels ;
- supprimer les couches non nécessaires ;
- offrir une solution pour une gestion d'état contextuelle, décourageant l'utilisation d'une architecture Stateless ;
- gérer le contexte de persistance (Session Hibernate ou EntityManager de JPA) pour prévenir les exceptions de Lazy initialisation dans la vue et les requêtes en descendant ;
- fournir un moyen d'étendre le contexte de persistance à la durée d'un cas d'utilisation ;
- connecter les vues aux pages flows stateful ;
- apporter la gestion des processus métier au monde des applications web ;
- connecter aux POJO les mécanismes d'authentification et d'autorisation gérés par JAAS, accessibles via les EL et pouvant être étendues en utilisant des règles déclaratives ;
- fournir un conteneur d'EJB embarqué pour réaliser des tests dans un environnement non JEE ;
- fournir plus de 30 exemples de références dans la version fournie du framework.
Pour plus d'informations, je vous invite donc à télécharger le PDF complet (30 pages) de la présentation :
Le PDF via FTP
Le PDF via HTTP
Merci à RougeCitron pour sa relecture et ses corrections.