Cours Complet2012

Enterprise JavaBeans 3.
0
Introduction gnrale
Michel Buffa (buffa@unice.fr), UNSA 2006
Les promesses des EJB
Enterprise JavaBeans
Standard industriel pour un modle de composant logiciel
distribu,
Permet d'implmenter des "objets mtier" d'une manire
propre et rutilisable,
Pour le dveloppement RAD d'applications ct serveur
Questions :
De quoi a-t-on besoin lorsqu'on dveloppe une application
distribue oriente objet ?
Qu'est-ce que les EJBs et qu'apportent-elles ?
Quels sont les acteurs dans l'cosystme EJB ?
Motivation des EJBs
Considrons : un site de gestion de portefeuille
boursier, une application bancaire, un centre
d'appel, un systme d'analyse de risque
Nous parlons ici d'applications distribues.
Choses considrer lorsqu'on construit
une application distribue
Si on prend une application monolithique et
qu'on la transforme en application distribue,
o plusieurs clients se connectent sur plusieurs
serveurs qui utilisent plusieurs SGBD, quels
problmes se posent alors ?
Choses considrer lorsqu'on construit
une application distribue
Protocoles d'accs distants (CORBA, RMI, IIOP)
Gestion de la charge,
Gestion des pannes,
Persistence, intgration au back-end,
Gestion des transactions,
Clustering,
Redploiement chaud,
Arrt de serveurs sans interrompre l'application,
Gestion des traces, rglages (tuning and auditing),
Programmation multithread
Problmes de nommage
Securit, performances,
Gestion des tats
Cycle de vie des objets
Gestion des ressources (Resource pooling)
Requte par message (message-oriented midddleware)
Qui s'occupe de tout ceci : le middleware !
Dans le pass, la plupart des entreprises
programmaient leur propre middleware.
Adressaient rarement tous les problmes,
Gros risque : a revient cher (maintenance,
dveloppement)
Orthogonal au secteur d'activit de l'entreprise
(banque, commerce)
Pourquoi ne pas acheter un produit ?
Oracle, IBM, BEA proposent depuis plusieurs
annes des middleware
Aussi appels serveurs d'application.
Serveur d'application : diviser pour rgner !
Un serveur d'application fournit les services
middleware les plus courants,
Permettent de se focaliser sur l'application que
l'on dveloppe, sans s'occuper du reste.
Le code est dploy sur le serveur
d'application.
Sparation des mtiers et des spcificits :
d'un ct la logique mtier, de l'autre la logique
middleware.
Serveurs d'application
HTML
Java
Application
Business Logic
Distributed
Objects
Transactions
Content
Management
Scalability Reliability Security Manageability
Enterprise Deployment Services
Development Tools
Presentation
Java
HTML
Data
Data Access
Enterprise Data
Connectors
Data Access
Objects
Encore mieux !
Il est possible d'acheter ou de rutiliser une
partie de la logique mtier !
Vous dveloppez votre application l'aide de
composants.
Code qui implmente des interfaces prdfinies.
Sorte de bote noire.
Un bout de logique facilement rutilisable.
Un composant n'est pas une application complte.
Juste un bout.
On assemble les composants comme un puzzle,
afin de rsoudre des problmes importants.
Composant logiciel rutilisable
Une entreprise peut acheter un composant et
l'intgrer avec des composants qu'elle a
dvelopp.
Par exemple, un composant qui sait grer des prix.
On lui passe une liste de produits et il calcule le prix
total.
Simple en apparence, car la gestion des prix peut
devenir trs complexe : remises, promotions, lots,
clients privilgis, rgles complexes en fonction du
pays, des taxes, etc
Ce composant rpond un besoin rcurrent
Vente en ligne de matriel informatique,
Gestion des cots sur une chane de production
automobile,
Calcul des prix des expditions par la poste,
Etc



Quel intrt ?
Moins d'expertise requise pour rpondre
certains points du cahier des charges,
Dveloppement plus rapide.
Normalement, les vendeurs de composants
assurent un service de qualit (BEA, IBM)
Rduction des frais de maintenance.
Naissance d'un march des composants.
Pas encore l'explosion attendue mais
Architectures de composants
Plus de 50 serveurs d'applications ont vu le
jour depuis une dizaine d'annes,
Au dbut, composants propritaires
uniquement.
Pas de cohabitation entre composants dvelopps
pour diffrents serveurs d'application
Dpendant d'un fabriquant une fois le choix
effectu.
Dur avaler pour les dveloppeurs java qui
prnent la portabilit et l'ouverture !
Ncessit de standardiser la notion de
composants
Ensemble de dfinitions d'interfaces entre le
serveur d'application et les composants
Ainsi n'importe quel composant peut tourner ou tre
recompil sur n'importe quel serveur
Un tel standard s'appelle une architecture de
composants
Penser aux CDs audio, la tl, au VHS, etc

Enterprise JavaBeans (EJB)
Le standard EJB est une architecture de
composants pour des composants serveur
crits en java.
1. Adopt par l'industrie. "Train once, code
anywhere"
2. Portable facilement
3. Rapid Application Development (RAD)
EJB signifie deux choses :
1. Une spcification
2. Un ensemble d'interfaces
Pourquoi java ?
EJB = uniquement en java
Sparation entre l'implmentation et l'interface
Robuste et sr : mcanismes + riche API +
spcificit du langage (reflexivit, introspection,
chargement dynamique)
Portable
Autre possibilits
Composants Microsoft .NET
Ruby on rails, Python turbo gears, frameworks java
plus lgers comme WebWork, Spring, etc.
EJB pour dvelopper des composants
business
Implmenter de la logique mtier : calcul des taxes sur
un ensemble d'achats, envoyer un mail de confirmation
aprs une commande, etc
Accder un SGBD
Accder un autre systme d'information (CICS,
COBOL, SAP R/3, etc)
Applications web : intgration avec JSP/Servlets
Web services bass sur XML (SOAP, UDDI, etc)
Exemple : DELL attaque le serveur d'INTEL directement
travers un protocole XML pour rserver des pices.
EJB ne fournit pas de GUI
GUI = ct client
Applications
classiques
Servlets/JSP

L'cosystme EJB
Pour dployer et excuter un projet base
d'EJBs, six mtiers sont impliqus
1 - Le fournisseur d'EJBs
Peut-tre un membre de votre quipe, ou bien une
entreprise qui vend des EJBs
(www.componentsource.com ou
www.flashline.com pour voir une liste)
L'cosystme EJB
2 - L'assembleur d'application
Il s'agit de l'architecte de l'application
Il est client des EJBs achetes ou dveloppes
Il dcide de la combinaison de composants dont il a besoin
Fournit un GUI l'application
Conoit et dveloppe de nouveau composants
Conoit et dveloppe les programmes clients
Dfinit le mapping avec les donnes manipules par les
diffrents composants
En gnral, c'est un expert en Gnie Logiciel, en UML et en
dveloppement Java.
Il peut s'agir d'un intgrateur de systmes, d'un consultant,
d'une quipe de dveloppeurs/concepteurs maison

L'cosystme EJB
3 - Le dployeur d'EJBs
Aprs que l'application ait t assemble, elle doit tre
dploye sur un ou plusieurs serveurs d'application
Attention la scurit (firewall, etc)
Branchement de services annexes (LDAP, Lotus Notes,
Microsoft Active Directory, etc) sur le serveur d'applications.
Choix du hardware, des SGBD, etc
Paramtrage du serveur d'application, optimisation des
performances
Il adapte les composants et le serveur l'application
Il peut tre une quipe ou une personne, un consultant ou un
vendeur d'hbergement de serveurs d'applications.
Exemples aux USA : www.hostJ2EE.com ou
www.loudcloud.com
L'cosystme EJB
4 - L'administrateur systme
Vrifie le bon fonctionnement de l'application en
exploitation.
Il utilise les outils de monitoring des serveurs
d'application.
Il effectue la maintenance hardware et software
(lancement, arrt) du systme.
Certains serveurs d'application savent tlphoner et
appeler l'administrateur systme en cas de
problme.
Ponts avec les outils de Tivoli, Computer
Associates, via JMX.

L'cosystme EJB
5 - Le fournisseur du serveur d'application et des
containers
EJB container = environnement au sein du serveur dans
lequel les EJB vivent.
Le container EJB fournit les services middleware et manage
les EJBs.
Exemples : Weblogic, Websphere, BES, Oracle Orion Server,
JRun, JBoss
Il existe d'autre containers spcialiss (container Web comme
Tomcat, Resin)
Le fournisseur du serveur d'application est le mme que le
fournisseur de containers EJB.
On confond en gnral container et serveur d'application.
L'cosystme EJB
6 - Les vendeurs d'outils
Dvelopper une application base d'EJB est assez
lourd. Pourtant la manire de dvelopper,
construire, maintenir, dployer les EJBs est
standard.
Il est trs pratique d'utiliser un IDE pour simplifier
les tches rptitives comme le dploiement, etc
Principaux IDEs : JBuilder, Visual Age, Visual Cafe.
Autres outils : les outils UML comme Together/J,
Rational Rose
Outil de test (JUnit), de stress (LodeRunner), etc
Les diffrents mtiers

Les diffrents mtiers
Bientt un nouveau mtier : le "persistence
manager"
Dveloppe des outils qui se "branchent" sur le
serveur d'application et implmentent les
mcanismes de persistance.
Mapping BD relationnelles/Objets
Mapping BD objet/Objets
Etc
Pas encore standardis dans la spcification
EJB 2.0
La plate-forme Java J2EE
EJB = la cl de vote d'une architecture distribue
java appele J2EE
Pour le dveloppement d'application serveur
Ensemble de spcifications et d'APIs
Contient deux autres architectures
1. J2ME (Java 2 Micro Edition) : pour les mobiles
2. J2SE : pour applications et applets standards
Non attach un vendeur particulier.
Quiconque respecte les spcification est "J2EE compliant"
Applications dveloppes indpendantes des vendeurs
d'outils.
La plate-forme Java J2EE
Chaque API dans J2EE sa propre
spcification (PDF)
Batterie de logiciel pour valider les
implmentations (test suites)
Implmentation de rfrence
J2EE est livre avec un serveur d'application par
exemple
Ensemble de "blueprints" : dfinit prcisment
le rle de chaque API (PDF)
J2EE : les APIs
J2EE comprend en plus de J2ME et J2SE
EJB : standard de dfinition de composants
Java 2 RMI et RMI-IIOP : objets distribus
JNDI (Java Naming and Directory Interface)
JDBC (Java Data Base Connectivity)
JTA (Java Transaction API)
JMS (Java Messaging Service)
Java Servlets and Java Pages (JSP)
Java IDL (Corba)
JavaMail
JCA (J2EE Connector Architecture) : ponts vers SAP/3,
CICS
JAXP (Java API for XML Parsing)
JAAS (Java Authentification and Authorization Service)
J2EE

