EJB 3

formation interne pour CLIO S.A.

Cdric BOTTERO Michal MATHIEU Genve, le 30 juin 2009

Plan
Introduction 3 types dEJB (Session, Entity, Message-Driven) Injection et JNDI Intercepteurs et callbacks Transactions (CMT, BMT) Scurit Persistance avec JPA

Introduction
Permet dviter au dveloppeur davoir se proccuper de tout ce qui a trait au systme :
Transactions Scurit Evolutivit Concurrence Communications Gestion des ressources Persistance Gestion des erreurs Etc.

3 types dEJB
Session
Stateless Stateful

Entity (depuis la version 3, est un simple POJO) Message-Driven

Session
Sont conus pour encapsuler la logique mtier Les plus utiliss 2 types dEJB session :
Stateless Stateful

Session -> Stateless

Stateless (sans tat) => les attributs de lEJB sont rinitialises entre chaque appel mme sil sagit du mme client Sont spcialement penss pour tre robustes et fiables lorsquil y a beaucoup dappels en concurrence

Lorsquun client appelle lEJB, une instance de ce dernier sert le client, puis, retourne dans le pool dEJB (cette dernire est donc prte a tre rutilise pour un autre client) A utiliser le plus souvent possible (par rapport aux Stateful) => cycle de vie

EJB 2 vs. 3
Pour les EJB session stateless, nous commencerons par prsenter leur utilisation avec les EJB 2, puis avec les 3 Le but est de montrer les amliorations et simplifications amenes avec la version 3 Cela permettra galement de mieux comprendre le principe de fonctionnement des EJB (par exemple, lutilisation du javax.rmi.PortableRemoteObject.nar row())

Structure dun EJB

Avec les EJB 2, la configuration des EJB se fait dans le fichier META-INF/ejb-jar.xml Avec les EJB 3, le fichier de configuration nest plus ncessaire: la configuration se fait dans le code au moyen des annotations

Session -> Stateless

EJB 2

Session -> Stateless

EJB 2

Par convention, et ce afin dviter des malentendus, les mthodes mtier ne doivent pas commencer par ejb

Session -> Stateless

EJB 2
META-INF/ejb-jar.xml

Session -> Stateless

EJB 2

Session -> Stateless

EJB 3

Session -> Stateless

EJB 3

Session -> Stateful

Stateful (avec tat) => les attributs de lEJB sont sauvegards durant toute la session

Lorsquun client appelle lEJB, une instance de ce dernier est cre, puis sert le client. Cette instance reste disponible pour les futurs appels de ce client uniquement. Cette instance sera dtruite la fin de la session (timeout ou appel une mthode portant lannotation @Remove) Sil y a trop dinstances dun EJB en mmoire, ces dernires peuvent tre sorties de la mmoire de travail. Elles passent ainsi en mode passif (= sauves sur disque => tous les attributs doivent tre srialisables = types implmentant linterface Serializable)

Srialisation
Le type des attributs et le type de retour de chaque mthode doivent tre Serializable (sauf dans le cas dune mthode dun EJB stateless local) Par prcaution, nous tcherons de veiller ce que tous les types que nous utilisons soient Serializable Le serialVersionUID permet de faire la distinction entre des objets de mme type, mais dune version diffrente Lorsque quun objet est reu, le destinataire vrifie que le serialVersionUID de lobjet reu correspond celui de la classe quil a charg. Sil diffre, une InvalidClassException est lance Ce mcanisme permet de sassurer que lmetteur et le destinataire travaillent avec la mme version de lobjet Cette solution a une faiblesse: lors dune modification, elle ncessite que toutes les applications qui utilisent cette classe doivent tre mis jour, alors que cela nest pas forcment ncessaire. En effet, dans le cas o on ajoute un nouvel attribut un objet, cela ne signifie pas forcment que toutes les applications ont lutilit de ce nouvel attribut => on donne une valeur arbitraire par dfaut au serialVersionUID et on ne la modifie pas

Local vs. Remote

