Les fondamentaux EJB3

La spécification EJB3

Apparue sous sa version finale en 2006, la spécification EJB3 dispose de nombreux atouts pour redorer un tant soit peu le blason des EJB, terni en grande partie par la complexité de l’ancienne norme EJB2. Comme nous allons le voir, cette nouvelle mouture a bénéficié des apports de frameworks tels que Spring et Hibernate et des annotations emmenés par le JDK5 pour permettre à la communauté des développeurs J2EE/JEE de s’en emparer et de l’adapter à leurs projets. D’EJB1 à EJB3 Attendue avec impatience par la communauté Java, EJB3, dont les premières « épreuves » ont paru en 2003, est une étape importante pour la spécification EJB, qui compte déjà plus de huit ans d’évolutions. Répondant aux souhaits des développeurs et aux best practices de développement, cette nouvelle spécification a pour premier avantage décomplexifier fortement la précédente. Rappelons les dates clés qui ont jalonné l’évolution de la spécification :  Les fondamentaux EJB3 Développement EJB3 avec Eclipse et Web Tools PARTIE III 198 • 2005 : EJB 3.0 • 2006 : phase finale de la spécification EJB 3.0 Définie par la JSR-220, la spécification EJB3 comporte trois documents distincts : • EJB3 simplified API, qui fournit une description globale du nouveau modèle de développement EJB3. • EJB3 Core Contracts and Requirements, qui se concentre sur les beans de types session et orientés message (MDB). • Java Persistence API, qui s’applique aux beans entité et aux frameworks de persistance. Le nouveau modèle de composants EJB3 définit toujours les mêmes types d’objets : • Les beans session, qui exécutent les services et opérations métier et orchestrent les transactions. Il existe deux types de bean session : – Les beans session stateless (sans état), qui ont une durée de vie limité et qui se limitent à l’invocation de la méthode et à la récupération de son résultat (exemple : une classe MailSender chargée de l’envoi de messages). – Les beans session stateful (avec état), qui permettent la conservation de l’état transactionnel (exemple : caddy virtuel). • Les beans MDB, qui sont invoqués de manière asynchrone et répondent aux événements extérieurs par le biais d’une file de messages (exemple : un bean chargé de la commande d’articles à un centre de gestion des commandes). • Les beans entité, qui disposent d’un unique identifiant et représentent les données persistantes du modèle métier. Ils peuvent être utilisés pour mapper une entrée dans la table de la base avec une classe Java (mapping objet-relationnel), le serveur d’applications fournissant les fonctionnalités pour charger, mettre à jour et supprimer les valeurs de l’instance de classe dans la base. La différence fondamentale entre EJB2 et EJB3 tient à ce que les beans entité sont désormais gérés par un fournisseur de persistance particulier (TopLink, Hibernate, etc.), et non plus par le conteneur. Ils ne sont donc plus considérés comme de « vrais » beans d’entreprise. Cette volonté de séparer les services de persistance du conteneur est la réponse au reproche fait à EJB2 de ne rendre utilisables les couches implémentées avec des EJB qu’au sein de conteneurs EJB, rendant problématiques les tests unitaires. Concernant enfin la persistance, EJB3 propose un nouveau modèle de persistance, Java Persistence API, totalement inspiré d’Hibernate. La spécification JEE5, qui intègre EJB3, prend la suite de J2EE 1.4 (notez l’abandon du « 2 » de J2EE, qui faisait référence au JDK 1.2). La version qui succède à J2SE 5.0 se nomme Java SE 6, ou JSE6. L’objectif de JEE5 est avant tout de simplifier le développement des applications Java d’entreprise. Elle intègre bon nombre de fonctionnalités EJB3, telles que les annotations, la programmation de POJO (Plain Old Java Objects), l’injection de dépendances, de nouvelles API, de nouveaux frameworks, etc. Les points forts de cette « révolution » du modèle EJB sont détaillés à la section suivante, ainsi que dans les différents chapitres suivants.

Principales nouveautés d’EJB3

