Les composants EJB et ses différentes API

1. heithem.abbes@gmail.com
Les Entreprise Java Beans
(EJB)

2. Introduction JEE
 Java
 JSE : Java Standard Edition (PCs)
 JME: Java Micro Edition (mobiles)
 JEE: Java Entreprise Edition (serveurs)
 Objectifs de JEE
 Faciliter le développement de nouvelles applications à
base de composants
 Intégration avec les systèmes d’information existants
 Support pour les applications « critiques » de
l’entreprise
 Disponibilité, tolérance aux pannes, montée en charge,
sécurité ...
2

3. Java EE – C’est quoi?
 Anciennement, J2EE (Java2 Enterprise
Edition)
 Norme proposée par SUN visant à définir un
standard de développement d’applications
d’entreprises multi-niveaux, basées sur des
composants.
http://www.oracle.com/technetwork/java/javaee/overview/index.html
3

4. Serveurs d’applications JEE
 Offre commerciale
 BEA WebLogic (haut de
gamme)
 IBM Websphere (no 1)
 Sun Java System App
Server
 Borland Enterprise Server
 Oracle Application Server
 Macromedia jRun
 SAP Web application
server
 Iona Orbix E2A
 …
 Offre open source
 JBoss (no 1 en nombre
de déploiements)
 OW2 JOnAS
 Sun Glassfish (Platform
edition de l’offre Sun Java
System App Server)
 Apache Geronimo (
Community edition de
IBM Websphere)
 openEjb
 …
4

5. Java EE - Architecture
5
 Client
 Léger (Web, browser) et Lourd (Application java, Applet…)
 Serveur d ’applications
 Conteneur EJB + conteneur web + logique métier
 Services non fonctionnels (services JEE)
 EIS (Entreprise Information System) ou Base de données

6. Services JEE
 JDBC (Java DataBase Connectivity) est une API
d'accès aux bases de données relationnelles
 JNDI (Java Naming and Directory Interface) est une
API d'accès aux services de nommage et aux
annuaires d'entreprises tels que DNS, NIS, LDAP
 JTA/JTS (Java Transaction API/Java Transaction
Services) est une API définissant des interfaces
standard avec un gestionnaire de transactions.
 JPA (Java Persistance API) est une API pour la
correspondance modèle objet-modèle relationnel
(ORM, Object-Relational Mapping).
 JCA (JEE Connector Architecture) est une API de
connexion au système d'information de l'entreprise,
tels que les ERP
6

7. Services JEE
 JMX (Java Management Extension) fournit des
extensions permettant de développer des applications
web de supervision d'applications
 JAAS (Java Authentication and Authorization Service)
est une API de gestion de l'authentification et des droits
d'accès.
 JavaMail est une API permettant l'envoi de courrier
électronique.
 JMS (Java Message Service) fournit des fonctionnalités
de communication asynchrone (appelées MOM pour
Middleware Object Message) entre applications.
 RMI-IIOP est une API permettant la communication
entre objets distants
7

8. Composants EJB
 « A server-side component that encapsulates
the business logic of an application »
 On se focalise sur la logique applicative et métier
 Le développeur ne prend en compte que la
logique métier de l'EJB.
 Les services systèmes sont fournis par le conteneur
 Persistance
 Transactions
 Sécurité (authentification, confidentialité, etc.)
 Réserve (pool) d’objets, équilibrage de charge
 Vocabulaire : Bean = EJB = composant
 Plusieurs versions : EJB 3.2 (JEE 7)
11

9. Composants EJB
 EJB ne fournit pas de GUI
 GUI (Graphical User Interface)= côté client
 Applications classiques
 Java Beans
 Servlets, JSP
12
 Conteneur EJB
 environnement au sein du serveur dans lequel les
EJB vivent
 fournit les services nécessaires pour gérer les
EJBs
 On confond en général conteneur et serveur
d'application.

10. Schéma d’exécution des EJB
 Les conteneurs isolent les beans des clients et d’une
implémentation spécifique du serveur
13
 Les beans fournissent un
ensemble de services, en
réalisant les traitements
spécifiques à une application
(“business logic”).
 Les clients font appel à ces
services.
 Le conteneur intercepte les