Permet de spcifier la manire daccder lEJB => limplmentation des services est identique Local appel un EJB se trouvant sur la mme machine = appel un EJB se trouvant dans la mme JVM Remote
utilise RMI (Remote Method Invocation) (=> plus lent quun appel local) et JNDI (Java Naming and Directory Interface) utilis dans la majorit des cas

Local
EJB 2

Local
EJB 2

Local
EJB 2
META-INF/jboss.xml

Local
EJB 2

Local
EJB 2
META-INF/jboss.xml

Local
EJB 2

Local
EJB 3

Entity
Permet de grer la persistance comme le ferait Hibernate sur le concept de object-relational mapping (ORM) => illusion de travailler avec une base de donnes objet Le mapping ne se fait plus forcment dans un fichier XML (comme hibernate.cfg.xml), mais directement dans le code avec des annotations (@Id, @Column, etc.) Davantage de dtails dans le dernier chapitre de ce cours Persistance avec JPA

Message-Driven
Permet des applications de communiquer entre elles, en tant faiblement couples, et de manire asynchrones Ce concept est connu sous le nom de Message-oriented middleware (MOM) Les produits implmentant ce mcanisme sont nombreux comme IBM WebSphere MQ (anciennement MQSeries), JBoss Messaging (qui remplacera JBoss MQ), etc. PTP (point-to-point)
javax.jms.Queue

pub-sub (publish-subscribe)
javax.jms.Topic

Message-Driven
Nous devons configurer le produit qui implmente le mcanisme JMS. Ici, il sagit de JBoss MQ qui est intgr notre version de JBoss (4.0.5-GA) Le fichier de configuration doit tre dpos dans le rpertoire <jboss-install>/server/<configurationname>/deploy/jms, et son nom doit se terminer par service.xml

Message-Driven
EJB 3

Message-Driven
EJB 3

Message-Driven
EJB 3

Message-Driven
Il y a la possibilit de mettre un filtre sur les messages qui peuvent tre traits par un MDB. Cela permet de ne pas recevoir certains messages. Cette proprit est surtout intressante dans le cas dune Queue (PTP), car le message nest envoy qu un seul MDB. Dans le cas dun Topic (pubsub), cela permet surtout de ne pas avoir tester si le message reu peut tre trait par le MDB Pour davantage de prcisions sur la proprit messageSelector, nous vous renvoyons la page 131 du livre EJB 3 in Action , 2007, Manning

Injection et JNDI
Lannotation @Resource permet dinjecter un objet rfrenc (au sens large: DataSource, JMS, EJB, Context, etc.). Il est possible de spcifier le nom JNDI de lobjet pour lever une ambigut. Par exemple, dans le cas dune DataSource, sil y en a plusieurs dfinies sur le serveur, il faudra alors donner son nom JNDI (@Resource(name="jdbc/myDB")avec les EJB 2, dans le descripteur de dploiement, on utilisait la balise <res-ref-name>) Il est galement possible dinjecter des variables denvironnement (de type String, Character, Byte, Short, Integer, Long, Boolean, Double ou Float) qui ont t pralablement dclares dans le descripteur de dploiement :

Lors du dploiement, le conteneur rsout les rfrences JNDI et relie les ressources en question. Si une ressource nest pas trouve lors du dploiement, le conteneur lance une RuntimeException; lEJB est alors inutilisable

Intercepteurs
Lorsquune mthode mtier est appele, les intercepteurs permettent dexcuter des mthodes avant que la mthode mtier ne soit excute Les intercepteurs peuvent tre utiles dans plusieurs situations: pour mettre des logs sans avoir surcharger le code, pour grer la scurit sparment du code mtier, etc. Exemple pour vrifier le rle de lappelant :

Intercepteurs
EJB 3

Les intercepteurs peuvent tre dfini au niveau du descripteur de dploiement, de la classe, de la mthode (ordre dans lequel ils sont appels)

Callbacks
Les callbacks permettent dexcuter des mthodes lorsque certains vnements lis au cycle de vie de lEJB interviennent (cration, suppression, hibernation, rveil) Aprs la cration (@PostConstruct) (Stateless, Stateful, Message-Driven) Avant la suppression (@PreDestroy) (Stateless, Stateful, Message-Driven) Avant lhibernation (@PrePassivate) (Stateful) Aprs le rveil (@PostActivate) (Stateful)

