Après avoir créé votre projet Java™ ou EJB, vous pouvez créer des beans session, des beans entity et des beans gérés par message à ajouter à votre projet.
Beans enterprise
Un bean enterprise est un composant Java qui peut être combiné à d'autres ressources pour créer des applications Java. Il
existe trois types de beans enterprise : les beans de session, les beans d'entité
et les beans gérés par message. Tous les beans résident dans des conteneurs de beans Enterprise Java (EJB) qui fournissent une interface entre les beans et le serveur d'applications qui les héberge.
La spécification EJB 3.1 rend obsolète les beans entity de style EJB 1.1.
La spécification d'API de persistance Java (JPA) est destinée à remplacer les beans enterprise rendus obsolètes.
Bien que la fonction équivalente, dans la spécification JPA, porte le nom de "classe entité", elle ne doit pas être
confondue avec la notion de bean d'entité. Une entité JPA n'est pas un bean enterprise et n'est pas obligée de s'exécuter dans un conteneur
EJB.
Vous pouvez aussi créer des beans EJB 3.0 et 3.1 dans des projets Web 3.0.
Annotations de définition de composant
A l'aide des annotations de définition de composant,
vous pouvez créer les types de bean enterprise suivants : beans session, beans gérés par messages et
entités JPA. L'inclusion de
l'annotation de définition de composant @Stateful ou @Stateless indique que la
classe est celle d'un bean session ; l'inclusion de l'annotation de définition de composant @Singleton indique qu'il s'agit d'une classe de singleton ; l'inclusion de
l'annotation de définition de composant @MessageDriven indique qu'il s'agit d'une classe de
bean géré par message ; l'inclusion
de l'annotation de définition de composant @Entity indique qu'il s'agit d'une classe entity JPA.
- Beans session : un bean session développé selon la spécification EJB 3.1 nécessite au minimum une classe de bean.
- Avec état : un bean session avec état préserve les informations de session propres au client
(état conversationnel) à travers plusieurs appels de méthode et transactions. Une instance de bean session avec état
possède une identité unique, qui lui est attribuée par le conteneur lors de sa création.
- Sans état : un bean session sans état ne préserve pas l'état conversationnel. Les instances d'un
bean session sans état ne possèdent pas d'état conversationnel. De ce fait, toutes les données échangées entre le client et
l'EJB doivent être transmises sous forme de paramètres d'entrée ou de valeur en retour, déclarés dans l'interface de la
méthode métier de l'EJB.
Toutes les instances d'un bean session sans état possèdent le même identificateur d'objet, qui est
attribué par le conteneur.
- Singleton : les beans session singleton, qui sont nouveaux dans EJB 3.1, constituent un nouveau type de bean session dont l'instanciation est assurée une fois pour une application sur une machine virtuelle Java particulière. Les singletons proposent une fonctionnalité similaire à celle des beans session sans état mais diffèrent de ces derniers car il n'existe qu'un seul bean session singleton par application, et non un pool de beans session sans état pouvant tous répondre à une demande du client. A l'instar des beans session sans état, les beans session singleton peuvent implémenter des noeuds finaux de service Web. Les beans session singleton conservent leur état entre les appels de client mais ne sont pas supposés conserver leur état en cas de panne ou d'arrêt du serveur.
- Beans gérés par message : les beans gérés par message ont été introduits dans EJB 2.0 en vue de la prise en charge du traitement des messages asynchrones depuis un service JMS (Java Message
Service). La
spécification EJB 2.1 développe la définition du bean géré par message afin qu'il puisse prendre en charge tout système de
messagerie, et non uniquement JMS. En termes plus simples, un bean géré par message est un consommateur de messages qui
peut être appelé par son conteneur. Il est appelé par le conteneur lorsqu'un message est reçu. Ces beans constituent un
autre mécanisme d'interaction pour l'appel des EJB, mais, contrairement aux beans session, c'est au conteneur et non au
client (ou à un autre bean) qu'il incombe de les appeler lors de la réception d'un message.
- Entités utilisant l'API JPA (Java Persistence API) :
les entités utilisent la nouvelle API JPA (Java Persistence
API) qui fait partie de la plateforme Java EE
5. Contrairement aux composants EJB qui
utilisent la CMP (persistance gérée par conteneur), les objets entité qui utilisent les nouvelles API ne sont plus des
composants mais simplement des objets Java. Les entités manipulées sont donc plus légères et le modèle de programmation est plus simple
à utiliser. Pour plus d'informations sur
JPA, voir la documentation JPA.
Instructions de développement d'EJB
EJB 3.1 fournit un modèle de programmation simple et souple, mais il est néanmoins conseillé de respecter certaines
règles pour le développement des EJB. En voici quelques-unes :
- Chaque entité doit être un POJO (objet Java "classique") et la classe doit être concrète (et donc ni abstraite ni
finale).
- La classe doit avoir un constructeur sans argument. Dans le cas contraire, le compilateur ajoute un constructeur par
défaut.
- L'objet POJO doit implémenter au moins une interface POJI (interface Java "classique") ; il n'est pas nécessaire d'inclure une interface, mais vous pouvez inclure différentes interfaces pour les clients locaux et distants.
- Si l'interface métier comporte une annotation @Remote, tous les paramètres déclarés dans l'interface doivent
implémenter java.io.Serializable.
- Un EJB session peut sous-classer un POJO, mais il ne peut pas sous-classer un autre EJB session.
Vous pouvez créer des beans enterprise de l'une des manières suivantes :
- en les créant à l'aide des assistants ;
- en les créant à l'aide d'annotations Java EE ;
- en les important depuis des fichiers JAR EJB.