Enterprise JavaBeans

Un article de Wikipédia, l'encyclopédie libre.

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant. (Comment ?).

La technologie Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement J2EE.

Cette architecture propose un cadre pour créer des composants distribués (c’est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java hébergés au sein d'un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des services avec ou sans conservation d'état entre les appels (EJB dit session), ou encore d'accomplir des tâches de manière asynchrone (EJB dit message). Tous les EJB peuvent évoluer dans un contexte transactionnel.

De la version 1.0 à la version 2.1, un EJB était accompagné d'un ou plusieurs fichiers de déploiement écrit en XML qui permettait au serveur applicatif de déployer correctement l'objet au sein d'un conteneur. C'était notamment dans ces fichiers de déploiement que le développeur avait la possibilité de préciser le cadre transactionnel dans lequel l'objet allait s'exécuter. Depuis la version 3.0, le modèle EJB utilise le principe d'annotation java (meta-données) pour spécifier toute la configuration et les propriétés transactionnelles de l'objet. Le fichier de code source de l'EJB se suffit à lui même.

C'est le serveur applicatif qui a en charge la création, la destruction, la passivation ou l'activation de ses composants en fonction des besoins. Le client via un appel RMI (ou une de ses dérivées) va rechercher un EJB par son nom logique JNDI et appeler une/des méthodes de cet objet.

Sommaire

1 Les EJB session (Session Bean)
- 1.1 Stateless Session Bean
- 1.2 Stateful Session Bean
2 Les EJB entité
3 Les EJB message
4 Liens externes

[modifier] Les EJB session (Session Bean)

Les EJB sessions sont des objets proposant des services à leur appelant. Ils proposent un certain nombre de méthodes écrites par le développeur. Il y a deux types d'EJB session: les EJB sessions ne conservant pas leur état entre deux appels (EJB dit "stateless"), et ceux le conservant (EJB dit "stateful"). Il n'y a aucune garantie qu'entre deux appels au même EJB l'instance de l'objet soit la même.

[modifier] Stateless Session Bean

La particularité principale d'un Stateless Session Bean est de ne pas conserver d'état entre les différents appels.

@Stateless
public class StatelessSessionBeanImpl implements StatelessSessionBean {
 
    public String sayHello() {
        return ("Hello world !");
    }
}

[modifier] Stateful Session Bean

La particularité principale d'un Stateful Session Bean est de conserver son état entre différents appels de méthodes.

@Stateful
public class StatefulSessionBeanImpl implements StatefulSessionBean {
 
    private String user;
 
    public void login(String user) {
        this.user = user;
    }
 
    public String sayHello() {
        if (user == null)
            return ("Hello world !");
        return ("Hello " + user + " !");
    }
}

[modifier] Les EJB entité

Les EJB entité sont des beans ayant majoritairement pour vocation d'être persistants, c'est-à-dire pouvant être stockés sur un support physique entre deux sessions.
Les EJB entité peuvent être de deux sortes : BMP (Bean Managed Persistence) ou CMP (Container Managed Persistence).

Les EJB BMP sont des beans dont la persistance a dû être programmée par le développeur (Ce dernier doit respecter un format pour la classe et les méthodes à implémenter sont imposées par la norme).

Les EJB CMP sont eux des beans dont la persistance est directement assurée par le conteneur d'EJB ; le mapping entre l'objet et son support de persistance est indiqué au conteneur via les fichiers descripteurs de déploiement. Le développeur une fois le fichier de déploiement réalisé n'a pas besoin d'écrire le code de persistance.

[modifier] Les EJB message

Depuis la norme EJB, cette architecture propose un troisième type de composant : les EJB message permettant de déclencher un processus coté serveur applicatif lors de la publication d'un message asynchrone. Pour ces composants, le client ne s'adresse pas directement aux composants mais publie un message sur un réceptacle JMS (queue ou topic) configuré sur le serveur applicatif qui va alors déclencher l'activation par ce serveur d'une instance de l'EJB concerné pour pouvoir traiter ce message.