Intercepteurs et callbacks
Session -> Stateless

Intercepteurs et callbacks
Session -> Stateful

Intercepteurs et callbacks
Entity

Intercepteurs et callbacks
Message-Driven

Transactions
ACID Atomicit Pour atteindre un but donn, une transaction est compose de plusieurs oprations qui sont indispensables => soit toutes les oprations sont effectues, soit aucune ! Cohrence Aprs quune transaction se soit ralise, le base de donnes ou le systme doit se trouver dans un tat cohrent Isolation Une transaction doit se raliser sans dpendre des autres transactions qui peuvent avoir lieu en mme temps Durabilit Lorsquune transaction sest termine, le rsultat de cette dernire est durable : que la transaction ait t annule ou quelle se soit termine correctement, les oprations quelle a effectu ne doivent pas disparatre Exemple : transfert bancaire

Transactions
JTA (Java Transaction API) fournit un API permettant de grer les transactions :
BMT (Bean-Managed Transactions) => @TransactionManagement(TransactionManagementTyp e.BEAN) CMT (Container-Managed Transactions) => @TransactionManagement(TransactionManagementTyp e.CONTAINER) Par dfaut, le conteneur gre les transactions

JPA (Java Persistance API) ne dpend pas du mode de gestion des transactions => ninflue que sur les EJB Session et les Message-Driven, et non sur les Entity

CMT
Le conteneur dmarre, valide ou annule la transaction. La transaction commence au dbut de lexcution de la mthode mtier appele et se termine la fin de cette dernire
Transaction @TransactionAttribute existante lors de l'appel ? REQUIRED (par dfaut) REQUIRED_NEW Non Oui Non Oui Non Oui Non Oui Non Oui Non Oui Rsultat Le conteneur cre une nouvelle transaction La mthode rejoint la transaction existante Le conteneur cre une nouvelle transaction Le conteneur cre une nouvelle transaction et la transaction existante est suspendue Aucune transaction n'est utilise La mthode rejoint la transaction existante Lve une javax.ejb.EJBTransactionRequiredException La mthode rejoint la transaction existante Aucune transaction n'est utilise La transaction existante est suspendue et la mthode est appele sans transaction Aucune transaction n'est utilise Lve une javax.ejb.EJBException

SUPPORTS MANDATORY

NOT_SUPPORTED

NEVER

CMT
On peut forcer le fait que la transaction soit annule (context.setRollBackOnly()) Les mthodes setRollbackOnly() et getRollbackOnly() ne peuvent tre appeles que depuis un EJB dont les transactions sont gres par le conteneur (CMT) et ayant comme attribut de transaction REQUIRED, REQUIRED_NEW ou MANDATORY Sinon une IllegalStateException est leve ! Si le conteneur dtecte une exception systme (principalement les RuntimeException) comme une ArrayIndexOutOfBoundsException ou une NullPointerException, la transaction sera automatiquement annule

CMT
Avec CMT, nous navons pas le contrle sur le moment o la transaction est dmarre, valide ou annule Il est possible dtre inform de ces vnements grce des callbacks LEJB doit implmenter linterface javax.ejb.SessionSynchronization
void afterBegin() Est appel juste aprs que le conteneur ait cr une nouvelle transaction et avant que la mthode mtier soit appele void beforeCompletion() Est appel lorsque la mthode mtier sest termine et juste avant que le conteneur termine la transaction void afterCompletion(boolean committed) Est appel aprs que la transaction soit termine. Le flag committed indique si la transaction a t valide (true) ou si elle a t annule (false)

BMT
On utilise la UserTransaction
@Resource private UserTransaction userTransaction; OU @Resource private SessionContext context; ... UserTransaction userTransaction = context.getUserTransaction();

userTransaction.begin(); ... userTransaction.commit(); OU userTransaction.rollback(); La UserTransaction ne peut tre utilise que dans le cas o les transactions sont gres par lEJB (BMT); dans le cas o cest le conteneur (CMT) une IllegalStateException est leve