appels aux beans qu’il contient
et réalise diverses fonctions
communes (persistance,
transactions, sécurité).

11. Accès aux composants EJB
 Chaque EJB fournit 1 interface
d'accès distant
 les services (méthodes) offerts à
ses clients
 Le client d'un EJB peut être :
servlet, applet, application classique,
autre EJB
14
 + éventuellement 1 interface d'accès
local
 les services offerts par le bean à ses
clients locaux
 les mêmes (ou d'autres) que ceux offerts
à distance

12. Types des EJB
 3 types de beans:
 Session Beans
 Représente un traitement (services fournis à un
client)
 Entity Beans
 Représente un objet métier qui existe dans le
système de stockage permanent (exp: compte
client)
 Message-Driven Bean
 Traite les messages asynchrones
15

13. Session Bean
 Modélise un traitement (ou session)
 Processus métier (business process): services fournis aux
clients
 Exemple: gestion de compte bancaire, affichage de catalogue de
produit, vérifieur de données bancaires…
 Durée de vie = la session
 Le temps qu'un client reste connecté sur le bean.
 Cycle de vie
 Le conteneur crée une instance lorsqu'un client se connecte sur
le session bean.
 Il peut la détruire lorsque le client se déconnecte.
 Les Session Beans ne résistent pas aux pannes du serveur
 Des objets en mémoire, non persistants
 Contrairement aux Entity Beans
16

14. Types de Session Beans
 Chaque session bean entretient une
conversation avec un client.
 Conversation = suites d'appels de méthodes.
 Il existe deux types de Session Beans
 Stateful Session Beans
 Stateless Session Beans
 Chacun modélisant un type particulier de
conversation
17

15. Stateless Session Beans
 Sans état : ne conserve pas d’information entre 2
appels successifs
 Certaines conversations peuvent se résumer à un appel
de méthode, sans besoin de connaître l'état courant du
Bean
 Le client passe toutes les données nécessaires au
traitement lors de l'appel de méthode.
 Un tel EJB est partageable consécutivement par de
multiples clients
 Exemples
 validation de numéro de compte bancaire, un convertisseur
de monnaies…
Une instance de Stateless Session Bean n'est pas
propre à un client donné, elle peut être partagée
18

16. Stateful Session Beans
 Certaines conversations se déroulent sous forme de
requêtes successives.
 D'une requête à l'autre, il faut un moyen de
conserver un état
 Exemple : un client surfe sur un site de e-commerce,
sélectionne des produits, remplit son caddy…
 Un Stateful Session Bean maintient l’état pendant la durée
de vie du client
 Au cours d'appels de méthodes successifs. Si un appel de méthode
change l'état du Bean, lors d'un autre appel de méthode l'état sera
disponible.
 Un tel EJB est propre à un client pendant toute la durée de la
Session
une instance de Stateful Session Bean par client
19

17. Session Bean - Développement
 1 interface (éventuellement 2 : Local + Remote) + 1
classe
 Interface
 annotations @javax.ejb.Local ou @javax.ejb.Remote
20

18. Session Bean - Développement
 Classe
 annotations @Stateless ou @Stateful
Possibilité de nommer les beans : @Stateless(name="foobar")
Par défaut, le nom de la classe
21

19. Session Bean - Développement
Client local
 Typiquement une servlet ou une JSP
 colocalisée sur le même serveur que le
bean
 Mécanisme « injection de
dépendance »
 annoté @EJB
 éventuellement @EJB(name="foobar")
22

20. Session Bean - Développement
Client distant
1. Recherche du bean dans l'annuaire JNDI
2. Récupération de la référence de l'annuaire JNDI
3. Appel des méthodes du bean
23

21. Entity Bean (EB)
 Représentation d'une donnée, manipulée par l'application,
typiquement stockée dans un SGBD
 l’état d’un Entity Bean est persistant.
 La Persistance signifie que l’état du Entity Bean existe
(persiste) même après la durée de l’exploitation de
l’application (session)
24
Session Bean Entity Bean
Gestion de compte Compte bancaire
Vérificateur de CB Carte de crédit
Système d'entrée gestion de commandes Commande, ligne de commande
Gestion de catalogue Produits
Gestionnaire d'enchères Enchère, Produit
Gestion d'achats Commande, Produit, ligne de commande

22. Entity Bean (EB)
 Correspondance objet – relationnel (mapping
Objet/Relationel)
 Les attributs d'un objet sont enregistrés sur un support
persistant
 Avantage
 manipulation d'objets Java plutôt que de requêtes SQL
 mis en œuvre
 annotations Java 5 (@)
 API JPA ( Java Persistence API) à partir de EJB 3.0
 frameworks de persistance (Hibernate, TopLink,
EclipseLink…)
 Intérêt de JPA: permet d’être indépendant du
framework gérant la persistance
25

23. Mapping objet/BD relationelle
26

24. Propriétés des Entity Beans
 Plusieurs clients peuvent utiliser des EB qui
« pointent » sur les mêmes données
 Une instance EB contient une copie des données
du système de stockage
 Quand plusieurs clients partagent un EB, ils
 reçoivent leurs propres instances d’EB
 partagent les données sous-jacentes
 n'ont pas à gérer la synchronisation sur les données

25. Persistance d’un Entity Bean
 Il existe deux types de persistance pour les Entity
Bean :
 Bean-Managed Persistence (BMP) : le code du
bean entité contient les appels qui accèdent à la
base de données
 Container-Managed Persistence (CMP) : le
conteneur EJB génère automatiquement les appels
d’accès à la base de données, en utilisant le
descripteur de déploiement de bean (fichier xml ou
annotations)
 Avantage : le redéploiement d’un même Entity Bean sur
différents serveurs JEE utilisant différentes bases de
données ne nécessitera aucune modification du bean.
 Dans les 2 cas le conteneur est responsable de la
28

26. Entity Bean - Développement
 annotation @Entity :
 déclare une classe correspondant à un Entity
Bean
 chaque classe de EB est mise en
correspondance avec une table
 par défaut table avec même nom que la classe
 sauf si annotation @Table(name="...")
 annotation @Id : définit une clé primaire
 annotation @Column : définit une colonne
29

27. Entity Bean - Développement
30

28. Entity Bean – Entity Manager
 Gestionnaire d'entités (Entity Manager)
 assure la correspondance entre les objets Java et
les tables relationnelles
 point d'entrée principal dans le service de
persistance
 permet d'ajouter des enregistrements
 permet d'exécuter des requêtes
 accessible via une injection de dépendance
 attribut de type javax.persistence.EntityManager
 annoté par @PersistenceContext ou
@PersistenceUnit
31

29. Entity Bean – Entity Manager
 Exemple
 création de trois enregistrements dans la table des
livres
de façon similaire em.remove(b2) retire l'enregistrement de la table
32

30. Entity Bean – Entity Manager
Recherche par clé primaire
 méthode find du gestionnaire d'entités
Book myBook = em.find(Book.class,12);
 retourne null si la clé n'existe pas dans la table
 IllegalArgumentException
 si 1er paramètre n'est pas une classe d'EB
 si 2ème paramètre ne correspond pas au type de la clé
primaire
33

31. Entity Bean – Entity Manager
Recherche par requête
 requêtes SELECT dans une syntaxe EJB-QL
 mot clé OBJECT pour désigner un résultat à retourner
sous la forme d'un objet
 paramètres nommés (préfixés par : ) pour configurer la
requête
• méthode getSingleResult() pour récupérer un résultat
unique
• NonUniqueResultException en cas de non unicité
34

32. Entity Bean – Entity Manager
Recherche par requête pré-compilée
 création d'une requête nommée attachée à l'EB
35

33. Message-Driven Bean
 Interaction par envoie de messages asynchrone
 MOM : Message-Oriented Middleware
 2 modes
 Point-to-Point
n vers 1 (Queue)
 Publish/Subscribe
n vers m ( Topic)
36

34. Messaging
37
Client/Serveur : communication synchrone
Producteur/Consommateur : communication asynchro

35. Caractéristiques des MDB
 consomme des messages asynchrones
 pas d'état ( stateless session bean)
 toutes les instances d'une même classe de MDB sont
équivalentes
 peut traiter les messages de clients différents
 Quand utiliser un MDB ?
 éviter appels bloquants
 découpler clients et serveurs (couplage faible)
 besoin de fiabilité : supporter une déconnexion temporaire avec
le serveur
 Vocabulaire : producteur/consommateur
38

36. MOM et JMS
 Message Oriented Middleware (MOM) :
middlewares qui supportent le messaging.
 fournissent : messages avec garantie de livraison,
tolérance aux fautes, etc…
 sont pour la plupart propriétaires : pas de portabilité des
applications !
 Exemples :Tibco Rendezvous, IBM MQSeries, BEA
Tuxedo/Q, Microsoft MSMQ, Talarian SmartSockets,
Progress SonicMQ, Fiorano FioranoMQ, …
 JMS = un standard pour normaliser les échanges entre
composant et serveur MOM,
 Une API pour le développeur,
 Un Service Provider Interface (SPI), pour connecter l'API et les
serveurs MOM, via les drivers JMS
39

37. Concepts des MDB
 MDB basé sur Java Messaging Service (JMS)
 ConnectionFactory : fabrique pour créer des connexions vers
une queue/topic
 Connection : une connexion vers une queue/topic
 Session : période de temps pour l'envoi de messages dans 1
queue/topic
 Interfaces JMS :
40

38. JMS : les étapes
1. Création d'une connexion
2. Création d'une session
3. Création d'un message
4. Envoi du message
5. Fermeture session
6. Fermeture connexion
41

39. MDB - Développement
Producteur
42

40. MDB - Développement
Consommateur
 MDB = classe
 annotée @MessageDriven
 implantant interface MessageListener
 méthode void onMessage(Message)
Queue" )
43

41.  Fournit les services
 de nommage (JNDI)
 de persistance (EntityManager)*
 de gestion du cycle de vie
 de transaction
 de sécurité
Services du conteneur EJB
* Voir partie EntityManager de Entity Bean + Persistance

42. JNDI (Java Naming and Directory Interface)
 JNDI est composée de :
 API standard utilisée pour
développer des applications
 SPI utilisée par les fournisseurs
d'une implémentation d'un pilote de
service de nommage
 Différents services de nommages
 systèmes de fichiers (File system),
les DNS, les annuaires LDAP
45
 Contexte :
 un ensemble d'associations nom/objet.
 utilisé lors de l'accès à un élément contenu dans le service de
nommage
javax.naming.InitialContext ctx = new
javax.naming.InitialContext();

43. JNDI (Java Naming and Directory
Interface)
46
 À partir du contexte, on appelle les opérations
 bind : associer un objet avec un nom
 rebind : modifier une association
 unbind : supprimer une association
 lookup : obtenir un objet à partir de son nom
 list : obtenir une liste des associations
Context context = new InitialContext();
MyEJBInterface bean= (MyEJBInterface) context.lookup("java:gloabl/MyApp/myBean");
 Standardisation du format des noms JNDI
java:global[/application name]/module name/enterprise bean name[/interface
name]
 Exemple: java:global/myApp/MyBean
 myApp : nom du module
 MyBean : nom du bean

44. Injection de dépendances
 Variable d’instance initialisée par le conteneur
 Alternative au lookup JNDI
 Interne au serveur d’application
 Exemples
 @EJB : Injecter une dépendance vers un EJB
 @Resource : injecter une ressource externe : DataSources JDBC,
destinations JMS (queue ou topic),..
 @PersistenceContext : injecter un objet de type
EntityManager
 @WebServiceRef : injecter une référence vers un service
web
 Il est possible de spécifier le nom JNDI de l’objet pour lever
toute ambiguïté.
 Par exemple, dans le cas d’une DataSource, s’il y en a plusieurs
définies sur le serveur, il faudra alors donner son nom JNDI
@Resource(name="jdbc/myDB")
47

45. Injection de dépendances
 Lors du déploiement, le conteneur résout les
références JNDI et relie les ressources en question.
 Si une ressource n’est pas trouvée lors du
déploiement, le conteneur lance une
RuntimeException, l’EJB est alors inutilisable
 L'utilisation de l'injection de dépendances
remplace l'utilisation implicite de JNDI
48

46. Intercepteurs
 Lorsqu’une méthode métier est appelée, les
intercepteurs permettent d’exécuter des
méthodes avant que la méthode métier ne soit
exécutée
 Les intercepteurs peuvent être utiles dans
plusieurs situations:
 mettre des logs sans avoir à surcharger le code,
 gérer la sécurité séparément du code métier, etc.
 Ils sont définis grâce aux annotations :
 @Interceptors : les méthodes devant être
interceptées
 @AroundInvoke : les méthodes d'interception
49

47. Intercepteurs
50

48. Callbacks
 Les callbacks permettent d’exécuter des méthodes
lorsque certains événements liés au cycle de vie de
l’EJB interviennent (création, suppression,
passivation, activation)
 Après la création (@PostConstruct)
 (Stateless, Stateful, Message-Driven)
 Avant la suppression (@PreDestroy)
 (Stateless, Stateful, Message-Driven)
 Avant la passivation (desactivation) (@PrePassivate)
 (Stateful)
 Après l’activation (@PostActivate)
 (Stateful)
51

49. Cycle de vie - Stateful
52
 3 phases : Non existant, Prêt, Passif
 Le client initie le cycle de vie en obtenant une référence de
l’EJB
 Le conteneur peut désactiver le bean en le déplaçant de la
mémoire vers le disque (algorithme LRU (Least Recent Used)
 Conteneur :
 Résolution des injections de
dépendances et appel des
méthodes callback (si elles
existent)
 @PostConstruct : après la
construction
 @PrePassivate : avant la
passivation
 @ PostActivate : après l’activation
 @PreDestroy : avant la destruction

50. Cycle de vie - Stateless
53
 2 phases : Non existant, Prêt
 Le conteneur crée et maintient un pool de beans session
pour initialiser le cycle de vie du bean.
 Le conteneur effectue toute injection de dépendance et puis
appelle la méthode annotée @PostConstruct (si elle existe)
 A la fin du cycle de vie, le conteneur
EJB appelle la méthode annotée
@PreDestroy (si elle existe)

51. Cycle de vie - MDB
54
 2 phases : Non existant, Prêt à recevoir les messages
 Le conteneur crée un pool d'instances de message-
driven bean.
 Le conteneur injecte les références d’injection de
dépendance avant d'instancier l'instance. Le conteneur appelle la
méthode annotée
@PostConstruct (si elle
existe).
 A la fin du cycle de vie, le
conteneur appelle la
méthode annotée
@PreDestroy (si elle
existe).

52. Transaction
56
 Service de transactions
 Assure des propriétés ACID pour des transactions
plates
 Exemple classique : un transfert bancaire (débit,
crédit)
 Atomicité : soit les 2 opérations s'effectuent
complètement, soit aucune
 Cohérence : le solde d'un compte ne doit jamais être
négatif
 Isolation : des transferts // doivent fournir le même
résultat qu'en séquentiel.
 Durabilité : les soldes doivent être sauvegardés sur
support stable

53. Granularité des transactions
57
 Comment démarquer (délimiter) les transactions ?
 Attribut transactionnel avec 6 valeurs: REQUIRED, REQUIRED_NEW, SUPPORTS,
MANDATORY, NOT_SUPPORTED, NEVER
 2 cas pour le bean appelant
 soit il s'exécute dans une transaction
 soit il s'exécute en dehors de tout contexte transactionnel

54. 58
REQUIRED
SUPPORTS
MANDATORY
NOT_SUPPORTED
NEVER
REQUIRED_NEW

55. Définition des transactions
59
 2 modes
 BMT (Bean-Managed Transactions)
 @TransactionManagement(TransactionManagementType.BEA
N)
 CMT (Container-Managed Transactions)
 @TransactionManagement(TransactionManagementType.CON
TAINER)
 Par défaut, le conteneur gère les transactions
 JTA (Java Transaction API) fournit une API
permettant de gérer les transactions
 JPA (Java Persistance API) ne dépend pas du
mode de gestion des transactions

56. CMT
60
 Annotations
 @TransactionManagement sur la classe
 @TransactionAttribute(TransactionAttributeType.
XXX) sur les méthodes transactionnelles
 où XXX est l’un des 6 attributs précédents
 Toute la méthode est considérée comme un
bloc transactionnel
 commit par défaut en fin de méthode
 appel setRollbackOnly() pour annuler

57. CMT - Exemple
61

58. BMT
62
 Démarcation explicite avec
begin/commit/rollback
 On injecte une dépendance : UserTransaction
@Resource private UserTransaction
userTransaction;
 Méthodes
 userTransaction.begin()
 userTransaction.commit()
 userTransaction.rollback()
 Avantage : possibilité granularité plus fine
qu'en CMT

59. BMT - Exemple
63

60. Sécurité
64
 Contrôler l'accès aux méthodes d'un bean
 Authentifier l'utilisateur
 À base de rôles
5
@(javax.annotation.security)
@PermitAll
@DenyAll
@RolesAllowed
@DeclareRoles
@RunAs

61. Sécurité
65
 javax.annotation.security.PermitAll :
 Indique que la méthode donnée ou toutes les méthodes métier
de l'EJB donné sont accessibles par tout le monde
 javax.annotation.security.DenyAll :
 Indique que la méthode donnée de l'EJB n'est accessible par
personne
 javax.annotation.security.RolesAllowed :
 Indique que la méthode donnée ou toutes les méthodes métier
de l'EJB sont accessibles par les utilisateurs associés à la liste
de rôles.
 javax.annotation.security.DeclareRoles :
 Définit des rôles pour le contrôle de la sécurité. A utiliser par
EJBContext.isCallerInRole, HttpServletRequest.isUserInRole et
WebServiceContext.isUserInRole.
 javax.annotation.security.RunAs :
 Spécifie le rôle d'identité d'exécution (run-as) pour les
composants donnés.

62. Sécurité – Exemple 1
66
 hello : accessible par tout le monde
 bye : accessible seulement pour le rôle javaee

63. Sécurité – Exemple 2
67
 Pour les cas plus complexes : @DeclaresRoles
 La boucle if{} est accessible par ceux qui sont dans le
rôle A mais pas dans le rôle B

64. 68

65. 69

66. 70

67. Cycle de vie
 Stateful Session
71

68. Cycle de vie
 Stateless Session
72

69. Cycle de vie
 Message Driven
73

70. Les objets distribués et le
middleware
 Lorsqu'une application devient importante,
des besoins récurrents apparaissent :
sécurité, transactions, persistance…
 C'est là qu'intervient le middleware!
 Deux approches
1. Middleware explicite,
2. Middleware implicite
74

71. Middleware explicite
75

72. 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 vérification de
sécurité,
2. Appel vers l'API de transaction pour démarrer 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.
76

73. Middleware explicite
 Difficile à écrire,
 Difficile à maintenir,
 Le code est dépendant des API du vendeur de
middleware utilisé.
77

74. Middleware implicite
78

75. 79

76. Contrats EJB
 Modèle de développement uniforme pour
les applications utilisant les composants EB
 Contrat coté client: fournir une vue uniforme du
bean au client indépendante de la plate-forme
de déploiement
 Contrat coté conteneur: assurer la portabilité du
bean sur différents serveurs EJB

77. 81

78.  Les diapos suivants concernent EJB 2
82

79. Comment utiliser un EJB
 localiser le Bean par JNDI (Java Naming and
Directory Interface)
 utiliser le Bean
 via Home Interface : méthodes liées au cycle de
vie du bean
 : create(), remove(), …
 via Remote Interface : services métiers par le
bean
 Le conteneur implémente le mécanisme de
délégation permettant de faire suivre l’appel
au bean
83

80. Comment utiliser un EJB
 Les clients d'un Bean lui parlent au travers
d'interfaces
 Ces interfaces, de même que le Bean, suivent la
spécification EJB
 Cette spécification requiert que le Bean expose
certaines méthodes
 En général (EJB 2.1 Session et Entity), le bean doit
proposer une interface de création (Home) et une
interface d’utilisation (Remote)
84

81. Comment utiliser un EJB
 + éventuellement 2 interfaces d’accès local
 Pour établir la communication avec les clients
locaux (partageant la même machine virtuelle)
85

82. Processus de développement
 Développement d’un bean
 Ecrire la Home interface
 Ecrire la Remote interface
 Ecrire l’implémentation (classe) du bean
 Compiler ces classes et interfaces
 Déploiement du Bean
 Construire le descripteur de déploiement
 Construire le fichier d’archive .jar ou .ear
 Utilisation du Bean
 Ecrire, compiler et exécuter le client
 qui peut être une servlet ou une application Java ou une
applet, etc.
86

83. 87

84. 88

85. Qu'est-ce qu'un Message-Driven
Bean ?
 Un EJB qui peut recevoir des messages
 Il consomme des messages depuis les queues ou
topics, envoyés par les clients JMS
89

86. 90

87. Exemple 1 : Convertisseur de
monnaie
 Une application qui convertit la monnaie du
Dollar au Yen et le Yen à l’euro
 Créer l’interface distante (remote interface)
 Implémenter l’interface (business methods)
 Créer un client local (Injection de dépendance)
 Créer un client distant (recherche sur JNDI)
91

88. Remote Interface
92

89. Business Methods
93

90. Local client (1/2)
94

91. Local client (2/2)
95

92. Remote client (1/3)
96

93. Remote client (3/ 3)
97

94. Remote client (2/2)
98

95. Exemple 2: Simple Message
application
 The application client sends messages to the queue,
which was created administratively using the Admin
Console. The JMS provider (in this case, the
Application Server) delivers the messages to the
instances of the message-driven bean, which then
processes the messages.
99

96. Exemple 2: Simple Message
application
 Write the SimpleMessageClient: An application
client that sends several messages to a queue
 Write the SimpleMessageEJB: A message-
driven bean that asynchronously receives and
processes the messages that are sent to the
queue
 Info nécessaires :
 jms/ConnectionFactory : désignation de la
fabrique de connexion
 jms/Queue : désignation de la queue
100

97. SimpleMessageClient
101

98. SimpleMessageClient
102

99. SimpleMessageEJB
103

100. 104

101. SimpleMessageEJB
105

102. 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 même client appelle
une autre méthode.
 Problème si trop de clients utilisent ce type de Bean en
même temps.
 Ressources limitées (connexions, mémoire, sockets…)
 Mauvaise scalabilité du système,
 L'état peut occuper pas mal de mémoire…
 Problème similaire à la gestion des tâches dans un
OS…
106

103. Pooling des Stateful Session
Beans
 Avec un OS : on utilise le concept de mémoire
virtuelle…
 Lorsqu'un processus ne fait plus rien (Idle), on
swappe son état mémoire sur disque dur, libérant
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…
107

104. Pooling des Stateful Session
Beans
 Avec les Stateful Session Beans on fait pareil !
 Entre chaque appel de méthode, un client ne fait
rien (Idle),
 Pendant qu'il ne fait rien, l'état du bean est
swappé mais les ressources telles que les
connexions BD, sockets, la mémoire intrinsèque
qu'il occupe, peuvent être utilisées par un autre
client.
108

105. Pooling des Stateful Session
Beans
 Principe : l'activation/passivation
 Choix du bean à swapper par LRU le plus
souvent (Least Recent Used)
 Choix du bean à activer : lorsqu'on le demande
(Just in Time)
 On peut effectuer des actions avant la
passivation (@PrePassivate) ou après
l’activation (@Post1Activate)
 libérer des ressources, les re-ouvrir…
109

106. Activation/Passivation callbacks
 Lorsqu'un bean va être mis en passivation, le
container peut l’avertir (@PrePassivate)
 Il peut libérer des ressources (connexions…)
 Idem lorsque le bean vient d'être activé
(@PostActivate)
110

107. 111

108. Transactions distribuées
XA (eXtended Architecture)112
 Afin de garantir les propriétés ACID vues
précédemment, dans un contexte où les sources de
données sont distribués, il faut que les drivers des
bases de données soient de type XA
 L’architecture XA définit un protocole de validation en
2 phases et un API pour la communication entre un
transaction manager et un resource manager
 Dans le cas d’une transaction où l’on doit enregistrer
des données dans 2 bases de données, que faire si
lors de la validation une se déroule avec succès et
l’autre non ?
 L’application se trouvera alors dans un état
inconsistant et les propriétés ACID ne seront plus
respectées !
=> utilisation du protocole de validation en 2
phases

109. 113