J2EE for the Real World
HTML
Java
Application
JTS/JTA JNDI JavaMail RMI-IIOP JMS
Presentation
Servlets/JSP
On Demand
Java
Business Logic
EJB
Triggers
Content
Management
Data Access
JDBC 2.0
Enterprise Data
Connectors
Visual Servlets
Data Access
Objects
Distributed
Data Cache
Development and Deployment Tools
Data
Consistent, Integrated Architecture
JTS/JTA JNDI JavaMail RMI-IIOP JMS
Presentation
Servlets/JSP
On Demand
Java
Business Logic
EJB
Triggers
Content
Management
Data Access
JDBC 2.0
Enterprise Data
Connectors
Visual Servlets
Data Access
Objects
Distributed
Data Cache
Development and Deployment Tools
HTML
Java
Application
Data
EJB : les fondamentaux
Enterprise Bean
Composant serveur qui peut tre dploy
Compos de un ou plusieurs objets
Les clients d'un Bean lui parlent au travers
d'une interface
Cette interface, de mme que le Bean, suivent
la spcification EJB
Cette spcification requiert que le Bean expose
certaines mthodes
Enterprise Bean
Le client d'un Bean peut tre
Une servlet
Une applet
Une application classique
Un autre Bean
On peut dcomposer une application en un graphe de
tches/sous-tches
Exemple : achat d'un CD partir du code-barre
Scanner (qui a une JVM embarque) client d'un Bean sur le
Serveur
Ce Bean client d'autres Beans : gestion de catalogue, de
commandes, de gestion de transaction VISA, etc
Modle flexible, extensible
3 types de Beans : Session Bean
Session Beans
Modlisent un traitement (business process)
Correspondent des verbes, des actions
Ex : gestion de compte bancaire, affichage de
catalogue de produit, vrifieur de donnes
bancaires, gestionnaire de prix
Les actions impliquent des calculs, des accs une
base de donnes, consulter un service externe
(appel tlphonique, etc.)
Souvent clients d'autres Beans
3 types de Beans : Entity Bean
Entity beans
Modlisent des donnes
Correspondent des noms
Ce sont des objets java qui cachent des donnes d'une base
de donnes
Ce sont des objets persistants
Ex : un Bean Personne, un Bean compte bancaire, un Bean
produit, un Bean commande.
Serveurs pour des Beans Session le plus souvent
Servent de proxy entre la logique mtier et les base de
donnes
Mapping base de donne relationnelle/Objet facilit par EJB
2.0

Exemple de Session/Entity bean

Session Bean Entity Bean
Gestion de compte Compte bancaire
Vrificateur de CB Carte de crdit
Systme d'entre gestion
de commandes
Commande, ligne de
commande
Gestion de catalogue Produits
Gestionnaire d'enchres Enchre, Produit
Gestion d'achats Commande, Produit,
ligne de commande
3 types de Beans : Message-Driven Bean
Message-Driven Beans
Introduits prtir de la norme EJB 2.0, nous
sommes aujourdhui en 3.0
Similaire aux Session bean : reprsentent des
verbes ou des actions,
On les invoque en leur envoyant des messages,
Ex : message pour dclencher des transactions
boursires, des autorisations d'achat par CB,
Souvent clients d'autres beans
3 types de Beans : pourquoi ?
Pas d'Entity Beans dans les solutions Microsoft
par exemple
Nombreuses compagnies impliques dans les
standards EJB/J2EE
Leurs clients ont des besoins varis,
Solution propose flexible mais plus complexe,
Standard EJB plus difficile apprendre,
Risque de mauvaise utilisation mais
On est gagnant sur le long terme.
Clients interagissant avec un serveur
base d'EJBs

Les objets distribus au cur des EJBs

Les objets distribus et le middleware
Lorsqu'une application devient importante,
des besoins rcurrents apparaissent :
scurit, transactions,etc
C'est l qu'intervient le middleware!
Deux approches
1. Middleware explicite,
2. Middleware implicite
Middleware explicite

Exemple : transfert d'un compte bancaire vers un
autre :
transfert(Compte c1, Compte c2, long montant)
1. Appel vers l'API middleware qui fait une vrification de
scurit,
2. Appel vers l'API de transaction pour dmarrer une
transaction,
3. Appel vers l'API pour lire des lignes dans des tables d'une
BD,
4. Faire le calcul : enlever de l'argent d'un compte pour le
mettre dans l'autre
5. Appeler l'API pour mettre jour les lignes dans les tables,
6. Appeler l'API de transaction pour terminer la transaction.
Difficile crire,
Difficile maintenir,
Votre code est dpendant des API du vendeur
de middleware que vous utilisez.
Middleware implicite

Les EJB : middleware implicite mais API pour
descendre au bas niveau, Explicite
La plupart du temps le dveloppeur demeure
au niveau implicite,
Mais il peut, mme si le travail est plus
complexe, utiliser des APIs de J2EE pour
contrler manuellement les transactions, la
scurit, etc.
EJB et SOA (Service Oriented Architecture)
Une application = ensemble de services,
Un service = ensemble de composants,
Un composant = des classes,
Les services peuvent tourner sur des
nuds diffrents (des cpus diffrents) et
donc former une architecture distribue
Avantage : souplesse, mise jour, etc Le
code ne change pas quon soit en mono-cpu
ou en distribu.
EJB et SOA (Service Oriented Architecture)
SOA = un paradigme de conception
Service = indpendant, faiblement coupl aux
autres
Les Web Service = un exemple de SOA, mais
il y en a dautres.
Par exemple des services fait dEJBs, les
services du Robotic Studio de Microsoft, etc.
Avant les EJB 3.0 taient les EJB 2.x
et ctait puissant mais trop
compliqu !
EJB 2.0 : constitution dun bean, les
principes sont les mmes en 3.0 sauf
que lon a pas crire autant de code
Constitution d'un EJB : Enterprise Bean
class
La classe du Bean (Enterprise Bean class)
Une classe qui implmente une interface prcise et qui
respecte certaines rgles,
Il s'agit de l'implmentation du bean lui-mme,
Session Bean : logique mtier, calculs, transfert de
compte bancaire, saisie de commandes, etc
Entity Bean : logique oriente donne, par exemple
comment changer le nom d'un client, diminuer un compte
bancaire
Message-Driven Bean : logique oriente message,
traitement aprs rception d'un ordre d'achat d'actions
boursires

Constitution d'un EJB : EJ B Object
Les clients n'invoquent jamais directement les
mthodes de la classe du Bean
Les appels de mthodes (requests) sont
intercepts par le Container, afin d'assurer le
traitement middleware implicite,
Une fois ce traitement effectu, le container
appelle les mthodes de la classe du Bean
Le dveloppeur de composant se concentre
sur la logique, ignore la partie middleware.
Que se passe-t-il lors de l'interception ?
Prise en compte des transactions,
Scurit : le client est-il autoris ?
Gestion des ressources + cycle de vie des composants :
threads, sockets, connexions DB, pooling des instances
(mmoire),
Persistance,
Accs distant aux objets,
Threading des clients en attente,
Clustering,
Monitoring : statistiques, graphiques temps rel du
comportement du systme

Container = couche d'indirection entre le client
et le bean
Cette couche est matrialise par un objet
unique : l'EJB Object
L'EJB Object contient du code spcifique au
container (vendeur-dpendant)
Il appelle les mthode de la classe du Bean,
Il est gnr par le container !
Chaque container est livr avec des outils pour
gnrer les EJB Object pour chaque Bean.
EJB Server
EJB Container
EJ Bean
EJ Bean
Container
EJB
Serveur
EJB
Code simple
Gnration du code
partir du Bean
Le code gnr fournit
Transactions, Securit,
Persistance, Accs
Distant, gestion des
ressources, etc.
Fournit les services au
container
EJB : classe du Bean et EJB Object
Serveur
EJB
Container
EJB
EJ Bean
EJ Bean
Container
EJB
Utilisation du descripteur
de dploiement (fourni
par l'auteur du Bean)
Paramtres de
dploiement = securit,
mappings objets/BD
relationelle, etc.)
Gnration du code pour
intgrer le bean dans le
container, ajout du
plumbing (persistance,
securit, etc)
Code gnr
EJB Object : gnration du code
Constitution d'un EJB : l'interface distante
Les clients invoquent les mthodes des EJB
Objects,
Ces EJB Objects doivent cloner toutes les
mthodes que le bean expose,
Comment l'outil qui gnre l'EJB Object peut-il
connatre la liste des mthodes cloner ?
Rponse : il utilise une interface fournie par le
programmeur du bean, l'interface distante
public interface javax.ejb.EJBObject extends java.rmi.Remote {
public abstract javax.ejb.EJBHome getEJBHome()
throws java.rmi.RemoteException;

public abstract java.lang.Object getPrimaryKey()

public abstract void remove()
throws java.rmi.RemoteException,
javax.ejb.RemoveException;

public abstract javax.ejb.Handle getHandle()

public abstract boolean isIdentical(javax.ejb.EJBObject)
}

Le programmeur du Bean drivera son
interface distante de javax.ejb.EJBObject,
Rajoutera les signatures des mthodes qu'il
souhaite exposer,
Qui implmentera cette interface ?
L'EJB Object gnr par le container !
Presque rien faire pour le dveloppeur de
bean !
Java RMI-IIOP et EJB Objects
Javax.ejb.EJBObject drive de
java.rmi.Remote,
Quiconque implmente Remote est appelable
distance depuis une autre JVM,
EJB Objects = RMI-IIOP + EJB compatibles
RMI-IIOP = convention de passage de
paramtres + valeurs de retour lors d'appels de
mthode distante, entre autres
Constitution d'un EJB : Home Object
Nous avons vu comment les clients appelaient
les mthodes d'un Bean : via l'EJB Object.
Mais comment obtiennent-ils une rfrence sur
l'EJB Object ?
En effet : pas d'instanciations lorsque on
travaille avec des objets distants !
Solution : le client demande la rfrence une
fabrique d'EJB Objects (EJB Object Factory)
Design pattern!
L'EJB factory est responsable de l'instanciation
et de la destruction des EJB Objects.
La spcification EJB appelle cette factory un
Home Object.
Responsabilits du Home Object
Crer les EJB Objects,
Trouver les EJB Objects existants (Entity beans
seulement)
Supprimer les EJB Objects.
Comme les EJB Objects, les Home Objects
sont gnrs par le container
Contiennent du code spcifique,
Assurent le load-balancing, etc
Constitution d'un EJB : l'interface Home
Comment un Home object sait de quelle
manire le client veut initialiser l'EJB Object ?
Rappel : au lieu d'appeler un constructeur, on
demande au Home object de retourner une
rfrence.
Comme pour les constructeurs, il est possible de
passer des paramtres d'initialisation.
Comme pour les EJB Objects, le dveloppeur
du bean doit spcifier une interface Home
L'interface Home dfinit
Les mthodes pour crer, dtruire et localiser les
EJB Objects
Le Home Object (gnr par le container)
implmente cette interface.
L'interface fournie par le dveloppeur drive de
javax.ejb.EJBHome
Javax.ejb.EJBHome drive de java.rmi.Remote
Les Home objects sont aussi des objets distants,
compatibles RMI-IIOP
public interface javax.ejb.EJBHome extends java.rmi.Remote {
public EJBMetaData getEJBMetaData()

public javax.ejb.HomeHandle getHomeHandle()

public void remove(Handle handle)
throws java.rmi.RemoteException

public void remove(Object primaryKey)
throws java.rmi.RemoteException,
}

