2. Présentation
• La version 1.0 très simple
• la version 2.0 introduit de nombreuses nouveautés avec
la possibilité de travailler directement (via des EJB
particuliers) sur des données stockées dans une base de
données relationnelle.
3. • la version EJB 3.0, introduite en 2006, a pour objectif de
simplifier l'utilisation et le déploiement de cette
technologie.
➢ Les fichiers XML de déploiement sont remplacés par des
annotations placées directement dans le code des EJB.
➢ Le programmeur n'est plus obligé d'implémenter de
nombreuses interfaces (au sens java du terme). Les
annotations vont simplifier les choses.
8. Plusieurs annotations sont définies par les
spécifications des EJB pour permettre de déclarer:
❖ le type de bean
❖ le type de l'interface
❖ des références vers des ressources qui seront
injectées
❖ la gestion des transactions
❖ la gestion de la sécurité
...
10. ● La seule annotation obligatoire dans
un EJB est celle qui précise le type
d'EJB
@javax.ejb.Stateless: précise que le
bean est de type Stateless
@javax.ejb.Stateful: précise que le
bean est de type Stateful
@javax.ejb.MessageDriven: précise
que le Bean est de type MessageDriven
11. ● Pour les Entity Beans, on utilisera les
annotations pour indiquer le mapping
entre la classe java et les données dans
la BD
@Entity
13. @Remote: permet un accès à
l'EJB depuis un client hors de la
JVM.
@Local: permet un accès à l'EJB
depuis un client dans la même
JVM que celle de l'EJB.
15. • Jusqu'à la version 2.1 des EJB, il était obligatoire
d'implémenter plusieurs méthodes relatives à la
gestion du cycle de vie de l'EJB notamment
ejbActivate, ejbLoad, ejbPassivate, ejbRemove, ...
pour chaque EJB même si ces méthodes ne
contenaient aucun traitement.
• Avec les EJB 3.0, l'implémentation de ces méthodes
est remplacée par l'utilisation facultative
d'annotations sur les méthodes concernées.
16. Annotation Rôle
@PostConstruct
la méthode est invoquée après que
l'instance est créée et que les dépendances
sont injectées
@PostActivate
la méthode est invoquée après que
l'instance de l'EJB est désérialisée du
disque. C'est l'équivalent de la méthode
ejbActivate() des EJB 2.x
@Remove
la méthode est invoquée avant que l'EJB ne
soit retiré du conteneur
@PreDestroy
la méthode est invoquée avant que
l'instance de l'EJB ne soit supprimée
@PrePassivate
la méthode est invoquée avant que de
l'instance de l'EJB ne soit sérialisée sur
disque. C'est l'équivalent de la méthode
ejbPassivate() des EJB 2.x
18. Le conteneur peut être utilisé pour assurer l'injection
de dépendances de certaines ressources requises par
exemple par un contexte de persistance ou un autre
EJB, grâce à des annotations déchargeant le
développeur de l'écriture du code utilisant JNDI ou un
objet de type EJBContext.
L'injection de dépendances est réalisée au moment de
l'instanciation du bean par le conteneur
19. Plusieurs annotations sont définies pour
mettre en oeuvre l'injection de
dépendances :
● @EJB :permet d'injecter une référence
vers un autre EJB.
● @Resource :injecter une dépendance vers
une ressource externe
● @PersistenceContext: permet d’ injecter
un objet de type EntityManager
● @WebServiceRef : permet d’injecter une
référence vers un service web
● ….
•@Resource
21. Le conteneur d'EJB propose un support des transactions
par déclaration ce qui évite d'avoir à mettre en oeuvre
explicitement une API de gestion des transactions dans
le code.
22. @TransactionAttribute permet de mettre en
oeuvre les transactions par déclaration.
Elle permet de préciser dans quel contexte
transactionnel une méthode d'un EJB sera
invoquée.
Elle s'utilise sur une classe d'un EJB ou sur
une méthode d'un EJB session. Utilisée sur
une classe, l'annotation s'applique à toutes les
méthodes de l'EJB.
● TransactionAttributeType.MANDATORY
● TransactionAttributeType.REQUIRED (valeur par
défaut)
● ….
•@Resource
23. @TransactionManagement: permet de
préciser le mode de gestion des
transactions. Elle s'utilise sur une classe
d'un EJB session ou message driven.
Ce mode peut prendre deux valeurs :
-gestion par le container (valeur par défaut)
TransactionManagementType.CONTAINER
-gestion par le code de l'EJB:
TransactionManagementType.BEAN
Rq:
cette valeur est incompatible avec l’annotation
@TransacrionAttribute
il est donc nécessaire de coder la gestion des transations
dans les méthodes qui en ont besoin en utilisant l'API
JTA
•@Resource
25. • Les autorisations reposent en Java EE sur la notion
de rôle. Un ou plusieurs rôles sont affectés à un
utilisateur.
• Même s'il est possible d'utiliser une API dédiée,
généralement la mise en oeuvre de la sécurité dans
les EJB se fait de manière déclarative.
26. ● La définition des restrictions d'accès permet la
mise en oeuvre des mécanismes d'autorisation.
● Les spécifications des EJB 3.0 définissent plusieurs
annotations pour gérer et mettre en oeuvre la
sécurité dans les accès réalisés sur les EJB.
27. @DeclareRoles permet de définir la liste des rôles
qui sont utilisés par un EJB . Elle s'applique
uniquement sur une classe
@RolesAllowed: permet de préciser les rôles qui
seront autorisés à invoquer les méthodes de l'EJB.
Elle s'applique sur une classe ou une méthode.
@PermitAll: permet l'invocation par tout le monde :
c'est l'annotation par défaut si aucune restriction n'est
définie.(classe ou méthode)
@DenyAll: permet d'empêcher l'invocation d'une
méthode quel que soit le rôle de l'utilisateur qui
l'invoque.
@RunAs : permet de préciser le rôle sous lequel un
EJB va être exécuté dans le conteneur
indépendamment du rôle de l'utilisateur. classe
29. • L'utilisation des annotations va simplifier le
développement des EJB mais la gestion de la
configuration pourra devenir plus complexe
puisqu'elle n'est plus centralisée.
• Chaque vendeur peut définir en plus ses
propres annotations dans l'implémentation de
son serveur d'applications. Leur utilisation
n'est cependant pas recommandée car elle
rend l'application dépendante du serveur
d'applications utilisé.