Transactions distribues XA (eXtended Architecture)

Afin de garantir les proprits ACID vues prcdemment, dans un contexte o les sources de donnes sont distribus, il faut que les drivers des bases de donnes soient de type XA Larchitecture XA dfinit un protocole de validation en 2 phases et un API pour la communication entre un transaction manager et un resource manager Dans le cas dune transaction o lon doit enregistrer des donnes dans 2 bases de donnes, que faire si lors de la validation une se droule avec succs et lautre non ? Lapplication se trouvera alors dans un tat inconsistant et les proprits ACID ne seront plus respectes ! => utilisation du protocole de validation en 2 phases

Scurit
JAAS (Java Authentication and Authorization Service) est une API standard de Java permettant de grer les identifications et les droits associs (par rles) au niveau du client et du serveur d'application Principe de fonctionnement :
Dans un premier temps, JAAS authentifie (valide l'identit du client) Puis gre les autorisations (valide les droits d'accs pour un client authentifi) Les identits sont regroupes en rles et les autorisations accordes par rle

Ct client, la technique la plus simple, mais aussi la plus ancienne et la plus limite : le username (Context.SECURITY_PRINCIPAL) et le password (Context.SECURITY_CREDENTIAL) sont transmis avant le lookup au contexte JNDI

Scurit
Lauthentification est ralise par une application web qui ensuite appelle lEJB en lui passant le Principal

Pour scuriser une mthode, il existe 2 possibilits :

Avec les annotations (@RolesAllowed(...), @PermitAll, @DenyAll) Avec la mthode isCallerInRole(...)

Scurit
Dans un premier temps, il faut configurer la scurit JAAS sur le serveur Pour nous simplifier la tche, nous utiliserons la mthode dauthentification SimpleServerLoginModule :
Si le mot de passe est null, alors lutilisateur est authentifi avec le rle guest Si le nom dutilisateur est gal au mot de passe, alors lutilisateur est authentifi avec les rles guest et user Sinon lauthentification choue

Pour cela, nous devons dfinir une politique de scurit dans le fichier <jbossinstall>/server/<configuration-name>/conf/loginconfig.xml

Scurit
Remarque : dans le cadre dune vraie application, nous aurions plutt utilis la mthode dauthentification DatabaseServerLoginModule qui effectue une requte dans une base de donnes qui contiendrait les noms dutilisateurs, les mots de passe, ainsi que les rles associs aux utilisateurs Dans les 2 exemples qui suivent, on dclare le domaine de scurit par lannotation @SecurityDomain(...) ATTENTION utiliser linterface org.jboss.annotation.security.SecurityDoma in et non org.jboss.aspects.security.SecurityDomain

Scurit
Avec les annotations

Scurit
Avec la mthode isCallerInRole(...)

Scurit
Pour pouvoir accder aux mthodes prcdemment scurises, il faut que lappelant soit correctement identifi avec JAAS Prenons le cas dune application web

Scurit
Dfinir le domaine de scurit : fichier <your-webapp>/WEB-INF/jboss-web.xml

Dfinir ce qui sera scuris, comment, et quelle sera la page dauthentification et la forme de celle-ci : fichier <yourweb-app>/WEF-INF/web.xml (contenu sur le slide suivant)

Scurit
Page JSP qui permet dappeler lauthentification JAAS : fichier <your-web-app>/WEB-INF/jsp/login.jsp

Scurit
Appel de lEJB depuis la Servlet :

Persistance avec JPA

Intrt de JPA: permet dtre indpendant du framework grant la persistance => si Hibernate venait disparatre, lutilisation de son successeur ne demanderait que peu dadaptation Pour cette partie, nous partons du principe que vous tes dj familiaris avec Hibernate et avec le concept dORM (ObjectRelational Mapping) Au passage, nous profitons pour vous indiquer une excellente rfrence : Hibernate 3.0, 2005, Eyrolles

Persistance avec Hibernate