Constitution d'un EJB : les interfaces
locales
Problme : la cration de bean et l'appel de
mthode distante cotent cher !
locales
Commentaires sur la figure prcdente
1. Le client appelle un stub (souche),
2. Le stub encode les paramtres dans un format capable de
voyager sur le rseau,
3. Le stub ouvre une connexion sur le skeleton (squelette),
4. Le skeleton dcode les paramtres,
5. Le skeleton appelle l'EJB Object,
6. L'EJB Object effectue les appels middleware,
7. L'EJB Object appelle la mthode du bean,
8. Le Bean fait son travail,
9. On fait le chemin inverse pour retourner la valeur de retour
vers le client !
10. Sans compter le chargement dynamique des classes
ncessaires !
locales
Nouveau dans EJB 2.0 : les interfaces locales.
Introduit la notion de Local Object, en remplacement
de EJB Object
Les Local Objects implmentent une interface locale
au lieu d'une interface distante
Exemple d'appel de mthode distante
1. Le client appelle le Local Object,
2. Le Local Object appelle le middleware puis la mthode du
bean
3. La valeur de retour est renvoye au Local Object, puis au
client

locales
Pour l'appel distant de mthodes, le dveloppeur peut
fournir une interface locale, qui sera implmente par
le container en tant que Local Object
A distinguer du cas "normal" (EJB 1.1) ou on a interface
distante implmente par EJB Object
Pour la cration/localisation de beans, le dveloppeur
peut fournir une interface home interface locale, qui
sera implmente par le container en tant que Home
Object local
A comparer avec Home Interface implmente par le container
en tant que Home Object
locales
Les interfaces locales ne tournent que si les EJB sont
dans le mme processus (mme container),
Attention, paramtres et valeurs de retour (lors des
appels de mthodes) se passent maintenant par
rfrence
Toujours par valeur dans le cas d'appels distants!
Plus performant mais smantique diffrente.
Difficile de passer d'une implmentation locale une
implmentation classique
Aurait pu tre fait dans les descripteurs (weblogic)
Constitution d'un EJB : les descripteurs
de dploiement
Pour informer le container des besoins
middleware, on utilise un descripteur de
dploiement (XML)
Standardis,
A l'extrieur de l'implmentation du bean.
Attention si on les crit la main!
Outils d'aide au dploiement : IDEs (Jbuilder, Visual
Cafe), outils spcifiques (Borland Application
Server, Weblogic 6.1)
Descripteurs peuvent tre modifis aprs le
dploiement.
Constitution d'un EJB : les descripteurs
de dploiement
Descripteurs spcifiques au serveur
d'application
Chaque vendeur ajoute des trucs en plus : load-
balancing, persistance complexe, clustering,
monitoring
Dans des fichiers spcifiques (inprise-ejb.xml avec
Borland)
Dploiement : un fichier .jar

Rsum
Enterprise Bean class
Interface distante (remote interface)/Interface locale
EJB Object/Local Object
Home interface/Local Home interface
Home Object/Local Home Object
Descripteur de dploiement standard
Descripteurs spcifiques au vendeur
Fichier .jar de l'EJB

OUF !
Le modle EJB 3.0 a fait le mnage !
Quest-ce qui a chang ?
Pas grand-chose sur le fond, les EJBs adressent
toujours le mme problme,
Beaucoup sur la forme.
Pour les Session Beans et pour les Message Driven Beans :
modle POJO (Plain Old Java Object)
Les dveloppeurs veulent crire du Java, pas du XML et
pas 50 fichiers pour faire HelloWorld !
Pour les Entity Beans, on utilisera les annotations de code
pour indiquer le mapping entre la classe java et les donnes
dans la BD
Le modle EJB 3.0 utilise beaucoup les annotations
de code introduites avec java 1.5

Introduction aux Session Beans
Session Bean : rappel
Un Session Bean reprsente
une action, un verbe,
une logique mtier, un algorithme,
Un enchanement de tches
Exemples
Saisie d'une commande,
Compression vido,
Gestion d'un caddy, d'un catalogue de produits,
Transactions bancaires
Dure de vie d'un Session Bean
Dure de vie = la session
En gros, le temps qu'un client reste connect sur le bean.
Dans une logique e-commerce, le temps qu'un utilisateur est
connect sur le site.
Le container cre une instance lorsqu'un client se
connecte sur le Session Bean.
Il peut le dtruire lorsque le client se dconnecte.
Les Session Beans ne rsistent pas des crashes du
serveur.
Ce sont des objets en mmoire, non persistants.
Le contraire des Entity Beans que nous verrons plus tard.
Types de Session Beans
Chaque EJB a un moment donn entretient
une conversation avec un client.
Conversation = suites d'appels de mthodes.
Il existe deux types de Session Beans
1. Stateful Session Beans,
2. Stateless Session Beans.
Chacun modlisant un type particulier de
conversation.
Stateful Session Beans
Certaines conversations se droulent sous
forment de requtes succesives.
Exemple : un client surfe sur un site de e-
commerce, slectionne des produits, remplit son
caddy
D'une requte HTTP l'autre, il faut un moyen
de conserver un tat (le caddy par ex.)
Autre exemple : une application bancaire. Le client
effectue plusieurs oprations. On en va pas
chaque fois lui redemander son No de compte
Stateful Session Beans
En rsum, un Stateful Session Bean est utile pour
maintenir un tat pendant la dure de vie du client
au cours d'appels de mthodes successifs.
Au cours de transactions successives.
Si un appel de mthode change l'tat du Bean, lors d'un autre
appel de mthode l'tat sera disponible.
Consquence : une instance de Stateful Session Bean
par client.
Avec certains containers, les Stateful Session Beans
peuvent tre persistants (BAS/BES) par srialisation.
Stateless Session Beans
Certaines conversations peuvent se rsumer un
appel de mthode, sans besoin de connatre l'tat
courant du Bean
Ex : simple traitement, simple calcul (validation de No de CB),
compression
Le client passe toutes les donnes ncessaires au traitement
lors de l'appel de mthode.
Le container est responsable de la cration et de la
destruction du Bean
Il peut le dtruire juste aprs un appel de mthode, ou le
garder en mmoire pendant un certain temps pour
rutilisation.
Une instance de Stateless Session Bean n'est pas
propre un client donn, elle peut tre partage entre
chaque appel de mthode.
Pooling des Stateful Session Beans
Le pooling des instances de Stateful Session Beans
n'est pas aussi simple
Le client entretient une conversation avec le bean,
dont l'tat doit tre disponible lorsque ce mme client
appelle une autre mthode.
Problme si trop de clients utilisent ce type de Bean en
mme temps.
Ressources limites (connexions, mmoire, sockets)
Mauvaise scalabilit du systme,
L'tat peut occuper pas mal de mmoire
Problme similaire la gestion des tches dans un
OS
Avec un OS : on utilise le concept de mmoire
virtuelle
Lorsqu'un processus ne fait plus rien (Idle), on
swappe son tat mmoire sur disque dur,
librant de la place.
Lorsqu'on a de nouveau besoin de ce
processus, on fait l'inverse.
Ceci arrive souvent lorsqu'on passe d'une
application l'autre
Avec les Stateful Session Beans on fait pareil !
Entre chaque appel de mthode, un client ne fait
rien (Idle),
Un utilisateur d'un site de e-commerce lit les infos
sur la page www, rflchit de temps en temps il
clique sur un bouton
Pendant qu'il ne fait rien, l'tat du bean est swapp
mais les ressources telles que les connexions BD,
sockets, la mmoire intrinsque qu'il occupe,
peuvent tre utilises par un autre client.
Etc
Ceci a un cot : l'activation/passivation gnre
des E/S
Choix du bean swapper par LRU le plus
souvent (Least Recent Used)
Choix du bean activer : lorsqu'on le demande
(just in time)
En quoi consiste l'tat d'un Bean Stateful?
L'tat conversationnel d'un bean suit les rgles
de la srialisation d'objets en java.
En effet, la passivation (swap de la mmoire vers le
HD) et l'activation (l'inverse) sont ralises par
srialisation.
Rappelez-vous que javax.ejb.EnterpriseBean
implmente java.io.Serializable
Tous les attributs du Bean non transcients sont
donc concerns.

En quoi consiste l'tat d'un Bean Stateful?
Ce sont tous les attributs de la classe +
dautres ceux du code gnr par le
container.
Peut-on effectuer des actions avant la
passivation ou aprs lactivation (librer des
ressources, les re-ouvrir)
Rponse: oui!
Activation/Passivation callbacks
Lorsqu'un bean va tre mis en passivation, le
container peut lavertir (@PrePassivate)
Il peut librer des ressources (connexions)
Idem lorsque le bean vient d'tre activ
(@PostActivate)
Persistance dans Java EE 6 :
JPA2 et EJB 3.1
Note importante
Ce cours couvre les besoins les plus
importants, vous pourrez retrouver un cours
trs complet sur JPA2 et sur la persistence en
java en gnral sur la page de Richard Grin
http://deptinfo.unice.fr/~grin/mescours/minfo/modper
sobj/supports/index.html
Aussi, une bonne rfrence en ligne sur JPA2
http://www.objectdb.com/api/java/jpa, en particulier
la section JPA2 annotations
Contexte
Java EE 6 propose ce quon appelle un web
profile
Un sous-ensemble de java EE pour le
dveloppement dapplication web simples
La suite sera aborde en partie lan prochain
Dans ce web profile on propose :
Vue : JSP ou facelets/JSF2
Contrleur web : Servlets ou web service
Composant mtier : EJB type session + managed
beans + classes java standard,
Accs aux donnes dans une BD via JPA2/EJB
type entity
Contexte

Contexte

Entity Bean, introducton
Un Entity Bean reprsente
Des objets persistants stocks dans une base de
donne,
Des noms, des donnes
Gestion via JPA2 + sessions beans
Dans ce chapitre on tudiera
Le concept de persistance,
Ce qu'est un entity bean, du point de vue du
programmeur,
Les caractristiques des entity beans,
Les concepts de programmation des entity beans.
La persistance par srialisation
Srialisation = sauvegarde de l'tat d'un objet sous
forme d'octets.
Rappel : l'tat d'un objet peut tre quelque chose de trs
compliqu.
Etat d'un objet = ses attributs, y compris les atributs hrits.
Si les attributs sont eux-mme des instances d'une classe, il
faut sauvegarder aussi les attributs de ces instances, etc
A partir d'un tat srialis, on peut reconstruire l'objet
En java, au travers de l'interface
java.io.Serializable, des mthodes de
java.io.ObjectInputStream et
java.io.ObjectOutputStream

La persistance par srialisation
Dfauts nombreux
Gestion des versions, maintenance
Pas de requtes complexes
Ex : on srialize mille comptes bancaires. Comment
retrouver ceux qui ont un solde ngatif ?
Solution : stocker les objets dans une base de
donne!
La persistance par mapping objet/BD
relationelle
On stocke l'tat d'un objet dans une base de
donne.
Ex : la classe Personne possde deux attributs
nom et prenom, on associe cette classe une
table qui possde deux colonnes : nom et
prenom.
On dcompose chaque objet en une suite de
variables dont on stockera la valeur dans une
ou plusieurs tables.
Permet des requtes complexes.

relationelle

relationelle
Pas si simple
Dtermination de l'tat d'un objet parfois difficile,
tout un art
Il existe des produits pour nous y aider
EclipseLink, TopLink (WebGain), Hibernate (JBoss),
Aujourd'hui la plupart des gens font a la main
avec JDBC ou SQL/J.
Mais SQL dur tester/debugger source de
La persistance l'aide d'une BD Objet
Les Base de donnes objet stockent
directement des objets.
Plus de mapping !
Object Query Language (OQL) permet de
manipuler les objets
Relations entre les objets videntes (plus de
join)
Bonnes performances mais mauvaise
scalabilit.

