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)

704 vues

Publié le

Les composants EJB et ses différentes API

Publié dans : Formation
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
704
Sur SlideShare
0
Issues des intégrations
0
Intégrations
14
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Voir spring, struts, …
  • Label Java EE Sun (qualification de plateformes)

    Modèle de programmation
    Implémentation de référence
    Suite(s) de tests
  • Oracle est le responsable de java sun.
  • Parler de 4 types de conteneurs ici
    Client
    Léger (Web, browser)
    Lourd (Application java, Applet…)
    Architecture orientée service (Application répartie sans présentation)

  • JPQL (Java Persistence Query Language) permet d’interroger les objets stockés dans la base de données sous-jacente.
  • ⇒ Traitement des données : Modèle
  • Home Interface n’existe plus dans EJB 3.
  • EJB : composants spécifiques chargés des traitements des données propres a un secteur d’activité (logique métier, logique applicative) et de l’interfaçage avec les bases de données.

  • La présentation est du ressort du client
    actuellement (2013) EJB 3.2 (JEE 7)
  • Le fournisseur du serveur d'application est le même que le fournisseur de conteneurs EJB.
    Ne pas confondre avec les Java Beans coté client
  • Le serveur joue le rôle d’intermédiaire entre le système et le conteneur (il permet au conteneur de réaliser ses fonctions en faisant appel aux primitives du système)
  • les services offerts par le bean à ses clients locaux
    les mêmes (ou d'autres) que ceux offerts à distance
     Optimisation
  • Il faut voir aussi les Singletons
    Exécutent une tâche pour le client (ex: service de change pour une banque)
  • Souvent clients d'autres Beans
    Puis les beans sessions accèdent aux Entity beans
    En général c’est par ces beans que commence la première connexion de l’utilisateur de l’application

    Durée de vie = la session
    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.


  • Chaque session bean a un moment donné entretient une conversation avec un client.
  • Le conteneur est responsable de la création et de la destruction du Bean
    Il peut le détruire juste après un appel de méthode, ou le garder en mémoire pendant un certain temps pour réutilisation.
  • D'une requête HTTP à l'autre, il faut un moyen de conserver un état (le caddy par ex.)
    une application bancaire. Le client effectue plusieurs opérations. On en va pas à chaque fois lui redemander son numéro de compte et son mot de passe

  • @Singleton
  • attribut du type de l'interface
    L'annotation @EJB permet de demander au conteneur d'injecter une référence sur un EJB sans avoir à faire appel explicitement à l'annuaire du serveur avec JNDI.
    Heithem : Injection de dépendance est géré par le conteneur, donc le développeur ne se charge plus de l’appel de l’annuaire JNDI pour appeler la ressource demandée.
    Donc c’est une alternative à la recherche lookup de JNDI. IL N’EST PAS POSSIBLE d’effectuer une injection de dépendance dans un composant non managé (çad n’est pas dans un conteneur
    EJB ou conteneur de servlets). Donc un client simple SWING ne peut pas appeler une ressource via Injection de dépendance.
    Alors il est recommandé d’utiliser les injections de dépendance lorsqu’il est possible pour avoir un code « elegant » 
    Différence : Si les données risquent de ne pas être utilisées, le bean peut éviter le coût de l'injection en effectuant à la place une recherche JNDI. En ce cas, le code ne prend les données que s'il en a besoin au lieu d'accepter des données qui lui sont transmises et qui ne lui sont plus nécessaires.

    Plus de détails : http://manu.kegtux.org/Java/Tutoriels/J2EE/BeanSession.html

  • Donnée typiquement stockée dans un SGBD (ou tout autre support accessible en JDBC)

    Objets java qui cachent des données d'une base de données
    Ils représentent les données persistantes

    Ils survivent à une panne de serveur

  • Correspondance objet – tuple relationnel (mapping Objet/Relationel)
    possibilité de définir des clés, des relations, des recherches
    mis en œuvre à l'aide
    d'annotations Java 5
    de la généricité Java 5
    de l'API JPA ( Java Persistence API)

  • Il existe deux modes de gestion de la persistance des données
    Container-Managed Persistence (CMP)
    Bean-Managed Persistence (BMP)

    Exemples de supports de persistance
    Sérialisation
    Accès à une base par JDBC



    Serveurs pour des Beans Session (le plus souvent)
  • Gérée par le bean (via JDBC ou SGF) => BMP

    Gérée par le conteneur (utilisation des container maintened fields): le code d’accès à la BD est délégué au conteneur => CMP

  • L'instance EJB contient une copie des données du système de stockage
    2 modes de définition des colonnes des tables
    property-based access : on annote les méthodes getter
    field-based access : on annote les attributs

    par défaut colonne avec même nom que field/property
    sauf si annotation @Column(name="...")

    annotation @Id : définit une clé primaire
    types supportés
    primitifs (et leurs correspondants), String, Date
  • @PersistenceUnit uses an EntityManagerFactory, and @PersistenceContext uses an EntityManger.

    @PersistenceUnit annotation is used in J5SE applications to handle Java Persistence API (JPA) persistence management. You may use a PeristenceUnit in an application inside a container, but it must be managed by the developer instead of the container.
    @PersistenceContext annotation is used for Container Managed Persistence (CMP). This relieves the developer of having to worry about connection management.

    Injection de dépendances
    • Variable d’instance initialisée par le conteneur
    – Alternative au lookup JNDI
    – Interne au conteneur (pas client distant !)
    • Implicite ou avec spécification du nom (name=¶\ nom
    JNDI ¶], optionnel)
    – @EJB private CalculatorLocal calc; // Injection d’EJB (local)
    – @Resource javax.sql.DataSource ds; // Injection de ressource
    • Egalement utilisé par JPA pour le contexte de
    persistance
  • @PersistenceUnit uses an EntityManagerFactory, and @PersistenceContext uses an EntityManger.

    @PersistenceUnit annotation is used in J5SE applications to handle Java Persistence API (JPA) persistence management. You may use a PeristenceUnit in an application inside a container, but it must be managed by the developer instead of the container.
    @PersistenceContext annotation is used for Container Managed Persistence (CMP). This relieves the developer of having to worry about connection management.
  • The createQuery method is used to create dynamic queries, which are queries defined directly within an application’s business logic:

    requêtes SELECT dans une syntaxe dite EJB-QL étendue
  • The createNamedQuery method is used to create static queries, or queries that are defined in metadata by using the javax.persistence.NamedQuery annotation. The name element of @NamedQuery specifies the name of the query that will be used with the createNamedQuery method. The query element of @NamedQuery is the query:

    POJO est un acronyme qui signifie Plain Old Java Object que l'on peut traduire en français par bon vieil objet Java.Cet acronyme est principalement utilisé pour faire référence à la simplicité d'utilisation d'un Objet Java en comparaison avec la lourdeur d'utilisation d'un composant EJB. Ainsi, un objet POJO n'implémente pas d'interface spécifique à un framework comme c'est le cas par exemple pour un composant EJB.
  • : listener processing messages asynchronously
    Nouveauté apparue avec EJB 2.0,
    Pratique dans de nombreux cas,
    Message-Driven beans = beans accessibles par messaging asynchrone.
    Similaire aux Session bean : représentent des actions
    On les invoque en leur envoyant des messages,
    Souvent clients d'autres beans…
  • Analogie : JPA et Moteurs de persistance
  • Localiser le driver JMS
    lookup JNDI. Le driver est une connection factory
    Créer une connection JMS
    obtenir une connection à partir de la connection factory
    Créer une session JMS
    Il s'agit d'un objet qui va servir à recevoir et envoyer des messages. On l'obtient à partir de la connection.
    Localiser la destination JMS
    Il s'agit du canal, de la chaîne télé ! Normalement, c'est réglé par le déployeur. On obtient la destination via JNDI.
    Créer un producteur ou un consommateur JMS
    Utilisés pour écrire ou lire un message. On les obtient à partir de la destination ou de la session.
    Envoyer ou recevoir un message


    Session période de temps pour l'envoi de messages dans 1 queue/topic
    peut être rendue transactionnelle
    similitude avec les notions de sessions JDBC, Hibernate, …


    (* : éventuellement plusieurs sessions par connexion)
  • Peut être qu’il faut enrichir cette partie
  • Shipping = expédition
  • Services Externes
    Gestion du Mapping sur base de données relationnelle
    Gestion des transactions et des échanges de messages

    Ces services peuvent être demandés par appels de méthodes par le client.
    Il seront réalisés par des méthodes propres au bean

  • Un pilote est un ensemble de classes qui implémentent les interfaces de JNDI pour permettre les interactions avec un service particulier. Ce mode de fonctionnement est identique à celui proposé par l'API JDBC.

    Tous les EJB de type Session sont enregistrés dans un annuaire avec un nom unique accessible par un client via un contexte JNDI que ce soit en utilisant directement le contexte (hors du conteneur) ou en utilisant l'injection de dépendance (dans le conteneur).



    Un service de nommage permet d'associer un nom à un objet. Cette association est nommée binding.
    Deux types de contexte :
    Contexte racine et Sous contexte (un contexte relatif à un contexte racine)
    Par exemple, c:\ est un contexte racine dans un système de fichiers de type Windows. Le répertoire windows (C:\windows) est un sous-contexte du contexte racine
    Dans DNS, com est un contexte racine et test est un sous contexte (test.com)


  • Je peux enrichir cette partie de JNDI (reste bcp de chose à dire, factory…)
    Le nom associé à un objet respecte une convention de nommage particulière à chaque type de service.
    Avec un système de fichiers de type Unix, le nom est composé d'éléments séparés par un caractère "/"
    Avec un système de fichiers de type Windows, le nom est composé d'éléments séparés par un caractère "\"
    Avec un service de type DNS, le nom est composé d'éléments séparés par un caractère "." (exemple : www.test.fr).
    Avec un service de type LDAP, le nom désigné par le terme Distinguished Name est composé d'éléments séparés par un caractère ",". Un élément est de la forme clé=valeur.

    !!!JNDI existe depuis longtemps mais, bien que son API fût standardisée et portable entre les serveurs d’applications, ce n’était pas le cas des noms JNDI, qui restaient
    spécifiques aux plates-formes. Lorsqu’un EJB était déployé dans GlassFish ou JBoss, son nom dans le service d’annuaire était différent et donc non portable : un
    client devait rechercher un EJB avec un certain nom sous GlassFish et un autre sous JBoss... EJB 3.1 a standardisé les noms JNDI afin qu’ils soient désormais portables.
    Dans l’exemple précédent, le nom java:global/chapter06/BookEJB respecte cette nouvelle convention de nommage : java:global[/<nom-app>]/<nom-module>/<nom-bean> [!<nom-interface-pleinement-qualifié>]

    URL JNDI type : chemin/nom
    RMI-IIOP iiop://myhost.com/myBean
    LDAP ldap://localhost:389

    Ce nom JNDI est composé de façon à le rendre unique dans une instance d'un conteneur en utilisant le préfixe java:global, le nom de l'application, le nom du module, le nom du bean et le nom de l'interface sous la forme:
    java:global[/<application-name>]/<module-name>/<bean-name>!<interface-name

    The java:global JNDI namespace is the portable way of finding remote enterprise beans using JNDI lookups. JNDI addresses are of the following form:
