Les ANNOTATIONS des EJB
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.
• 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.
Les annotations au lieu du
descripteur de
déploiement.
Fichier ejb-jar pour CountBean.java
<?xml version="1.0" encoding="UTF-8" ?>
<ejb-jar
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd"
version="3.0">
<entreprise-beans>
<session>
<ejb-name>examples.session.stateful_dd.Count</ejb-name>
<remote>examples.session.stateful_dd.Count</remote>
<ejb-class>examples.session.stateful_dd.CountBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
<lifecycle-callbacks>
<callback-listener>
examples.session.stateful_dd.CountCallbacks
</callback-listener>
</session>
</entreprise-beans>
</ejb-jar>
CountBean.java annoté
@Stateful
@Remote(Count.class)
@Interceptors(CountCallbacks.class)
Public class CountBean implements Count {
public int count() {
…
}
…
}
Exemples des annotations
des EJB
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é
...
Les annotations pour préciser le
type de l'EJB
● 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
● Pour les Entity Beans, on utilisera les
annotations pour indiquer le mapping
entre la classe java et les données dans
la BD
@Entity
Les annotations pour préciser le
type d’accès
@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.
Les annotations pour la gestion du
cycle de vie des EJB
• 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.
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
Les annotations pour l’injection
des dépendances
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
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
Les annotations pour la gestion des
transactions
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.
@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
@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
Les annotations pour la sécurité
• 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.
● 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.
@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
Points Négatifs
• 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é.
Merci pour votre attention

Les annotations

  • 1.
  • 2.
    Présentation • La version1.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 versionEJB 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.
  • 4.
    Les annotations aulieu du descripteur de déploiement.
  • 5.
    Fichier ejb-jar pourCountBean.java <?xml version="1.0" encoding="UTF-8" ?> <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_3_0.xsd" version="3.0"> <entreprise-beans> <session> <ejb-name>examples.session.stateful_dd.Count</ejb-name> <remote>examples.session.stateful_dd.Count</remote> <ejb-class>examples.session.stateful_dd.CountBean</ejb-class> <session-type>Stateful</session-type> <transaction-type>Container</transaction-type> <lifecycle-callbacks> <callback-listener> examples.session.stateful_dd.CountCallbacks </callback-listener> </session> </entreprise-beans> </ejb-jar>
  • 6.
  • 7.
  • 8.
    Plusieurs annotations sontdé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é ...
  • 9.
    Les annotations pourpréciser le type de l'EJB
  • 10.
    ● La seuleannotation 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 lesEntity Beans, on utilisera les annotations pour indiquer le mapping entre la classe java et les données dans la BD @Entity
  • 12.
    Les annotations pourpréciser le type d’accès
  • 13.
    @Remote: permet unaccè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.
  • 14.
    Les annotations pourla gestion du cycle de vie des EJB
  • 15.
    • Jusqu'à laversion 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éthodeest 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
  • 17.
    Les annotations pourl’injection des dépendances
  • 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 sontdé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
  • 20.
    Les annotations pourla gestion des transactions
  • 21.
    Le conteneur d'EJBpropose 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 demettre 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éciserle 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
  • 24.
    Les annotations pourla sécurité
  • 25.
    • Les autorisationsreposent 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éfinitiondes 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 dedé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
  • 28.
  • 29.
    • L'utilisation desannotations 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é.
  • 30.