Le modle de persistence JPA 2
JPA 2 propose un modle standard de persistance
laide des Entity beans
Les outils qui assureront la persistance (Toplink,
Hibernate, EclipseLink, etc.) sont intgrs au
serveur dapplication et devront tre compatibles
avec la norme JPA 2.
Java EE 6 repose tous les niveaux sur de
linjection de code via des annotations de code
Souvent, on ne fera pas de new , les
variables seront cres/initialises par injection
de code.

Qu'est-ce qu'un Entity Bean
Ce sont des objets qui savent se mapper dans
une base de donne.
Ils utilisent un mcanisme de persistance
(parmi ceux prsents)
Ils servent reprsenter sous forme d'objets
des donnes situes dans une base de
donne
Le plus souvent un objet = une ou plusieurs ligne(s)
dans une ou plusieurs table(s)
Qu'est-ce qu'un Entity Bean
Exemples
Compte bancaire (No, solde),
Employ, service, entreprises, livre, produit,
Cours, lve, examen, note,
Mais au fait, pourquoi nous embter passer par des
objets ?
Plus facile manipuler par programme,
Vue plus compacte, on regroupe les donnes dans un objet.
On peut associer des mthodes simples pour manipuler ces
donnes
On va gagner la couche middleware !
Exemple avec un compte bancaire

On lit les informations d'un compte bancaire en
mmoire, dans une instance d'un entity bean,
On manipule ces donnes, on les modifie en
changeant les valeurs des attributs d'instance,
Les donnes seront mises jour dans la base
de donnes automatiquement !
Instance d'un entity bean = une vue en
mmoire des donnes physiques
Fichiers composant un entity bean
Schma classique :
La classe du bean se mappe dans une base de donnes.
Cest une classe java normale (POJO) avec des attributs,
des accesseurs, des modifieurs, etc.
On utilisera les mta-donnes ou attributs de code pour
indiquer le mapping, la cl primaire, etc.
Cl primaire = un objet srializable, unique pour chaque
instance. C'est la cl primaire au sens SQL.
Note : on peut aussi utiliser un descripteur XML la place
des annotations de code
On manipulera les donnes de la BD laide des EntityBeans
+ laide dun PERSISTENT MANAGER.
Le PM soccupera de tous les accs disque, du cache, etc.
Lui seul contrle quand et comment on va accder la BD,
cest lui qui gnre le SQL, etc.

Exemple dentity bean : un livre
@Entity
public class Book {

@Id @GeneratedValue
private Long id;
@Column(nullable = false)
private String title;
private Float price;
@Column(length = 2000)
private String description;
private String isbn;
private Integer nbOfPage;
private Boolean illustrations;

// Constructors, getters, setters
}
Exemple dentity bean : un livre

