ejb - sebabarre/wikiDoc GitHub Wiki

EJB

Table of Contents

Introduction

Les EJB sont des composants côté serveur servant de couche métier, devant s’éxécuter dans un conteneur, et séparant la couche persistance (JPA) de la couche présentation (web, Swing, etc…​). La couche métier modélise les actions de l’application. Souvent, cette couche interagit avec des services web externes (SOAP ou REST), envoie des messages asynchrones (JMS), s’occupe de la sécurité, poste des emails et constitue un point d’entrée pour toutes sortes de clients comme les interfaces web (servlets ou beans gérés par JSF).

Types d’EJBs

Il existe 3 types d’EJBS :

  • EJB session

    • Sans état : Le bean de session ne contient aucun état conversationnel entre les méthodes et n’importe quel client peut utiliser n’importe quel instance.

    • Avec état : Le bean de session contient l’état conversationnel qui doit être mémorisé entre les méthodes pour un utilisateur donné.

    • Singleton : Un bean de session unique est partagé par les clients et autorise les accès concurrents.

  • EJB messages

  • EJB entity (remplacé par JPA dans EJB 3.0, JPA sortie de la spécification EJB en 3.1)

Déclaration d’EJB

@Stateless
public class BookEJB {
....
}

L’annotation @Stateless suffit à transformer une classe Java en composant transactionnel et sécurisé.

Cette simplicité s’applique aussi au code client. L’appel d’une méthode de BookEJB ne nécessite qu’une seule annotation, @EJB, pour obtenir une référence à l’aide d’une injection. Cette injection de dépendances permet à un conteneur (client, web ou EJB) d’injecter automatiquement une référence vers un EJB. Ci-dessous, par exemple, la classe Main obtient une référence à BookEJBRemote en annotant par @EJB l’attribut statique et privé bookEJB. Si l’EJB est déployé dans un conteneur, Main doit accéder à cet EJB à distance : il suffit d’ajouter une interface distante à l’EJB pour qu’on puisse y accéder à distance.

public class Main {
  @EJB
  private static BookEJBRemote bookEJB;
  public static void main(String[] args) {
  ....
    }
  }

La création de l’instance EJB se fait par injection ou par recherche JNDI.

Note
 Les EJB peuvent être aussi déployés avec le descripteur de déploiement facultatif ejb-jar.xml, qui, s’il est présent, a priorité sur les annotations.

Conteneur d’EJB

Lorsque l’EJB est déployé, le conteneur s’occupe de toutes ces fonctionnalités :

  • Communication distante: Un client EJB peut appeler des méthodes à distances via des protocoles standard.

  • Injection de dépendances: Le conteneur peut injecter plusieurs ressources dans un EJB (destinations et fabriques JMS, sources de données, autres EJB, variables d’environnement, etc.).

  • Gestion de l’état: Le conteneur gère l’état des beans de façon transparente.

  • Pooling: Le conteneur créé pour les beans sans état et les MDB un pool d’instance qu peut être créé par plusieurs clients.

  • Cycle de vie: Le conteneur prend en charge le cycle de vie de chaque composant.

  • Messages: Le conteneur permet aux MDB d’écouter les destinations et de consommer les messages sans qu’il soit nécessaire de trop se plonger dans les détails de JMS.

  • Gestion des transactions: Avec la gestion déclarative des transactions, un EJB peut utiliser des annotations pour informer le conteneur de la politique de transaction qu’il doit utiliser. C’est le conteneur qui prend en charge la validation ou l’annulation des transactions.

  • Sécurité: Les EJB peuvent préciser un contrôle d’accès au niveau de la classe ou des méthodes afin d’imposer une authentification de l’utilisateur et l’utilisation de rôles.

  • Gestion de la concurrence: À part les singletons, tous les autres types d’EJB sont thread-safe par nature.

  • Intercepteurs transversaux: Les problèmes transversaux peuvent être placés dans des intercepteurs qui seront automatiquement appelés par le conteneur.

  • Appels de méthodes asynchrones: Avec EJB 3.1, il est désormais possible d’avoir des appels asynchrones sans utiliser de messages.

Conteneur intégré

Le principe d’un conteneur intégré est de pouvoir exécuter des applications EJB dans un environnement Java SE afin de permettre aux clients de s’exécuter dans la même JVM. Ceci permet notamment de faciliter les tests et l’utilisation des EJB dans les applications classiques.

L’extrait de code suivant montre comment créer une instance d’un conteneur intégré, obtenir un contexte JNDI, rechercher un EJB et appeler l’une de ses méthodes :

EJBContainer ec = EJBContainer.createEJBContainer();
Context ctx = ec.getContext();
BookEJB bookEJB = (BookEJB) ctx.lookup("java:global/BookEJB");
bookEJB.createBook(book);

Injection de dépendances et JNDI

L’injection a lieu lors du déploiement. Si les données risquent de ne pas être utilisées, le bean peut éviter le coût de l’injection en effectuant à la place une recherche JNDI. En ce cas, le code ne prend les données que s’il en a besoin au lieu d’accepter des données qui lui sont transmises et dont il n’aura peut-être pas besoin.

Note
 JNDI est une API permettant d’accéder à différents types de services d’annuaires, elle permet au client de lier et de rechercher des objets par nom. JNDI est définie dans Java SE et est indépendante de l’implémentation sous-jacente, ce qui signifie que les objets peuvent être recherchés dans un annuaire LDAP (Lightweight Directory Access Protocol) ou dans un DNS (Domain Name System) à l’aide d’une API standard.

Appel par injection

@EJB
private static BookEJB bookEJB;

Appel par JNDI

Context ctx = new InitialContext();
BookEJB bookEJB = (BookEJB)ctx.lookup("java:global/chapter06/BookEJB");
Note
 Convention de nommage JNDI : java:global[/<nom-app>]/<nom-module>/<nom-bean>[!<nom-interface-pleinement-qualifié>]

Assemblage

Un EJB est assemblé dans un fichier .jar. Plusieurs EJB sont intégrés dans un fichier .ear pour un deploiement simultané.
Depuis EJB 3.1, les EJB peuvent également être assemblés directement dans un fichier.war.

Note
 Le descripteur de deploiement ejb-jar.xml est déployé dans le dossier META-INF dans le module ejb, et dans le dossier WEB-INF dans le module web.

EJB 3.1

La spécification EJB 3.1 ajoute les fonctionnalités et les simplifications suivantes :

  • Vue sans interface. On peut accéder aux beans de session avec une vue locale sans passer par une interface métier locale.

  • Déploiement war. Il est désormais possible d’assembler et de déployer directement les composants EJB dans un fichier war.

  • Conteneur intégré. Une nouvelle API embeddable permet d’exécuter les composants EJB dans un environnement Java SE (pour les tests unitaires, les traitements non interactifs, etc.).

  • Singleton. Ce nouveau type de composant facilite l’accès à l’état partagé.

  • Service timer plus élaboré. Cette fonctionnalité permet de créer automatiquement des expressions temporelles.

  • Asynchronisme. Les appels asynchrones sont désormais possibles sans MDB.

  • EJB Lite. Définit un sous-ensemble de fonctionnalités utilisables dans les profils Java EE (le profil web, par exemple).

  • Noms JNDI portables. La syntaxe de recherche des composants EJB est désormais standard.

⚠️ **GitHub.com Fallback** ⚠️