java:global[/application name]/module name/enterprise bean name[/interface name]
Application name and module name default to the name of the application and module minus the file extension. Application names are required only if the application is packaged within an EAR. The interface name is required only if the enterprise bean implements more than one business interface.
  • Interne au serveur d’application (pas client distant !)

    Implicite ou avec spécification du nom (name= nom « JNDI » , optionnel) @EJB private CalculatorLocal calc; : Injection d’EJB (local)
    @Resource javax.sql.DataSource ds; : Injection de ressource
    @PersistenceContext : injecter un objet de type EntityManager

    L’annotation @Resource permet d’injecter un objet référencé
    EJB, JMS, Data Source, contexte de sécurité, contexte de persistance, contexte de transaction, ...


    L'annotation @EJB permet d'injecter une ressource de type EJB.


  • Contrairement aux clients dit standalone, un client container-managed peut utiliser l'injection, grâce à l'annotation @EJB, pour récupérer des références vers les EJB dont il dépend. Cela évite l'écriture de la localisation JNDI. Les références vers les EJB sont automatiquement détectées et gérées par le conteneur client. Avec cette approche, l'application cliente ne fait plus référence à un serveur d'applications en particulier. Du coup, l'écriture devient standard et s'applique à tous les serveurs, ce qui offre une meilleure portabilité à vos applications.
  • Alors que dans la phase de prêt, le conteneur EJB peut décider de désactiver ou passiver, le bean en le déplaçant de la mémoire vers un stockage secondaire. (Typiquement, le conteneur d'EJB utilise un algorithme moins récemment utilisé pour sélectionner un haricot pour la passivation.)

    A la fin du cycle de vie, le client invoque une méthode annotée @ Remove et le conteneur EJB appelle la méthode annotée @ PreDestroy, le cas échéant. Par exemple la fève est alors prêt pour la collecte des ordures.

    Votre code de contrôle de l'invocation d'une seule méthode du cycle de vie: la méthode annotée @ Remove. Toutes les autres méthodes dans la figure 14-3 sont invoquées par le conteneur EJB. Voir Chapitre 28, Connexions ressources pour plus d'informations.
  • At the end of the lifecycle, the EJB container calls the method annotated @PreDestroy, if it exists. The bean’s instance is then ready for garbage collection.
    Garbage collection : In computer science, garbage collection (GC) is a form of automatic memory management
  • Assure des propriétés ACID pour des transactions plates
    Véritable avantage par rapport aux middlewares style CORBA

  • n’influe que sur les EJB Session et les Message-Driven, et non sur les Entity

    CMT (Container Managed Transaction) : annotations
    BMT (Bean Managed Transaction) : API JTA
  • • La UserTransaction ne peut être utilisée que dans le cas où les
    transactions sont gérées par l’EJB (BMT); dans le cas où c’est le
    conteneur (CMT) une IllegalStateException est levée
  • javax.annotation.security.PermitAll :
    Peut être utilisée au niveau type ou méthode.
    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 :
    Peut être utilisée au niveau méthode.
    Indique que la méthode donnée de l'EJB n'est accessible par personne.
    javax.annotation.security.RolesAllowed :
    Peut être utilisée au niveau type ou méthode.
    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 :
    Peut être utilisée au niveau type.
    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 :
    Peut être utilisée au niveau type.
    Spécifie le rôle d'identité d'exécution (run-as) pour les composants donnés.
  • La boucle if{} est accessible pour A mais pas pour B, le reste est accessible pour les 2
  • Un utilisateur d'un site de e-commerce lit les infos sur la page www, réfléchit… de temps en temps il clique sur un bouton…
  • Ceci a un coût : l'activation/passivation génère des E/S
  • 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

    ×