Successfully reported this slideshow.
heithem.abbes@gmail.com
Les Entreprise Java Beans
(EJB)
Introduction JEE
 Java
 JSE : Java Standard Edition (PCs)
 JME: Java Micro Edition (mobiles)
 JEE: Java Entreprise Edi...
Java EE – C’est quoi?
 Anciennement, J2EE (Java2 Enterprise
Edition)
 Norme proposée par SUN visant à définir un
standar...
Serveurs d’applications JEE
 Offre commerciale
 BEA WebLogic (haut de
gamme)
 IBM Websphere (no 1)
 Sun Java System Ap...
Java EE - Architecture
5
 Client
 Léger (Web, browser) et Lourd (Application java, Applet…)
 Serveur d ’applications
 ...
Services JEE
 JDBC (Java DataBase Connectivity) est une API
d'accès aux bases de données relationnelles
 JNDI (Java Nami...
Services JEE
 JMX (Java Management Extension) fournit des
extensions permettant de développer des applications
web de sup...
Composants EJB
 « A server-side component that encapsulates
the business logic of an application »
 On se focalise sur l...
Composants EJB
 EJB ne fournit pas de GUI
 GUI (Graphical User Interface)= côté client
 Applications classiques
 Java ...
Schéma d’exécution des EJB
 Les conteneurs isolent les beans des clients et d’une
implémentation spécifique du serveur
13...
Accès aux composants EJB
 Chaque EJB fournit 1 interface
d'accès distant
 les services (méthodes) offerts à
ses clients
...
Types des EJB
 3 types de beans:
 Session Beans
 Représente un traitement (services fournis à un
client)
 Entity Beans...
Session Bean
 Modélise un traitement (ou session)
 Processus métier (business process): services fournis aux
clients
 E...
Types de Session Beans
 Chaque session bean entretient une
conversation avec un client.
 Conversation = suites d'appels ...
Stateless Session Beans
 Sans état : ne conserve pas d’information entre 2
appels successifs
 Certaines conversations pe...
Stateful Session Beans
 Certaines conversations se déroulent sous forme de
requêtes successives.
 D'une requête à l'autr...
Session Bean - Développement
 1 interface (éventuellement 2 : Local + Remote) + 1
classe
 Interface
 annotations @javax...
Session Bean - Développement
 Classe
 annotations @Stateless ou @Stateful
Possibilité de nommer les beans : @Stateless(n...
Session Bean - Développement
Client local
 Typiquement une servlet ou une JSP
 colocalisée sur le même serveur que le
be...
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...
Entity Bean (EB)
 Représentation d'une donnée, manipulée par l'application,
typiquement stockée dans un SGBD
 l’état d’u...
Entity Bean (EB)
 Correspondance objet – relationnel (mapping
Objet/Relationel)
 Les attributs d'un objet sont enregistr...
Mapping objet/BD relationelle
26
Propriétés des Entity Beans
 Plusieurs clients peuvent utiliser des EB qui
« pointent » sur les mêmes données
 Une insta...
Persistance d’un Entity Bean
 Il existe deux types de persistance pour les Entity
Bean :
 Bean-Managed Persistence (BMP)...
Entity Bean - Développement
 annotation @Entity :
 déclare une classe correspondant à un Entity
Bean
 chaque classe de ...
Entity Bean - Développement
30
Entity Bean – Entity Manager
 Gestionnaire d'entités (Entity Manager)
 assure la correspondance entre les objets Java et...
Entity Bean – Entity Manager
 Exemple
 création de trois enregistrements dans la table des
livres
de façon similaire em....
Entity Bean – Entity Manager
Recherche par clé primaire
 méthode find du gestionnaire d'entités
Book myBook = em.find(Boo...
Entity Bean – Entity Manager
Recherche par requête
 requêtes SELECT dans une syntaxe EJB-QL
 mot clé OBJECT pour désigne...
Entity Bean – Entity Manager
Recherche par requête pré-compilée
 création d'une requête nommée attachée à l'EB
35
Message-Driven Bean
 Interaction par envoie de messages asynchrone
 MOM : Message-Oriented Middleware
 2 modes
 Point-...
Messaging
37
Client/Serveur : communication synchrone
Producteur/Consommateur : communication asynchro
Caractéristiques des MDB
 consomme des messages asynchrones
 pas d'état ( stateless session bean)
 toutes les instances...
MOM et JMS
 Message Oriented Middleware (MOM) :
middlewares qui supportent le messaging.
 fournissent : messages avec ga...
Concepts des MDB
 MDB basé sur Java Messaging Service (JMS)
 ConnectionFactory : fabrique pour créer des connexions vers...
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. Fer...
MDB - Développement
Producteur
42
MDB - Développement
Consommateur
 MDB = classe
 annotée @MessageDriven
 implantant interface MessageListener
 méthode ...
 Fournit les services
 de nommage (JNDI)
 de persistance (EntityManager)*
 de gestion du cycle de vie
 de transaction...
JNDI (Java Naming and Directory Interface)
 JNDI est composée de :
 API standard utilisée pour
développer des applicatio...
JNDI (Java Naming and Directory
Interface)
46
 À partir du contexte, on appelle les opérations
 bind : associer un objet...
Injection de dépendances
 Variable d’instance initialisée par le conteneur
 Alternative au lookup JNDI
 Interne au serv...
Injection de dépendances
 Lors du déploiement, le conteneur résout les
références JNDI et relie les ressources en questio...
Intercepteurs
 Lorsqu’une méthode métier est appelée, les
intercepteurs permettent d’exécuter des
méthodes avant que la m...
Intercepteurs
50
Callbacks
 Les callbacks permettent d’exécuter des méthodes
lorsque certains événements liés au cycle de vie de
l’EJB int...
Cycle de vie - Stateful
52
 3 phases : Non existant, Prêt, Passif
 Le client initie le cycle de vie en obtenant une réfé...
Cycle de vie - Stateless
53
 2 phases : Non existant, Prêt
 Le conteneur crée et maintient un pool de beans session
pour...
Cycle de vie - MDB
54
 2 phases : Non existant, Prêt à recevoir les messages
 Le conteneur crée un pool d'instances de m...
Transaction
56
 Service de transactions
 Assure des propriétés ACID pour des transactions
plates
 Exemple classique : u...
Granularité des transactions
57
 Comment démarquer (délimiter) les transactions ?
 Attribut transactionnel avec 6 valeur...
58
REQUIRED
SUPPORTS
MANDATORY
NOT_SUPPORTED
NEVER
REQUIRED_NEW
Définition des transactions
59
 2 modes
 BMT (Bean-Managed Transactions)
 @TransactionManagement(TransactionManagementT...
CMT
60
 Annotations
 @TransactionManagement sur la classe
 @TransactionAttribute(TransactionAttributeType.
XXX) sur les...
CMT - Exemple
61
BMT
62
 Démarcation explicite avec
begin/commit/rollback
 On injecte une dépendance : UserTransaction
@Resource private ...
BMT - Exemple
63
Sécurité
64
 Contrôler l'accès aux méthodes d'un bean
 Authentifier l'utilisateur
 À base de rôles
5
@(javax.annotation...
Sécurité
65
 javax.annotation.security.PermitAll :
 Indique que la méthode donnée ou toutes les méthodes métier
de l'EJB...
Sécurité – Exemple 1
66
 hello : accessible par tout le monde
 bye : accessible seulement pour le rôle javaee
Sécurité – Exemple 2
67
 Pour les cas plus complexes : @DeclaresRoles
 La boucle if{} est accessible par ceux qui sont d...
68
69
70
Cycle de vie
 Stateful Session
71
Cycle de vie
 Stateless Session
72
Cycle de vie
 Message Driven
73
Les objets distribués et le
middleware
 Lorsqu'une application devient importante,
des besoins récurrents apparaissent :
...
Middleware explicite
75
Middleware explicite
 Exemple : transfert d'un compte bancaire vers un autre
:
 transfert(Compte c1, Compte c2, long mon...
Middleware explicite
 Difficile à écrire,
 Difficile à maintenir,
 Le code est dépendant des API du vendeur de
middlewa...
Middleware implicite
78
79
Contrats EJB
 Modèle de développement uniforme pour
les applications utilisant les composants EB
 Contrat coté client: f...
81
 Les diapos suivants concernent EJB 2
82
Comment utiliser un EJB
 localiser le Bean par JNDI (Java Naming and
Directory Interface)
 utiliser le Bean
 via Home I...
Comment utiliser un EJB
 Les clients d'un Bean lui parlent au travers
d'interfaces
 Ces interfaces, de même que le Bean,...
Comment utiliser un EJB
 + éventuellement 2 interfaces d’accès local
 Pour établir la communication avec les clients
loc...
Processus de développement
 Développement d’un bean
 Ecrire la Home interface
 Ecrire la Remote interface
 Ecrire l’im...
87
88
Qu'est-ce qu'un Message-Driven
Bean ?
 Un EJB qui peut recevoir des messages
 Il consomme des messages depuis les queues...
90
Exemple 1 : Convertisseur de
monnaie
 Une application qui convertit la monnaie du
Dollar au Yen et le Yen à l’euro
 Crée...
Remote Interface
92
Business Methods
93
Local client (1/2)
94
Local client (2/2)
95
Remote client (1/3)
96
Remote client (3/ 3)
97
Remote client (2/2)
98
Exemple 2: Simple Message
application
 The application client sends messages to the queue,
which was created administrati...
Exemple 2: Simple Message
application
 Write the SimpleMessageClient: An application
client that sends several messages t...
SimpleMessageClient
101
SimpleMessageClient
102
SimpleMessageEJB
103
104
SimpleMessageEJB
105
Pooling des Stateful Session
Beans
 Le pooling des instances de Stateful Session Beans
n'est pas aussi simple…
 Le clien...
Pooling des Stateful Session
Beans
 Avec un OS : on utilise le concept de mémoire
virtuelle…
 Lorsqu'un processus ne fai...
Pooling des Stateful Session
Beans
 Avec les Stateful Session Beans on fait pareil !
 Entre chaque appel de méthode, un ...
Pooling des Stateful Session
Beans
 Principe : l'activation/passivation
 Choix du bean à swapper par LRU le plus
souvent...
Activation/Passivation callbacks
 Lorsqu'un bean va être mis en passivation, le
container peut l’avertir (@PrePassivate)
...
111
Transactions distribuées
XA (eXtended Architecture)112
 Afin de garantir les propriétés ACID vues
précédemment, dans un c...
113
Prochain SlideShare
Chargement dans…5
×

Entreprise Java Beans (EJB)

1 679 vues

Publié le

Les composants EJB et ses différentes API

Publié dans : Formation
  • Soyez le premier à commenter

Entreprise Java Beans (EJB)

  1. 1. heithem.abbes@gmail.com Les Entreprise Java Beans (EJB)
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17. Session Bean - Développement  1 interface (éventuellement 2 : Local + Remote) + 1 classe  Interface  annotations @javax.ejb.Local ou @javax.ejb.Remote 20
  18. 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. 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. 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. 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. 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. 23. Mapping objet/BD relationelle 26
  24. 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. 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. 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. 27. Entity Bean - Développement 30
  28. 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. 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. 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. 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. 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. 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. 34. Messaging 37 Client/Serveur : communication synchrone Producteur/Consommateur : communication asynchro
  35. 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. 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. 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. 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. 39. MDB - Développement Producteur 42
  40. 40. MDB - Développement Consommateur  MDB = classe  annotée @MessageDriven  implantant interface MessageListener  méthode void onMessage(Message) Queue" ) 43
  41. 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. 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. 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. 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. 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. 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. 47. Intercepteurs 50
  48. 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. 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. 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. 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. 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. 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. 54. 58 REQUIRED SUPPORTS MANDATORY NOT_SUPPORTED NEVER REQUIRED_NEW
  55. 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. 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. 57. CMT - Exemple 61
  58. 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. 59. BMT - Exemple 63
  60. 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. 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. 62. Sécurité – Exemple 1 66  hello : accessible par tout le monde  bye : accessible seulement pour le rôle javaee
  63. 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. 64. 68
  65. 65. 69
  66. 66. 70
  67. 67. Cycle de vie  Stateful Session 71
  68. 68. Cycle de vie  Stateless Session 72
  69. 69. Cycle de vie  Message Driven 73
  70. 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. 71. Middleware explicite 75
  72. 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. 73. Middleware explicite  Difficile à écrire,  Difficile à maintenir,  Le code est dépendant des API du vendeur de middleware utilisé. 77
  74. 74. Middleware implicite 78
  75. 75. 79
  76. 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. 77. 81
  78. 78.  Les diapos suivants concernent EJB 2 82
  79. 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. 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. 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. 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. 83. 87
  84. 84. 88
  85. 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. 86. 90
  87. 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. 88. Remote Interface 92
  89. 89. Business Methods 93
  90. 90. Local client (1/2) 94
  91. 91. Local client (2/2) 95
  92. 92. Remote client (1/3) 96
  93. 93. Remote client (3/ 3) 97
  94. 94. Remote client (2/2) 98
  95. 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. 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. 97. SimpleMessageClient 101
  98. 98. SimpleMessageClient 102
  99. 99. SimpleMessageEJB 103
  100. 100. 104
  101. 101. SimpleMessageEJB 105
  102. 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. 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. 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. 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. 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. 107. 111
  108. 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. 109. 113

×