Nous ne présentons ici que les fonctionnalités marquantes de la spécification EJB3, lesquelles seront mises en œuvre tout au long des chapitres de cette partie. Modèle simplifié grâce aux annotations EJB3 apporte une simplification des développements grâce aux annotations, une nouvelle fonctionnalité du langage Java 5.0 en lieu et place des descripteurs de déploiement. Les annotations sont des métadonnées qui permettent à certains outils de générer des constructions additionnelles à la compilation ou à l’exécution ou encore de renforcer un comportement voulu au moment de l’exécution (comme la nature « sans état » d’un composant EJB). Les annotations simplifient considérablement l’écriture des programmes, comme nous l’avons vu au chapitre précédent avec Seam. Les annotations permettent « d’attacher » des informations additionnelles (couramment appelées attributs) aux classes Java et aux interfaces, ainsi qu’aux méthodes et aux variables qui les composent. Ces informations additionnelles apportées par les annotations peuvent être assimilées à des interfaces. Elles peuvent être utilisées dans un environnement de développement tel qu’Eclipse ou WebTools, voire Dali, comme nous le verrons au chapitre 11, et par les différents assistants de déploiement du conteneur JEE. Elles rendent ainsi caduques les descripteurs de déploiement de la norme EJB2 tels que ejb-jar.xml. La figure 9.1 illustre la complémentarité entre POJO et annotations.

Introduction aux beans session

Quel que soit le niveau de la norme EJB utilisée, les beans session sont des composants qui s’exécutent au sein d’un conteneur EJB standalone ou d’un serveur d’applications. Ces composants sont utilisés pour représenter des cas d’utilisation ou des traitements spécifiques du client. Ils gèrent les opérations sur les données persistantes, mais non les données persistantes elles-mêmes. Il existe deux types de beans session : les beans non persistants (stateless) et les beans persistants (stateful). Quand utiliser des beans session ? Cette question se pose de manière identique avec les EJB3 et les EJB2. Un bean session est utilisé pour modéliser un processus métier nécessitant le maintien d’un état conversationnel pour le client. Il permet en outre de modéliser les traitements associés, souvent avec l’aide d’un bean entité pour les opérations transactionnelles associées et la persistance. Exemples de situation Typiquement, un bean session est utilisé pour : • Modéliser un traitement dont l’état ne sera pas rendu persistant et pour une durée déterminée. • Modéliser un traitement de gestion des employés d’une société en leur affectant un service et un profil d’identification dans le système cible en liaison avec un annuaire. • Créer un bordereau de commande pour un client du système. • Gérer et orchestrer les méthodes dites CRUD (création, lecture, mise à jour, suppression) sur une entité du modèle métier. Avantages Voici quelques-uns des avantages offerts par les beans session : • Amélioration des services du serveur d’applications en apportant des fonctionnalités évoluées de gestion transactionnelle. • Aide aux besoins de déploiement du client lorsque que l’application cliente n’est pas localisée dans le même serveur.  Les fondamentaux EJB3 CHAPITRE 9 203 • Amélioration de la sécurité fournie par le conteneur au niveau du composant et de la méthode. Beans session sans état Les beans session non persistants sont les types d’EJB les plus simples à implémenter. Ils ne conservent aucun état de leur conversation avec les clients entre les invocations de méthodes et sont donc facilement réutilisables dans la partie serveur. Comme ils peuvent être mis en cache, ils supportent bien les variations de la demande. Lors de l’utilisation de beans session non persistants, tous les états doivent être stockés à l’extérieur de l’EJB. Création de beans session sans état Pour créer un bean session sans état en utilisant la spécification EJB3, il suffit d’utiliser l’annotation @Stateless appliquée à la classe, comme dans l’exemple suivant : package com.eyrolles.chap09.exempleSession ; public interface CalculSalaire { public final static double tauxHoraire = 7 ; public double getSalaire(int nbreHeures) ; } package com.eyrolles.chap09.exempleSession ; import javax.ejb.Local ; @Local public interface CalculSalaireLocal extends CalculSalaire {} import javax.ejb.Stateless; @Stateless public class CalculSalaireBean implements CalculSalaireLocal { public CalculSalaireBean() {} public double getSalaire(int nbreHeures) { return nbreHeures*tauxHoraire ; } } La classe CalculSalaireBean (remarquez l’extension Bean après le nom de la classe, qui est une convention de nommage bien pratique) n’utilise pas d’interface particulière, comme javax.ejb.SessionBean, ni d’interface EJBHome ou EJBObject, si familières de générations de développeurs EJB2.