@Entity
public class Book {

@Id @GeneratedValue
private Long id;
@Column(nullable = false)
private Boolean illustrations
Les annotations de code JPA 2
Remarques gnrales (suite)
Nombreuses valeurs par dfaut, par exemple une
classe entit Personne se mappera dans la table
PERSONNE par dfaut, un attribut nom sur la
colonne NOM, etc.
Il existe de trs nombreux attributs pour les
annotations, ce cours prsente les principaux, pour
une tude dtaille, voir la spcification, un livre, ou
le tutorial Java EE 6
Les rgles de JDBC sappliquent pour le mapping
des types. String vers VARCHAR, Long vers
BIGINT, Boolean vers SMALLINT, etc.
Les annotations de code JPA 2
Remarques gnrales
String vers VARCHAR(255) par dfaut,
Les rgles peuvent changer dun SGBD lautre,
par exemple String est mapp sur VARCHAR avec
Derby, mais sur VARCHAR2 avec Oracle. Un
Integer sur un INTEGER avec Derby mais sur un
NUMBER avec Oracle. Etc.
Dans le cas des cls primaires auto-incrmentes,
la manire dont elles sont gres dpend du SGBD
et de loutil de mapping relationnel-objet
Si on en change -> la structure des tables
change !
Exemple dinsertion dun livre
public class Main {

public static void main(String[] args) {

// On cre une instance de livre
Book book = new Book();
book.setTitle("The Hitchhiker's Guide to the Galaxy");
book.setPrice(12.5F);
book.setDescription("Science fiction comedy book");

// On rcupre un pointeur sur lentity manager
// Remarque : dans une appli web, pas besoin de faire tout cela !
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("chapter02PU");
EntityManager em = emf.createEntityManager();

// On rend lobjet persistant dans la base (on linsre)
EntityTransaction tx = em.getTransaction();
tx.begin();
em.persist(book);
tx.commit();

em.close();
emf.close();
}
Client sous forme de session bean
Dans le cas o le client est un session
bean
du code peut tre inject ,
Les transactions sont dclenches par dfaut,
@stateless
public class UnSessionBean {
@PersistenceContext(unitName="EmployeeService")
EntityManager em;
public Employee createEmployee(int id, String name, long salary
, byte[] pic) {
Employee emp = new Employee(id);
emp.setName(name);

em.persist(emp);

return emp;
}
Dans le cas o le client est un session
bean
du code peut tre inject ,
Les transactions sont dclenches par dfaut,
@stateless
public class UnSessionBean {
@PersistenceContext(unitName="EmployeeService")
EntityManager em;
public Employee createEmployee(int id, String name, long salary
, byte[] pic) {
Employee emp = new Employee(id);
emp.setName(name);

em.persist(emp);

return emp;
}
@Stateless
public class BookBean {

@PersistenceContext(unitName = "chapter04PU")
private EntityManager em;

public void createBook() {
Book book = new Book();
book.setId(1234L);
book.setTitle("The Hitchhiker's Guide to the Galaxy");
book.setPrice(12.5F);
book.setDescription("Science fiction created by Douglas Adams.");
book.setIsbn("1-84023-742-2");
book.setNbOfPage(354);
book.setIllustrations(false);

em.persist(book);

// Rcupre le livre dans la BD par sa cl primaire
book = em.find(Book.class, 1234L);

System.out.println(book);
}
}
Remarques : quoi correspond le session
bean ?
On codera la partie mtier
Souvent on utilise un session bean pour la couche
DAO (avec des fonctions de cration,
recherche, modification et suppression dentity
beans)
Exemple : GestionnaireUtilisateurs
On utilisera aussi des session beans pour
implmenter des services composites
Exemple : GestionnaireDeCommandes, qui
utilisera dautres gestionnaires
Autres annotations
@Entity
public class Book {

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@Column(name = "book_title", nullable = false, updatable = false)
@Column(name = "nb_of_page", nullable = false)
private Boolean illustrations;
@Basic(fetch = FetchType.LAZY)
@Lob
private byte[] audioText;

// Constructors, getters, setters
}
Autres annotations (suite)
@Column permet dindiquer des prfrences
pour les colonnes
Attributs possibles : name, unique, nullable,
insertable, updatable, table, length, precision,
scale
@GeneratedValue
Indique la stratgie de gnration automatique des
cls primaires,
La valeur : GenerationType.auto est recommande,
Va ajouter une table de squence
@Lob indique large object (pour un BLOB)
Souvent utilis avec @Basic(fetch =
FetchType.LAZY) pour indiquer quon ne chargera
lattribut que lorsquon fera un get dessus
Autres annotations (suite)
Il existe de nombreuses autres annotations,
Voir par exemple : JPA Reference
http://www.objectdb.com/api/java/jpa
Il se peut que les TPs en introduisent
certaines.
Les curieux peuvent consulter la spcification
java EE 6 ou le tutorial (ou un bon livre)
Exemple de fichier persistence.xml
Ce fichier configure le persistence manager
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"
mlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="IGift-ejbPU" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>jdbc/igift</jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="update"/>
</properties>
</persistence-unit>
</persistence>
Un exemple dentity bean : un compte bancaire
La classe = POJO,
Srializable,
Un attribut = la cl primaire
Cest tout !

Client de lentity bean prcdent : un session
bean (servant de faade/DAO)
Ce session bean est stateless,
Utilise un EntityManager,
Sert envoyer des requtes
JPQL,
Mthode persist(entity) pour
crer une nouvelle entre
(insert)
Le reste passe par des
appels de mthodes
classiques de lentity bean.
Autre version : on garde dans le session bean la
mmoire de lentity bean
Le session bean
est stateful,
Il garde la
rfrence de
lentity bean,
On a du
tendre la
porte du
Persistence
Manager
Suite de lexemple

Dans getBalance() on
utilise plus de find,
On utilise les
Exceptions
Caractristiques des entity beans
Survivent aux crashes du serveur, du SGBD
Ce sont des vues sur des donnes dans un
SGBD
Modifier les donnes sans passer par le
bean

Packager et dployer un Entity Bean
Les EB sont dploys dans des persistence
Units ,
Spcifi dans le fichier persistence.xml qui est
dans le jar contenant les EJBs.
Exemple le plus simple :

Mais on peut ajouter de nombreux paramtres :
<description>, <provider>, <transaction type>,
<mapping file> etc.

Que faire avec un entity manager ?
Etats dun Entity Bean
Un EB peut avoir 4 tats
1. New: le bean existe en mmoire mais nest pas encore
associ une BD, il nest pas encore associ un contexte
de persistence (via lentity manager)
2. Managed : aprs le persist() par exemple. Le bean est
associ avec les donnes dans la BD. Les changements
seront rpercuts (transaction termines ou appel a flush())
3. Detached : le bean est nest plus associ au contexte de
persistenced
4. Removed : le bean est associ la BD, au contexte, et est
programm pour tre supprim (les donnes seront
supprimes aussi).
Utilisation du persistent manager
Remove() pour supprimer des donnes,
Set(), Get(), appel de mthodes de lentity
bean pour modifier les donnes, mais le bean
doit tre dans un tat managed ,
Persist() pour crer des donnes, le bean
devient manag,
Merge pour faire passer un bean detached
dans ltat managed .

Exemple de merge() avec le bean stateless
Recherche d'entity beans
Les entity beans correspondant des lignes
dans une BD, on peut avoir besoin de faire des
recherches.
Similaire un SELECT
Plusieurs fonctions sont proposes par lentity
manager
Recherche dentity beans
Recherche par cl primaire :

Excution de requtes JPQL

Recherche dentity beans
Requtes SQL:

Requtes nommes:

JPQL : Quelques exemples
Voir le fichier PDF fourni avec les TPs !
JPQL : Quelques exemples (suite)
Liste toutes les commandes qui ne
comprennent pas (LEFT) de produit dont le
prix est suprieur une certaine quantit

Requter sur plusieurs attributs renvoie soit un
tableau dObject, soit une collection de tableaux
dObject
texte = "select e.nom, e.salaire " +
" from Employe as e";
query = em.createQuery(texte);
List<Object[]> liste =
(List<Object[]>)query.getResultList();
for (Object[] info : liste) {
System.out.println(info[0] + "gagne"
+ info[1]);
}
Table des compagnies

Table des employs

Cette requte rcupre trois compagnies :

Mais celle-ci uniquement deux :

Celle-l : les trois (mme si join condition
absente)

Provoque le chargement des entities relies

Prend le devant sur @FetchType.LAZY
Autre exemple :

WHERE et requtes paramtres

Autre exemple avec paramtres nomms

Expressions

Le % dans le LIKE = suite de caractres, le _ =
un caractre

MEMBER OF

Sous-Requtes

Fonctions sur chanes, arithmtique

Fonctions sur chanes, arithmtique (suite)

Utiliser des colonnes composites
@Embeddable
public class Address {
protected String street;
protected String city;
protected String state;
@Embedded
Zipcode zipcode;
}
@Embeddable
public class Zipcode {
String zip;
protected String plusFour;
}
Utiliser une cl primaire composite
Similaire lexemple prcdent sauf que au
lieu dutiliser @Embedded / @Embeddable on
utilisera @EmbbededId / Embeddable
@Embeddable
public class CompositeId {
String name;
String email
}
@Entity public class Dependent {
@EmbeddedId // indique que la cl primaire est dans une autre classe
CompositeId id;
@ManyToOne
Employee emp;
}
Relations avec les entity beans
On complique un peu l'tude des entity
beans !
Les entity beans reprsentant des donns
dans une BD, il est logique d'avoir envie de
s'occuper de grer des relations
Exemples
Une commande et des lignes de commande
Une personne et une adresse
Un cours et les lves qui suivent ce cours
Un livre et ses auteurs
Nous allons voir comment spcifier ces
relations dans notre modle EJB
Concepts abords
Cardinalit (1-1, 1-n, n-n),
Direction des relations (bi-directionnelles, uni-
directionnelles),
Agrgation vs composition et destructions en cascade,
Relations rcursives, circulaires, agressive-load, lazy-
load,
Intgrit rfrentielle,
Accder aux relations depuis un code client, via des
Collections,
Comment grer tout a !

Direction des relations (directionality)
Unidirectionnelle
On ne peut aller que du bean A vers le bean B
Bidirectionnelle
On peut aller du bean A vers le bean B et
inversement
Cardinalit
La cardinalit indique combien d'instances vont
intervenir de chaque ct d'une relation
One-to-One (1:1)
Un employ a une adresse
One-to-Many (1:N)
Un PDG et ses employs
Many-to-Many (M:N)
Des tudiants suivent des cours

Cardinalit

Relations 1:1
Reprsente typiquement par une cl
trangre dans une BD
Ex : une commande et un colis

Relations 1:1, le bean Order
Relations 1:1, le bean Order
Relations 1:1, le bean Shipment

Exemple de code pour insrer une commande
avec une livraison relie

Relations 1:1, exemple de client (ici un main)
Version bidirectionnelle (on modifie Shipment)

Version bidirectionnelle (suite)

Version bi-directionnelle (suite, code qui fait le
persist)
On peut maintenant ajouter au code de tout
lheure (celui qui crit une commande) :

Version bi-directionnelle (suite, code du client)

Relations 1:N
Exemple : une entreprise a plusieurs employs
Relations 1:N
Exemple : une entreprise a plusieurs employs
Solution plus propre (viter les BLOBs!)
Relations 1:N exemple

Relations 1:N exemple

Exemple de code qui insre des compagnies

Exemple de code qui liste des compagnies

Exemple de client

Version bidirectionnelle


Relations M:N
Un tudiant suit plusieurs cours, un cours a
plusieurs tudiants inscrits
Table de jointure ncessaire.
Relations M:N, choix de conception
Deux possibilits lorsqu'on modlise cette
relation avec des EJBs
1. Utiliser un troisime EJB pour modliser la table
de jointure. On veut peut-tre mmoriser la date
o un tudiant s'est inscrit, etc Cet EJB
possdera deux relations 1:N vers le bean Student
et le vers le bean Course
2. Si on a rien besoin de plus part la relation, on
peut utiliser simplement deux EJB, chacun ayant
un attribut correspondant une Collection de
l'autre EJB

Relations M:N, exemple




La directionalit et le modle de donnes
dans la DB
La directionalit peut ne pas correspondre
celle du modle de donnes dans la DB
Schma normalis
Schma dnormalis
Choisir la directionalit ?
Premier critre : la logique de votre application,
Second critre : si le schma relationnel existe,
s'adapter au mieux pour viter de mauvaises
performances.
Lazy-loading des relations
Agressive-loading
Lorsqu'on charge un bean, on charge aussi tous les beans
avec lesquels il a une relation.
Cas de la Commande et des Colis plus tt dans ce chapitre.
Dans le ejbLoad() on appelle des finders
Peut provoquer un norme processus de chargement si le
graphe de relations est grand.
Lazy-loading
On ne charge les beans en relation que lorsqu'on essaie
d'accder l'attribut qui illustre la relation.
Tant qu'on ne demande pas quels cours il suit, le bean
Etudiant n'appelle pas de mthode finder sur le bean Cours.
Agrgation vs Composition et
destructions en cascade
Relation par Agrgation
Le bean utilise un autre bean
Consquence : si le bean A utilise le bean B, lorsqu'on dtruit
A on ne dtruit pas B.
Par exemple, lorsqu'on supprime un tudiant on ne supprime
pas les cours qu'il suit. Et vice-versa.
Relation par Composition
Le bean se compose d'un autre bean.
Par exemple, une commande se compose de lignes de
commande
Si on dtruit la commande on dtruit aussi les lignes
correspondantes.
Ce type de relation implique des destructions en cascade..
Relations et EJB-QL
Lorsqu'on dfinit une relation en CMP, on peut
aussi indiquer la requte qui permet de remplir
le champs associ la relation.
On fait ceci l'aide d'EJB-QL
SELECT o.customer
FROM Order o
Principale diffrence avec SQL, l'oprateur "."
Pas besoin de connatre le nom des tables, ni le
nom des colonnes

Renvoie tous
les clients qui
ont plac une
commande
Relations et EJB-QL
On peut aller plus loin
SELECT o.customer.address.homePhoneNumber
FROM Order o
On se promne le long des relations

Relations rcursives
Relation vers un bean de la mme classe
Exemple : Employ/Manager

Rien de particulier, ces relations sont
implmentes exactement comme les relations
non rcursives

Relations circulaires
Similaire au relations rcursives sauf qu'elles
impliquent plusieurs types de beans
Ex : un employ travaille dans une division, une division
possde plusieurs ordinateurs (workstation), une workstation
est alloue un employ

Ce type de relation, en cas de agressive-loading peut
mener une boucle sans fin
Mme problme avec les destructions en cascade

Relations circulaires
Plusieurs stratgies sont possibles
1. Certains containers proposent d'optimiser le chargement d'un
bean en chargeant toutes ses relations en cascade dans le
ejbLoad(). Attention si relations circulaires !
2. Supprimer une des relations (!!!) si le modle de conception
le permet.
3. Supprimer la bidirectionnalit d'une des relations pour briser
le cercle, si le modle de conception le permet.
4. Utiliser le lazy-loading et ne pas faire de destruction en
cascade.
5. Les meilleurs moteurs CMP dtectent les relations circulaires
et vous permettent de traiter le problme avant le runtime.

Intgrit rfrentielle
Un bean Compagnie, Division, etc a des
relations avec un bean Employ
Si on supprime un employ, il faut vrifier qu'il est
bien supprim partout o on a une relation avec lui.
Problme classique dans les SGBDs
Rsolus l'aide de triggers. Ils se dclenchent sitt
qu'une perte d'intgrit risque d'arriver et effectuent
les oprations ncessaires.
On peut aussi utiliser des procdures stockes via
JDBC. Ces procdures effectuent la vrification
d'intgrit.
Intgrit rfrentielle
Grer l'intgrit dans le SGBD est intressant
si la BD est attaque par d'autres applications
que les EJBs
Autre approche : grer l'intgrit dans les EJBs
Solution plus propre,
Le SGBD n'est plus aussi sollicit,
Avec les EJB: le travail est fait tout seul !
Intgrit rfrentielle
Et dans un contexte distribu ?
Plusieurs serveurs d'application avec le mme
composant peuvent accder des donnes
sur le mme SGBD,
Comment mettre jour les relations ?
Problme rsolu par les transactions !!!
Trier les relations
Lorsquon accde aux relations par un getter,
on ne contrle pas par dfaut lordre des
lments.
Plusieurs solutions sont possibles pour
rcuprer des relations sous forme de
collections tries
Utiliser lannotation @OrderBy juste avant la
dclaration de la relation ou juste avant le getter
Utiliser une requte avec un Order By
Annoter lattribut correspondant la colonne qui
sera ordonne, dans lentity de la relation
Trier des relations : annotation @OrderBy
@Entity public class Course {
...
@ManyToMany
@OrderBy("lastname ASC")
List<Student> students;
...
}
Remarques
ASC ou DESC pour lordre de tri, ASC par dfaut,
lastname est une proprit de lentit Student.java,
Si la proprit nest pas spcifie -> tri par lid
@Entity public class Student {
...
@ManyToMany(mappedBy="students")
@OrderBy // tri par cl primaire (dfaut)
List<Course> courses;
...
}
Remarques
ASC ou DESC pour lordre de tri, ASC par dfaut,
lastname est une proprit de lentit Student.java,
Si la proprit nest pas spcifie -> tri par lid
On peut utiliser loprateur . si on trie sur
une colonne qui est dfinie dans une autre
classe par @Embedded
@Entity public class Person {
...
@ElementCollection
@OrderBy("zipcode.zip,
zipcode.plusFour")
Set<Address> residences;
...
}
@Embeddable
public class Address {
protected String street;
protected String city;
protected String state;
@Embedded
Zipcode zipcode;
}
@Embeddable
public class Zipcode {
String zip;
protected String plusFour;
}
Concepts avancs sur la persistence
Introduction
Et le polymorphisme ?
Et lhritage ?
Et EJB-QL ?
Hritage
Stratgies de mapping entre classes et tables
quand on a de lhritage ?
Une table pour toute la hirarchie de classes ?
Une table par classe/sous-classe ?
Autres solutions ?
Un exemple !

Code de RoadVehicle.java (classe racine)
Code de Motorcycle.java
Code de Car.java
Code de Roadster.java
Code de Coupe.java
Premier cas : une seule table !
Une seule table reprsente toute la hirarchie.
Une colonne de discrimination est utilise
pour distinguer les sous-classes.
Cette solution supporte le polymorphisme.
Dsavantages :
Une colonne pour chaque champ de chaque classe,
Comme une ligne peut tre une instance de chaque
classe, des champs risquent de ne servir rien
(nullable)
Regardons le code avec les annotations !
(suite)
Motorcycle.java annot !
Car.java annot
Roadster.java annot
Coupe.java annot
Table correspondante
Quelques objets persistants !
Et les donnes correspondantes
Deuxime stratgie : une table par classe
Il suffit de modifier quelques annotations !
Dans RoadVehicle.java

Il faut retirer les @Discriminator des sous-classes,
Le champ Id de la classe RoadVehicle sera une cl trangre
dans les tables des sous-classes,
Remarque : on utilise ici @TABLE pour ne pas que la table porte
le mme nom que dans lexemple prcdent (facultatif)
Les tables !
Les tables (suite)
Requte SQL pour avoir tous les Roadsters
Il faut faire des joins !
Plus la hierarchie est profonde, plus il y aura
de jointures : problmes de performance !

Conclusion sur cette approche
Supporte le polymorphisme,
On alloue juste ce quil faut sur disque,
Excellente approche si on a pas une hirarchie
trop profonde,
A viter sinon
Autres approches
Des classes qui sont des entity bean peuvent
hriter de classes qui nen sont pas,
Des classes qui ne sont pas des entity beans
peuvent hriter de classes qui en sont,
Des classes abstraites peuvent tre des entity
beans,
(dj vu : une classe qui est un entity bean
hrite dune autre classe qui est un entity
bean)
Cas 1 : Entity Bean tends classe java
On utilise lattribut @mappedsuperclass dans
la classe mre
Indique quaucune table ne lui sera associe

Cas 1 (les sous-classes entities)
Cas 1 : les tables
Remarques sur le cas 1
RoadVehicle naura jamais sa propre table,
Les sous-classes auront leur propre table,
avec comme colonnes les attributs de
RoadVehicle en plus des leurs,
Si on avait pas mis @MappedSuperclass dans
RoadVehicle.java, les attributs hrits
nauraient pas t des colonnes dans les
tables des sous-classes.
Classe abstraite et entity bean
Une classe abstraite peut tre un entity bean
(avec @entity)
Elle ne peut pas tre instancie, ses sous-
classes concrtes oui,
Elle aura une table ddie,
Elle pourra faire lobjet de requtes
(polymorphisme) : trs intressant !
Polymorphisme ! Exemple avec un SessionBean
Polymorphisme (suite)
Des requtes polymorphes ! Si ! Si !

Polymorphisme : code client
Polymorphisme : oui, a marche !
Cest bien la mthode toString() de chaque
sous-classe qui est appele !
La requte rcupr tous les RoadVehicle (s)

EJB QL : Quelques exemples
Voir le fichier PDF fourni avec les TPs !
EJB QL : Quelques exemples (suite)
Liste toutes les commandes qui ne
comprennent pas (LEFT) de produit dont le
prix est suprieur une certaine quantit

Table des compagnies

Table des employs

Cette requte rcupre trois compagnies :

Mais celle-ci uniquement deux :

Celle-l : que la troisime

Provoque le chargement des entities relies

Prend le devant sur @FetchType.LAZY
Autre exemple :

WHERE et requtes paramtres

Autre exemple avec paramtres nomms

Expressions

Le % dans le LIKE = suite de caractres, le _ =
un caractre

MEMBER OF

Sous-Requtes

Fonctions sur chanes, arithmtique

Fonctions sur chanes, arithmtique (suite)

Nouveaut apparue avec EJB 2.0,
Messaging = moyen de communication lger,
compar RMI-IIOP,
Pratique dans de nombreux cas,
Message-Driven beans = beans accessibles
par messaging asynchrone.
Message-Driven Beans : motivation
Performance
Un client RMI-IIOP attend pendant que le serveur
effectue le traitement d'une requte,
Fiabilit
Lorsqu'un client RMI-IIOP parle avec un serveur, ce
dernier doit tre en train de fonctionner. S'il crashe,
ou si le rseau crashe, le client est coinc.
Pas de broadcasting !
RMI-IIOP limite les liaisons 1 client vers 1 serveur
Messaging
C'est comme le mail ! Ou comme si on avait
une troisime personne entre le client et le
serveur !
Messaging
A cause de ce "troisime homme" les performances ne
sont pas toujours au rendez-vous !
Message Oriented Middleware (MOM) est le nom
donn aux middlewares qui supportent le messaging.
Tibco Rendezvous, IBM MQSeries, BEA Tuxedo/Q, Microsoft
MSMQ, Talarian SmartSockets, Progress SonicMQ, Fiorano
FioranoMQ,
Ces produits fournissent : messages avec garantie de
livraison, tolrance aux fautes, load-balancing des
destinations, etc
The Java Message Service (JMS)
Les serveurs MOM sont pour la plupart
propritaires : pas de portabilit des
applications !
JMS = un standard pour normaliser les
changes entre composant et serveur MOM,
Une API pour le dveloppeur,
Un Service Provider Interface (SPI), pour rendre
connecter l'API et les serveurs MOM, via les drivers
JMS
JMS : Messaging Domains
Avant de faire du mesaging, il
faut choisir un domaine
Domaine = type de messaging
Domaines possibles
Publish/Subscribe (pub/sub) : n
producteurs, n consommateurs
(tv)
Point To Point (PTP) : n
producteurs, 1 consommateur
JMS : les tapes
1. Localiser le driver JMS
lookup JNDI. Le driver est une connection factory
2. Crer une connection JMS
obtenir une connection partir de la connection factory
3. Crer une session JMS
Il s'agit d'un objet qui va servir recevoir et envoyer des messages.
On l'obtient partir de la connection.
4. Localiser la destination JMS
Il s'agit du canal, de la chane tl ! Normalement, c'est rgl par le
dployeur. On obtient la destination via JNDI.
5. Crer un producteur ou un consommateur JMS
Utiliss pour crire ou lire un message. On les obtient partir de la
destination ou de la session.
6. Envoyer ou recevoir un message

JMS : les tapes

JMS : les interfaces

JMS : exemple de code (1)

JMS : exemple de code (2)

Note : Dans 3) false = pas de
transactions, AUTO_AKNOWLEDGE = inutile
ici puisquon envoie des messages.
Intgrer JMS et les EJB
Pourquoi crer un nouveau type d'EJB ?
Pourquoi ne pas avoir dlgu le travail un
objet spcialis ?
Pourquoi ne pas avoir augment les
caractristiques des session beans ?
Parce que ainsi on peut bnficier de tous les
avantages dj rencontrs : cycle de vie,
pooling, descripteurs spcialiss, code
simple
Qu'est-ce qu'un Message-Driven Bean ?
Un EJB qui peut recevoir des messages
Il consomme des messages depuis les queues ou
topics, envoys par les clients JMS
Un client n'accde pas un MDB via une interface, il
utilise l'API JMS,
Un MDB n'a pas d'interface Home, Local Home,
Remote ou Local,
Les MDB possdent une seule mthode, faiblement
type : onMessage()
Elle accepte un message JMS (BytesMessage,
ObjectMessage, TextMessage, StreamMessage ou
MapMessage)
Pas de vrification de types la compilation.
Utiliser instanceof au run-time pour connatre le type du
message.
Les MDB n'ont pas de valeur de retour
Ils sont dcoupls des producteurs de messages.

Pour envoyer une rponse l'expditeur : plusieurs
design patterns
Les MDB ne renvoient pas d'exceptions au client (mais
au container),
Les MDB sont stateless
Les MDB peuvent tre des abonns durables ou non-
durables (durable or nondurable subscribers) un
topic
Durable = reoit tous les messages, mme si l'abonn est
inactif,
Dans ce cas, le message est rendu persistant et sera dlivr
lorsque l'abonn sera de nouveau actif.
Nondurable = messages perdus lorsque abonn inactif.
Le consommateur (celui qui peut les dtruire)
des messages est en gnral le Container
C'est lui qui choisit d'tre durable ou non-durable,
S'il est durable, les messages rsistent au crash du
serveur d'application.
Dvelopper un Message-Driven Bean
Les MDBs doivent implmenter
public interface javax.jms.MessageListener {
public void onMessage(Message message);
}
public interface javax.ejb.MessageDrivenBean
extends EnterpriseBean {

public void ejbRemove()
throws EJBException;

public void setMessageDrivenContext(MessageDrivenContext ctx)
throws EJBException;
}
La classe d'implmentation doit fournir une mthode
ejbCreate() qui renvoit void et qui n'a pas
d'arguments.

Mthodes qui doivent tre implmentes
onMessage(Message)
Invoque chaque consommation de message
Un message par instance de MBD, pooling
assur par le container
setMessageDrivenContext(MessageDrivenC
ontext)
Appele avant ejbCreate, sert rcuprer le
contexte.
Ne contient que des mthodes lies aux
transactions

Un exemple simple
Un MDB qui fait du logging, c'est dire affiche
des messages de textes l'cran chaque fois
qu'il consomme un message.
Utile pour dbugger.
Rappel : pas d'interfaces !
La classe du bean
La classe du bean (suite)

Question ?
Comment sait-on quelle queue ou quel topic de
messages le bean consomme ?
Cela n'apparat pas dans le descripteur !
C'est fait exprs pour rendre les MDB
portables et rutilisables.
L'information se trouve dans
l@ActivationConfigProperty au dbut du code
Exemple de descripteur spcifique, tir
d'un autre exemple (Borland)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Borland Software Corporation//DTD Enterprise JavaBeans 2.0//EN"
"http://www.borland.com/devsupport/appserver/dtds/ejb-jar_2_0-borland.dtd">
<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>HelloEJBQueue</ejb-name>
<message-driven-destination-name>serial://jms/q</message-driven-destination-name>
<connection-factory-name>serial://jms/xaqcf</connection-factory-name>
<pool>
<max-size>20</max-size>
<init-size>2</init-size>
</pool>
</message-driven>
<message-driven>
<ejb-name>HelloEJBTopic</ejb-name>
<message-driven-destination-name>serial://jms/t</message-driven-destination-name>
<connection-factory-name>serial://jms/tcf</connection-factory-name>
<pool>
<max-size>20</max-size>
<init-size>2</init-size>
</pool>
</message-driven>
</enterprise-beans>
</ejb-jar>

Le client (1)
import javax.naming.*;

import javax.jms.*;
import java.util.*;

public class Client {
public static void main (String[] args) throws Exception {
// Initialize JNDI
Context ctx = new InitialContext(System.getProperties());

// 1: Lookup ConnectionFactory via JNDI
TopicConnectionFactory factory =
(TopicConnectionFactory)
ctx.lookup("javax.jms.TopicConnectionFactory");

// 2: Use ConnectionFactory to create JMS connection
TopicConnection connection =
factory.createTopicConnection();

Le client (2)

// 3: Use Connection to create session
TopicSession session = connection.createTopicSession(
false, Session.AUTO_ACKNOWLEDGE);

// 4: Lookup Destination (topic) via JNDI
Topic topic = (Topic) ctx.lookup("testtopic");

// 5: Create a Message Producer
TopicPublisher publisher = session.createPublisher(topic);

// 6: Create a text message, and publish it
TextMessage msg = session.createTextMessage();
msg.setText("This is a test message.");
publisher.publish(msg);
}
}

Concepts avancs
Transactions et MBD,
La production et la consommation du message sont dans deux
transactions spares
Scurit,
Les MDB ne reoivent pas les informations de scurit du
producteur avec le message. On ne peut pas effectuer les
oprations classiques de scurit sur les EJB.
Load-Balancing,
Modle idal : les messages sont dans une queue et ce sont
les MDB qui consomment, d'o qu'ils proviennent.
Comparer avec les appels RMI-IIOP pour les session et entity
beans, ou on ne peut que faire des statistiques
Concepts avancs
Consommation duplique dans les
architectures en clusters : utiliser une queue au
lieu d'un topic si on veut que le message ne
soit consomm qu'une fois !
Chaque container est un consommateur !

Concepts avancs

Piges !
Ordre des messages
Le serveur JMS ne garantit pas l'ordre de livraison
des messages.
L'appel ejbRemove() n'est pas garanti,
comme pour les session beans stateless
A cause du pooling,
En cas de crash.
Messages empoisonns (poison messages)
A cause des transactions un message peut ne
jamais tre consomm

Piges !
Messages empoisonns (poison messages)
A cause des transactions un message peut ne
jamais tre consomm

MDB empoisonn !
package examples;

import javax.ejb.*;
import javax.jms.*;

public class PoisonBean
implements MessageDrivenBean, MessageListener {

private MessageDrivenContext ctx;

public void setMessageDrivenContext(MessageDrivenContext ctx) {
this.ctx = ctx;
}
public void ejbCreate() {}
public void ejbRemove() {}
...
MDB empoisonn !
...
public void onMessage(Message msg) {
try {
System.out.println("Received msg " + msg.getJMSMessageID());
// Let's sleep a little bit so that we don't see rapid fire re-sends of the message.
Thread.sleep(3000);

// We could either throw a system exception here or
// manually force a rollback of the transaction.
ctx.setRollbackOnly();
}
catch (Exception e) {
e.printStackTrace();
}
}
}

MDB empoisonn !
Solutions
Ne pas lever d'exception,
Utiliser des transactions gres par le bean, non par
le container,
Certains serveurs peuvent configurer une "poison
message queue" ou possder un paramtre "nb
max retries"

Comment renvoyer des rsultats
l'expditeur du message ?
A faire la main ! Rien n'est prvu !
Nanmoins, des problmes se posent si le
client est lui-mme un EJB de type stateful
session bean
Que se passe-t-il en cas de passivation ?
Perte de la connexion la destination temporaire!
Solution : ne pas utiliser d'EJB SSB comme
client! Utiliser une Servlet ou un JSP
Autre solution : configurer un topic permanent
pour les rponses, au niveau du serveur JMS.

D'autres solutions existent
JMS propose deux classes
javax.jms.QueueRequestor et
javax.jms.TopicRequestor qui
implmentent une pattern simple
question/rponse
Solution bloquante, pas de gestion de
transactions
Le futur : invocation de mthode asynchrone
Gestion des transactions
Gestion de transactions
Service cl pour le dveloppement ct serveur,
Permet des applications de fonctionner de manire
robuste,
Les transactions sont trs utiles lorsqu'on effectue des
oprations de persistance, comme des mises--jours
dans une base de donnes
Dans ce chapitre nous prsentons le concept de
transaction et sa mise en application au sein des EJB.

Motivation pour les transactions
Oprations atomiques, bien que composes de
plusieurs petites oprations
Ex : transfert de compte compte bancaire : on
enlve sur un compte, on dpose sur l'autre
Si une des deux oprations choue, perte de
cohrence !
On veut que soit les deux oprations russissent,
mais si une d'elles choue, on annule le tout et on
remet les comptes dans l'tat initial !
On dit que les deux oprations forment une seule et
mme transaction !

Traitement par exceptions
On peut s'en sortir en grant des exceptions
try {
// retirer de l'argent du compte 1
} catch (Exception e){
// Si une erreur est apparue, on arrte.
return;
}
try {
// Sinon, on dpose l'argent sur le compte 2
} catch (Exception e){
// Si une erreur est apparue, o s'arrte, mais avant, on redpose
//l'argent sur le compte 1
return;
}
Qu'en pensez-vous ?
Traitement par exceptions
Et si on choue la dernire opration et qu'on
arrive pas remettre l'argent sur le compte 1 ?
Et si au lieu d'un traitement simple on a un
gros traitement faire qui se compose de 20
oprations diffrentes ?
Comment on teste tous les cas d'erreur ?
Panne rseau ou panne machine

Panne rseau ou panne machine
Le rseau plante, le client reoit une RMI
Remote Exception
L'erreur est intervenue avant qu'on enlve
l'argent, ou aprs ?
Impossible de savoir
Peut-tre que le SGBD s'est crash ? La
machine ? La BD est peut-tre devenue
inconsistante ?
Le traitement par Exception est vraiment
inacceptable ici, il n'est pas suffisant !

Partage concurrent de donnes

Partage concurrent de donnes
Plusieurs clients consultent et modifient les
mmes donnes
On ne peut tolrer de perte d'intgrit des
donnes !
Problmes rsolus par les transactions !
Un transaction est une srie d'oprations qui
apparaissent sous la forme d'une large
opration atomique.
Soit la transaction russit, soit elle choue.
Traduire par "toutes les oprations qui la
composent"
Les transactions s'accordent avec les pannes
machines ou rseau,
Rpondent au problmes du partage de
donnes.
Un peu de vocabulaire
Objet ou composant transactionel
Un composant bancaire impliqu dans une transaction. Un
EJB compte bancaire, un composant .NET, CORBA
Gestionnaire de transaction
Celui qui en coulisse gre l'tat de la transaction
Ressource
L'endroit o on lit et crit les donnes : un DB, une queue de
messages, autre
Gestionnaire de ressource
Driver d'accs une BD, une queue de message
Implmentent l'interface X/Open XA, standard de facto pour la
gestion de transactions
Les proprit ACID
Atomicit
Nombreux acteurs : servlet, corba, rmi-iiop, ejbs, DB Tous
votent pour indiquer si la transaction s'est bien passe
Consistance
Le systme demeure consistent aprs l'excution d'une
transaction (comptes bancaires ok!)
Isolation
Empche les transactions concurrentes de voir des rsultats
partiels. Chaque transaction est isole des autres.
Implment par des protocoles de synchronisation bas-niveau
sur les BDs
Durabilit
Garantit que les mises jour sur une BD peuvent survivre un
crash (BD, machine, rseau)
En gnral, on utilise un fichier de log qui permet de faire des
undos pour revenir dans l'tat avant le crash.
Modles de transactions
Il existe deux modles
1. Flat transactions ou transactions plat
Supportes par les EJBs
2. Nested transactions ou transactions
imbriques
Non supportes par les EJBs pour le moment
Flat transactions
Modle le plus simple.
Aprs qu'une transaction ait dmarr, on effectue des
oprations
Si toutes les oprations sont ok, la transaction est
commite (commited), sinon elle choue (aborted)
En cas de commit, les oprations sont valides
(permanent changes)
En cas d'abort, les oprations sont annules (rolled
back). L'application est galement prvenue
Flat transactions

Comment s'effectue le rollback ?
Tant qu'il n'y a pas de commit, les
modifications une BD ne sont pas
permanentes
Dans un contexte de composants, tout est fait
en coulisse. Vous n'avez pas vous
proccuper de l'tat de votre bean Il sera
restaur en cas de rollback.
Transactions imbriques
Cas d'cole : on veut faire un tour du monde
1. Notre application achte un billet de train de Nice
Marseille,
2. Puis un billet d'avion de Marseille Londres,
3. Puis un billet d'avion de Londres New-York,
4. L'application s'aperoit qu'il n'y a plus de billet
d'avion disponible ce jour-l pour New-York
Tout choue et on annule toutes les
rservations !
Avec un modle de transactions imbrique,
une transaction peut inclure une autre
transaction,
Si on ne trouve pas de vol pour New-York, on
essaiera peut-tre de prendre une
correspondance par Philadelphie

Gestion des transactions avec les EJBs
Seul le modle flat est support.
Le code que le dveloppeur crit, s'il dcide
de grer les transactions par programmation,
demeurera d'un trs haut niveau,
Simple vote pour un commit ou un abort,
Le container fait tout le travail en coulisse
3 manires de grer les transactions
1. Par programmation,
2. De manire dclarative,
3. De manire initie par le client.

Gestion des transactions par
programmation
Responsable : le
dveloppeur de
bean
Il dcide dans
son code du
begin, du
commit et du
abort
Ex: le banquier
Gestion des transactions dclarative
Le bean est automatiquement enrl (enrolled)
dans une transaction
Le container fait le travail
Gestion des transactions dclarative
Gnial pour le dveloppeur!
Transactions inities par le client

Que choisir ?
Par programmation : contrle trs fin
possible
Dclaratif : super, mais granularit importante,
Contrl par le client
N'empche pas de grer les transactions dans le
bean (par programmation ou de manire
dclarative)
Ajoute une couche de scurisation en plus, qui
permet de dtecter les crashes machine, rseau,
etc
Transactions et entity beans
Dans une transaction, on accde un entity
bean :
un moment donn : chargement des donnes
de la DB dans le bean,
Un verrou (lock) est acquis sur la DB, assurant la
consistance,
Juste aprs l'appel du commit de la transaction, les
donnes sont sauvegardes, la DB est mise
jour et libre le verrou.
On a donc le code daccs la BD, le code des
mthodes mtiers et l'appel la sauvegarde dans
la BD qui se trouvent dans la transaction.
Si on contrlait la transaction dans le bean
Dmarrer la transaction avant laccs la BD,
Faire le commit la fin, aprs la sauvegarde,
Problme : on a pas le contrle sur ce code
Bean-Managed transactions illgales pour les
entity beans. Seules les transactions gres
par le container sont autorises !

Consquence : un entity bean n'accde pas
la BD chaque appel de mthode, mais
chaque transaction.
Si un entity s'excute trop lentement, il se peut
qu'une transaction intervient pour chaque
appel de mthode, impliquant des accs BD.
Solution : inclure plusieurs appels de mthodes
de l'entity dans une mme transaction.
Se fait en prcisant les attributs de transaction
du bean.
Transactions et Message-Driven Beans
Bean-Managed Transactions
La transaction commence et se termine aprs que le message
a t reu par le MDB.
On indique dans le descripteur de dploiement les
aknowledgement modes pour indiquer au container comment
accuser rception
Container-Managed Transactions
La rception du message s'inscrit dans la mme transaction
que les appels de mthodes mtier du MDB. En cas de
problme, la transaction fait un rollback. Le container envoi
accus de rception (message acknowledgement)
Pas de transaction
Le container accusera rception aprs rception. Quand
exactement, ce n'est pas prcis
Transactions et Message-Driven Beans
Que choisir ?
Si on dcide de ne pas laisser le container grer les
transactions, on a pas de moyen de conserver le
message dans la queue de destination si un problme
arrive.
On choisit Container-Managed Transaction
Pige : si un MDB est expditeur et consommateur du
message, le tout intervient dans une mme transaction
Impossible de terminer ! Le message expdi n'est pas mis
dans la queue de destination de manire dfinitive tant que
l'envoi n'est pas commit.
Donc le message ne peut tre consomm! Cqfd.
Solution : appeler commit() sur l'objet JMS session juste
aprs l'envoi.
Attributs de transactions gres par le
container
Pour chaque bean, on prcise des attributs de
transaction
On peut spcifier des attributs pour le bean entier
ou mthode par mthode,
On peut prciser les deux Le plus restrictif gagne.
Chaque mthode mtier doit tre traite
(globalement ou individuellement)
Par dfaut : attribut = REQUIRED
Gnial pour le dveloppeur!
Valeur des attributs de transaction
Required
Le bean est toujours dans une transaction.
Si une transaction pour ce bean existe, alors le
bean la rejoint (join), sinon, le container cre une
nouvelle transaction.
La plupart du temps propos comme valeur
par dfaut par les IDEs et leurs
Wizards/diteurs de descripteurs
Attribut de transaction : Required
Exemple : passage d'une commande
Un session bean utilise deux entity beans : un bean carte de
crdit et bean commande,
Lors d'un passage de commande, on envoie la commande,
puis on dbite la carte de crdit,
Si le bean session a comme attribut de transaction Required,
une transaction est cre ds que le passage de commande
dmarre,
Lors de l'appel au bean Commande, si celui-ci est galement
en mode Required, il rejoindra la transaction en cours. Idem
lors de l'appel au bean Carte de Crdit,
Si un problme se pose, la carte de crdit ne sera pas dbite
et la commande ne sera pas passe.

Attribut de transaction : RequiresNew
RequiresNew
Le bean est toujours dans une nouvelle transaction.
Si une transaction existe, elle est suspendue,
Lorsque la nouvelle transaction se termine (abort ou
commit), l'ancienne transaction est rsume.
Utile si on veut respecter les proprits ACID
dans l'unit du bean, sans qu'une logique
externe intervienne.

Attribut de transaction : Supports
Supports
Semblable Required sauf que si une transaction
n'existe pas, elle n'est pas cre.
Si l'excution du bean intervient dans une
transaction existante, il la rejoint nanmoins.
A viter pour les applications mission-critical !
Dans ce cas, choisir Required.
Attribut de transaction : Mandatory
Mandatory
Une transaction doit exister lorsque le bean est
excut.
Si ce n'est pas le cas,
javax.ejb.TransactionRequiredException
est leve et renvoye au client.
Si le client est local, c'est
javax.ejb.TransactionRequiredLocalException qui
est leve
Attribut sr, qui oblige le client inscrire sa
logique dans une transaction avant d'appeler le
bean.
Attribut de transaction : NotSupported
NotSupported
Le Bean ne supporte pas les transactions,
Si une transaction existe lors de l'appel du bean, la
transaction est suspendue, le bean s'excute, puis
la transaction est rsume.
Utiliser cet attribut lorsque les proprits ACID
ne sont pas importantes
Exemple : un bean qui fait des statistiques toutes
les dix minutes en parcourant une BD. On tolre
que les donnes lues ne sont peut-tre pas jour
Gain en performance vident.
Attribut de transaction : Never
Never
Le Bean ne supporte pas les transactions,
Une exception javax.rmi.RemoteException ou
javax.ejb.EJBException est envoye au client
si une transaction existe au moment de l'appel du
bean.
A utiliser lors du dveloppement d'une logique
non transactionnelle.
Rsum sur les attributs de transaction
Soit T1 une transaction initie par le client, T2
la nouvelle transaction initie par le bean
appel.
Dbut et fin d'une transaction

Tous les attributs ne s'appliquent pas
tous les beans

Transactions gres par programmation
Plus complexes manipuler, mais plus
puissantes,
Le dveloppeur doit utiliser Java Transaction
API (JTA)
CORBA Object Transaction Service (OTS)
Dans une transaction de nombreux partis sont
impliqus : le driver de DB, le bean, le
container,
Premier effort pour assurer les transactions
dans un systme distribu : le service CORBA
Object Transaction Service (OTS)
OTS = ensemble d'interfaces pour le
gestionnaire de transactions, le gestionnaire de
ressources, etc
Mortel utiliser !
Java Transaction Service (JTS)
Sun Microsystems a encapsul OTS en deux
API distinctes
JTS s'adresse aux vendeurs d'outils capables
d'assurer un service de transaction, elle couvre tous
les aspects complexes d'OTS,
JTA s'adresse au dveloppeur d'application (vous)
et simplifie grandement la gestion de transactions
en contexte distribu.
Java Transaction API (JTA)
JTA permet au programmeur de contrler la
gestion de transaction dans une logique
mtier.
Il pourra faire les begin, commit, rollback, etc
Il peut utiliser JTA dans des EJB mais aussi
dans n'importe quelle application cliente.
JTA se compose de deux interfaces distinctes.
JTA : deux interfaces
Une pour les gestionnaires de ressources
X/Open XA (hors sujet pour nous)
Une pour le programmeur dsirant contrler
les transactions :

javax.transaction.UserTransaction

L'interface javax.transaction.UserTransaction
public interface
javax.transaction.UserTransaction {
public void begin();
public void commit();
public int getStatus();
public void rollback();
public void setRollbackOnly();
public void setTransactionTimeout(int);
}

L'interface javax.transaction.UserTransaction
Constantes de la classe
javax.transaction.Status
Constantes renvoyes par getStatus()
public interface javax.transaction.Status {
public static final int STATUS_ACTIVE;
public static final int STATUS_NO_TRANSACTION;
public static final int STATUS_MARKED_ROLLBACK;
public static final int STATUS_PREPARING;
public static final int STATUS_PREPARED;
public static final int STATUS_COMMITTING;
public static final int STATUS_COMMITTED;
public static final int STATUS_ROLLING_BACK;
public static final int STATUS_ROLLEDBACK;
public static final int STATUS_UNKNOWN;
}

Constantes de la classe
javax.transaction.Status
Exemple de transaction gre par
programmation

Exemple de transaction gre par
programmation (suite)

Transactions inities par le client
C'est la dernire des mthodes prsentes au
dbut de ce chapitre
Il est ncessaire d'obtenir une rfrence sur un
objet UserTransaction, fourni par JTA
Via JNDI !
Faire attention ce que chaque transaction ne
dure pas longtemps !!!
Pige classique !
Transactions inities par le client (servlet
par ex)
try {
/* 1: Set environment up. You must set the JNDI Initial Context factory, the
Provider URL, and any login names or passwords necessary to access JNDI.
See your application server product's documentation for details on their
particular JNDI settings. */
java.util.Properties env = ...
/* 2: Get the JNDI initial context */
Context ctx = new InitialContext(env);
/* 3: Look up the JTA UserTransaction interface via JNDI. The container is
required to make the JTA available at the location java:comp/UserTransaction. */
userTran =
(javax.transaction.UserTransaction)ctx.lookup("java:comp/UserTransaction");
/* 4: Execute the transaction */
userTran.begin();
// perform business operations
userTran.commit();
} catch (Exception e) {
// deal with any exceptions, including ones
// indicating an abort.
}

Isolation de transaction
Le "I" de ACID !
L'isolation cote cher en termes de
performances,
Ncessit de pouvoir rgler le niveau
d'isolation entre transactions concurrentes !
Un exemple : deux instances A et B d'un
mme composant accdent une mme
donne X dans une BD.
Chacune
1. Lit la valeur de X,
2. Ajoute 10 la valeur lue,
3. crit la nouvelle valeur dans la BD
Si chaque instance effectue ces oprations
de manire atomique, pas de problmes !
Ceci n'est pas garanti selon le niveau
d'isolation choisi.
Par exemple, si on ne prend pas de
prcaution
1. A lit X, dans la BD on a X=0,
2. B lit X, dans la BD on a X=0,
3. A ajoute 10 X et crit le rsultat dans la BD.
Dans la BD on a X=10,
4. B ajoute 10 sa copie de X et crit le rsultat dans
la BD. Dans la BD on a X=10, ce qui est anormal !
On a perdu le traitement effectu par A !
Solution : utiliser un verrou.
Chaque composant
1. Demande un verrou,
2. Fait le travail prcdent sur X,
3. Libre le verrou
Gestion de file d'attente exclusion mutuelle,
etc
Tout ceci peut-tre rgl avec les EJBs
Niveau d'isolation avec les EJB
Le niveau d'isolation limite la faon dont les
transactions multiples et entrelaces
interfrent les unes sur les autres dans une
BD multi-utilisateur.
3 types de violations possibles
1. Lecture brouille,
2. Lecture ne pouvant tre rpte,
3. Lecture fantme.
Lecture brouille
La transaction T1 modifie une ligne, la transaction T2 lit
ensuite cette ligne,
Puis T1 effectue une annulation (rollback),
T2 a donc vu une ligne qui n'a jamais vraiment exist.
Lecture ne pouvant tre rpte
T1 extrait une ligne,
T2 met jour cette ligne,
T1 extrait nouveau la mme ligne,
T1 a extrait deux fois la mme ligne et a vu deux valeurs
diffrentes.
Lecture fantme
T1 lit quelques lignes satisfaisant certaines
conditions de recherche,
T2 insre plusieurs lignes satisfaisant ces mmes
conditions de recherche,
Si T1 rpte la lecture elle verra des lignes qui
n'existaient pas auparavant. Ces lignes sont
appeles des lignes fantmes.

Attribut Syntaxe Description
Uncommited TRANSACTION_READ_UNCOMMITED Autorise l'ensemble des
trois violations
Commited TRANSACTION_READ_COMMITED

Autorise les lectures ne
pouvant tre rptes et
les lignes fantmes,
n'autorise pas les
lectures brouilles
Repeatable TRANSACTION_REPEATABLE_READ Autorise les lignes
fantmes mais pas les
deux autres violations
Serialisable TRANSACTION_SERIALIZABLE N'autorise aucune des
trois violations
Quel niveau utiliser
Uncommited
Uniquement si on est sr qu'une transaction ne pourra tre
mise en concurrence avec une autre.
Performant mais dangereux !
A viter pour les applications mission-critical !
Commited
Utile pour les applications qui produisent des rapports sur une
base de donne. On veut lire des donnes consistances,
mmes si pendant qu'on les lisait quelqu'un tait en train de
les modifier.
Lisent un snapshot des donnes commites
Niveau d'isolation par dfaut de la plupart des BD (Oracle)
Quel niveau utiliser
Repeatable
Lorsqu'on veut pouvoir lire et modifier des lignes,
les relire au cours d'une mme transaction, sans
perte de consistance.
Serialisable
Pour les applications mission-critical qui ncessitent
un niveau d'isolation absolu, ACID 100% !
Attention ,les performances se dgradent vitesse
grand V avec ce mode !

Comment spcifier ces niveaux ?
Transactions gres par le bean
Appel de
java.sql.Connection.SetTransactionIsolation(...).
Transactions gres par le container
Non, on ne peut pas spcifier le niveau d'isolation dans
le descripteur !
On le fera via le driver JDBC, ou via les outils de
configuration de la DB ou du container,
Problmes de portabilit !

Impossibilit de spcifier le niveau
d'isolation ???

Deux stratgies
Lorsqu'on veut grer les transactions, on doit
toujours choisir entre deux stratgies
1. Stratgie pessimiste
Tout peut foirer, on prend donc un verrou lors des
accs BD, on fait notre travail, puis on libre le
verrou.
2. Stratgie optimiste
Peu de chance que a foire, espre que tout va
bien se passe.
Nanmoins, si la BD dtecte une collision, on fait
un rollback de la transaction.
Que faire dans le code EJB ???
Ok, nous avons vu comment spcifier le type de
gestion de transaction, gre par le bean ou le
container,
Nous avons vu les niveaux d'isolations, que l'on
spcifie la plupart du temps via les pilotes JDBC,
Mais que faire en cas de rollback par exemple
On ne peut pas re-essayer indfiniment d'excuter une
transaction, on peut envoyer une Exception au client
On veut galement tre tenu au courant de ce qu'il se passe
pendant l'excution d'une transaction.
En cas de rollback, si on envoie une Exception
au client, que faire de l'tat du bean ?
Si le bean est stateful, on risque d'avoir un tat
incorrect (celui qui a provoqu l'chec de la
transaction),
Lors du design d'un bean, il faut prvoir la
possibilit de restaurer un tat correct,
Le container ne peut le faire pour vous car le
traitement est en gnral spcifique l'application,
Il peut nanmoins vous aider raliser cette tche.
L'EJB peut implementer une interface optionnelle
javax.ejb.SessionSynchronization

public interface javax.ejb.SessionSynchronization {
public void afterBegin();
public void beforeCompletion();
public void afterCompletion(boolean);
}
Uniquement pour les session beans stateful

Le container appelle afterCompletion() que la
transaction se soit termine par un commit ou par un
abort
Le paramtre de la mthode nous signale dans quel cas on se
trouve

public class CountBean implements SessionBean, SessionSynchronization {
public int val;
public int oldVal;

public void ejbCreate(int val) {
this.val=val;
this.oldVal=val;
}

public void afterBegin() { oldVal = val;}
public void beforeCompletion() {}
public void afterCompletion(boolean b) { if (b == false) val = oldVal; }

public int count() { return ++val; }
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext ctx) {}
}

Cours Complet2012

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Complet2012

Transféré par

Droits d'auteur :

Formats disponibles

Enterprise JavaBeans 3.

Vous aimerez peut-être aussi