Un petit rappel sera tout de mme le bienvenu !

Les diffrents types de relations :

one-to-one many-to-one one-to-many => => => <one-to-one name="user" class="User" constrained="true" /> (Email.hbm.xml) <many-to-one column="NATIONALITY" name="nationality class="Country" /> (User.hbm.xml) <set name="users" inverse="true"> <key column="NATIONALITY" /> <one-to-many class="User" /> </set> (Country.hbm.xml) <set name="bookmarks" table="WEBSITE_USER"> <key column="ID_USER" /> <many-to-many class="WebSite" column="ID_WEBSITE" /> </set> (User.hbm.xml)

many-to-many

=>

Persistance avec JPA

Activer la persistance JPA (META-INF\persistence.xml)

Au pralable une DataSource a t dclare sur le serveur (<jboss-install>/ server/ <configuration-name> /deploy)

Persistance avec JPA

@Entity Cette annotation permet de spcifier quune classe doit tre persiste par JPA Cette classe doit possder un constructeur public ou protected sans argument @Transient Permet de spcifier quil ne faut pas persister un attribut donn

Persistance avec JPA

@Id Permet de dfinir quel champ sera utilis comme cl primaire @IdClass, @Embeddable + @EmbeddedId Permettent de dfinir des cls composes Nous nallons pas les aborder dans le cadre de ce cours Nous vous renvoyons la page 235 du livre EJB 3 in action , Manning, 2007

ORM
@OneToOne Remarque: fonctionne trs bien dans une utilisation nave , mais cela devient problmatique lorsque lon veut utiliser des fonctionnalits plus intressantes, comme @PrimaryKeyJoinColumn

[http://en.wikibooks.org/wiki/Java_Persistence/Identity_and_S equencing#Primary_Keys_through_OneToOne_Relationships]
@OneToMany @ManyToOne @ManyToMany

ORM

ORM

ORM

ORM
Inconvnients des annotations, surtout dans le cas de la persistance JPA :
Dgrade la lisibilit du code Perte de la sparation entre Entit et Mapping En cas de modification, ncessite de recompiler les classes modifies, au lieu de juste modifier les fichiers de mapping concerns

=> utiliser plutt dans le cas dun prototype Solution plus lgante : utilisation dun fichier de mapping XML (META-INF\orm.xml) (contenu sur les slides suivant)

orm.xml (1/2)

orm.xml (2/2)

Hritage
Avec JPA, il est galement possible davoir une notion dhritage entre les entits Le dveloppeur doit choisir la manire dont seront stockes les informations (@Inheritance(strategy= ...)):
une seule table (InheritanceType.SINGLE_TABLE) plusieurs tables lies (InheritanceType.JOINED) des tables indpendantes (InheritanceType.TABLE_PER_CLASS)

Pour davantage de prcisions, nous vous renvoyons la page 284 du livre EJB 3 in Action , 2007, Manning + http://en.wikibooks.org/wiki/Java_Persistence/Inheritance

Callbacks
Comme pour les EJB session et les Message-Driven, il existe des callbacks pour le Entity Avant / aprs la persistance dune Entity (@PrePersist / @PostPersist) Aprs avoir charg une Entity lors dune requte ou dun refresh (@PostLoad) Avant / aprs la mise jour dune Entity (@PreUpdate / @PostUpdate) Avant / aprs la suppression dune Entity (@PreRemove / @PostRemove)

Rfrences
EJB 3 in action, 2007, Manning JBoss in action, 2009, Manning

The J2EE 1.4 Tutorial, 2005, SUN [http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html] EJB 2, 2005, SUPINFO [http://www.labo-sun.com/resource-fr-essentiels835-0-java-j2ee-ejb-2-les-entreprise-java-bean-javabeans-.htm] EJB 3, 2006, SUPINFO [http://www.labo-sun.com/resource-fr-essentiels836-0-java-j2ee-ejb-3-les-entreprise-java-bean-version-3-javabeans-.htm] Java Persistence, WIKIBOOKS [http://en.wikibooks.org/wiki/Java_Persistence]

FIN
Merci pour votre attention !