Je suis actuellement amené à utiliser des EJB. Aussi, ne maîtrisant pas vraiment le sujet j’ai fait un condensé ici de ce que j’ai trouvé sur le oueb … autant que ça profite à tout le monde !
Définition :
EJB ou “Enterprise JavaBeans” est une architecture de composants logiciels coté serveur pouvant évoluer dans un contexte transactionnel permettant de représenter :
- des données – Entité (Déprécié. Voir JDO ou JPA : java Persistence API en remplacement.)
- CMP : Container Managed Persistence
- BMP : Bean Managed Persistence
- des services – Session
- Une interface Java : toutes les méthodes déclarées ici sont apellées “Méthodes Métiers”. Elles sont accessible depuis le client
- @Remote : Accessible au travers du réseau
- RMI : remote Method Invocation
- JNDI : Java Naming and Directory Interface
- @Local : Accessible uniquement à partir du serveur d’applications
- @Remote : Accessible au travers du réseau
- Une classe (qui implémente l’interface) : toutes les méthodes qui sont déclarées ici et non dans l’interface ne seront pas accessible depuis le client.
- Une interface Java : toutes les méthodes déclarées ici sont apellées “Méthodes Métiers”. Elles sont accessible depuis le client
- @Stateful : avec conservation de l’état (static)
- Créer un mode Conversationnel
Serveur <======> Client
Coûte au serveur - @Remove / @PrePassivate / @PostActivate
- Créer un mode Conversationnel
- @Stateless : sans conservation de l’état
A utiliser par défaut pour une diminution des coûts serveur.- @PostConstruct / @PreDestroy
Il est possible que ces deux annotations prennent l’attribut : MappedName qui précise le nom de l’EJB dans l’annuaire du serveur d’applications.
- des tâches de manière asynchrone – Message
- Fonctionnent en tandem avec l’API JMS (Java Message Service)
- Réactifs à des évènements
- Abonnés à des fils de discussion
Attention :
- Un EJB n’est pas un composant Multi-thread, de ce fait, il ne peut pas servir plusieurs clients à la fois. La création / fermeture des Thread est de la responsabilité du serveur d’applications.
De plus, il ne doit pas utiliser de mécanisme de synchronisation avec d’autres Thread. - Un EJB ne doit pas utiliser de champs statiques. il est cependant autorisé à les lires.
- Les composants suivant lui sont totalement interdits :
- AWT / Swing
- Clavier
- Console de sortie
- Système de fichiers
- Utilisation directe de sockets
- Accès JDBC directs
- Un EJB ne doit pas tenter d’accéder au(x) “class loader”.
- Un EJB ne doit pas utiliser de librairie native.
- Un EJB ne doit pas passer “this” comme argument d’une méthode qu’il appelle.
Les DAO ou fournisseurs d’objets, placent les objets métiers contenus dans la mémoire vive sur un support physique.
Annotations
EJB Timer
Remarque (bug?) : pour prendre en charge la suite, un serveur d’application Glassfish v3.0.0 à v3.1.1 doit recevoir un paramétrage approprié par cette commande :
asadmin set server.ejb-container.property.disable-nonportable-jndi-names=”true”
@Startup : au lancement de l’EJB. Souvent utilisée avec @Singleton (Design pattern pour assurer une instance unique)
@PostConstruct : Après le lancement
@PreDestroy
@Schedule(dayOfMonth=4,hour=*) : Programme une exécution
@Timeout : désigne la méthode à exécuter
Transactions
@TransactionAttribute(value=?)
- TransactionAttributeType.REQUIRED : S’intègre à une transaction existante, en débute une nouvelle sinon
- TransactionAttributeType.REQUIRES_NEW : Débute une nouvelle transaction systématiquement.
- TransactionAttributeType.MANDATORY : Une transaction doit déjà exister. Sinon, une exception est levée.
- TransactionAttributeType.SUPPORTS : S’intègrera à une transaction existante, mais ne pourra pas en débuter une s’il n’en n’existe pas.
- TransactionAttributeType.NOT_SUPPORTED : Ne sait pas s’intégrer à une transaction existante. Ne sait pas en débuter une.
- TransactionAttributeType.NEVER : N’accepte pas d’être dans une transaction, et lève une exception si une est en cours.
@ApplicationException(rollback=true) : Provoquent l’annulation de la transaction en cours si elles sont levées par le service.
Gestion des transactions :
- Contain Manager : les transactions sont gérées par le serveur d’application, le développeur d’EJB n’a à se préoccuper de rien.
- Bean Managed : l’EJB gère lui même la transaction (fournie par le serveur d’applications) dans laquelle il travaille. Il doit appeller correctement les méthodes :
- begin()
- commit()
- rollback()
