EJB : les fondamentaux

Michel Buffa (buffa@unice.fr), UNSA 2002, modifi par Richard Grin (version 1.1, 21/11/11), avec emprunts aux supports de Maxime Lefranois

Plan du cours
Introduction gnrale

EJB : fondamentaux
Session Beans Entits Message-Driven Beans Concepts avancs sur la persistance Relations avec les entits Gestion des transactions

Enterprise Java Bean

Les EJB facilitent la cration d'applications distribues pour les entreprises. Soccupent du traitement mtier de lapplication Permettent aux dveloppeurs de se concentrer sur les traitements orients mtiers Sont rutilisables Sont assemblables

Enterprise Java Bean

Composant serveur qui encapsule une logique mtier, qui peut tre dploy dans un serveur dapplication Compos de un ou plusieurs objets

Les appels aux mthodes par les clients de lEJB sont intercepts par le conteneur dEJB

Rle du conteneur

Le conteneur dEJB soccupe de certains traitements

Cycle de vie du bean Injection de dpendance Accs au bean, communication distance Scurit daccs Accs concurrents Transactions,

2 Types dEJB

Session Bean

Modlise un traitement Reprsent par une classe Java et une interface qui expose certaines mthodes

Message Driven Bean (MDB)

Consomme des messages asynchrones envoys par des clients Permettent linterconnexion avec des systmes diffrents (non Java EE)

Session Bean

Modlise un traitement (business process)

Correspond un verbe, une action

Ex : gestion de compte bancaire, affichage de catalogue de produit, vrifieur de donnes bancaires, gestionnaire de prix Les actions impliquent des calculs, des accs une base de donnes, consulter un service externe (appel tlphonique, etc.) Souvent client d'autres Beans

3 types de Session Bean

Bean sans tat (stateless)

Pour traiter les requtes de plusieurs clients, sans garder un tat entre les diffrentes requtes Exemple : obtenir la liste de tous les produits

Bean avec tat (stateful)

Pour tenir une conversation avec un seul client, en gardant un tat entre les requtes Exemple : remplir le caddy dun client avant de lancer la commande (le caddy est rempli en cliquant sur les diffrentes pages des produits)

3 types de Session Bean

Bean singleton

Garantie de navoir quune seule instance du bean dans tout le serveur dapplication Supporte les accs concurrents (configurable) Exemple : bean qui cache une liste de pays, utilis par les classes de lapplication pour viter dinterroger la BD

Message-Driven Bean

Introduits partir de la norme EJB 2.0 (aujourdhui en 3.0) Similaire aux Session beans : reprsentent des verbes ou des actions, On les invoque en leur envoyant des messages, souvent dune autre application

Ex : message pour dclencher des transactions boursires, des autorisations d'achat par CB Souvent clients d'autres beans

Entit

Les applications Java EE utilisent aussi des entits Une entit est une classe qui reprsente des donnes enregistres dans une base de donnes Correspond un nom Ex : personne, produit, compte bancaire

Clients interagissant avec un serveur base d'EJBs

Objets distribus

Application distribue

Une application Java EE peut tre distribue sur plusieurs machines du rseau Les containers grent les appels distants pour le dveloppeur (utilisent RMI-IIOP)

Les objets distribus

RMI-IIOP
Machine client Client
Remote Interface

15

Machine serveur Serveur

= Objet distribu
Remote Interface

stub

~ ~

tie

IIOP Runtime JVM

IIOP Runtime JVM

RMI/IIOP

Internet

Les objets distribus et le middleware

Lorsqu'une application devient importante, des besoins rcurrents apparaissent : scurit, transactions,etc C'est l qu'intervient le middleware!

Deux approches
1. 2.

Middleware explicite, Middleware implicite

Les objets distribus

Middleware explicite

17

Machine client Client

Remote Interface

Machine serveur Serveur

= Objet distribu
Remote Interface
API transaction

Service Transaction Service Scurit Driver Base de donnes

API scurit

stub

~ ~

tie

API Base de donnes

IIOP Runtime JVM

IIOP Runtime JVM

RMI/IIOP

Internet

Les objets distribus

Middleware explicite

18

Machine client Client

Remote Interface

Machine serveur Serveur

= Objet distribu
Remote Interface
API transaction

Service Transaction Service Scurit Driver Base de donnes

API scurit

stub

~ ~

tie

API Base de donnes

Exemple : transfert d'un compte bancaire vers un autre : IIOP Runtime IIOP montant) transfert(Compte c1, Compte c2, longRuntime
1.Appeler l'API de scurit qui fait une vrification de scurit, 2.Appeler l'API de transaction pour dmarrer une transaction, 3.Appeler l'API de SGBD 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 de SGBD pour mettre jour les lignes dans les tables, 6.Appeler l'API de transaction pour terminer la transaction.

JVM

JVM

RMI/IIOP

Internet

Les objets distribus

Middleware explicite

19

Machine client Client

Remote Interface

Machine serveur Serveur

= Objet distribu
Remote Interface
API transaction

Service Transaction Service Scurit Driver Base de donnes

API scurit

stub

~ ~

tie

API Base de donnes

Exemple : transfert d'un compte bancaire vers un autre : Difficile crire IIOP Runtime IIOP montant) transfert(Compte c1, Compte c2, longRuntime 1.Appeler l'API de scurit qui fait une vrification de scurit, JVM Difficile maintenir JVM

2.Appeler l'API de transaction pour dmarrer une transaction, 3.Appeler l'API de SGBD pour lire des lignes dans des tables d'une BD, Code dpendant des API 4.Faire le calcul : enlever de l'argent d'un compte pour le mettre dans l'autre du vendeur de middleware 5.Appeler l'API de SGBD pour mettre jour les lignes dans les tables, 6.Appeler l'API de transaction pour terminer la transaction.

RMI/IIOP

Internet

Les objets distribus Middleware implicite

20

Machine client

Machine serveur
Serveur
= Objet distribu
API transaction

Service Transaction Service Scurit Driver Base de donnes

Client

Remote Interface

API scurit

Intercepteur de requte
Remote Interface Remote Interface
API Base de donnes

stub

~ ~

tie

IIOP Runtime JVM

IIOP Runtime JVM

RMI/IIOP

Internet

Les objets distribus

Middleware implicite

21

Machine client

Machine serveur
Serveur
= Objet distribu
API transaction

Service Transaction Service Scurit Driver Base de donnes

Client

Remote Interface

API scurit

Intercepteur de requte
Remote Interface Remote Interface
API Base de donnes

stub

~ ~

tie

IIOP Runtime JVM

RMI/IIOP

Internet

IIOP Runtime JVMLes besoins sont dcrits dans un fichier descripteur Lintercepteur de requte sait quoi faire

Les EJB : des objets distribus

RMI-IIOP au cur des EJBs

22

Machine client

Machine serveur
API transaction

EJB

EJB
API scurit

Service Transaction Service Scurit Driver Base de donnes

Client
Conteneur dEJB intercepteur
Remote Interface Remote Interface

stub

~ ~

API Base de donnes

tie

middleware implicite IIOP Runtime IIOP Runtime mais API pour descendre au bas niveau, Explicite

JVM JVM La plupart du temps le dveloppeur demeure au niveau implicite, Mais il peut utiliser des APIs de J2EE pour contrler manuellement les transactions, la scurit, etc. (travail plus complexe) Internet
RMI/IIOP

Un peu dimplmentation avec EJB 2.x

EJB Object

EJB 3.0 simplifie la tche du dveloppeur en cachant des dtails dimplmentation Ltude de EJB 2.x permet de comprendre comment fonctionnent les EJB

Pour chaque EJB crit par le dveloppeur, le serveur dapplication cre un objet (EJB Object) qui contient le code qui va permettre au serveur dintercepter les appels de mthode de lEJB

Rle de lEJB Object

Les clients n'invoquent jamais directement les mthodes de la classe du Bean Les appels de mthodes sont en fait envoys lEJB Object

Une fois les traitements effectus pour les transactions, scurit,.. le container appelle les mthodes de la classe du bean

Constitution d'un EJB : EJB Object

Que se passe-t-il lors de l'interception ?

Prise en compte des transactions, Scurit : le client est-il autoris ? Gestion des ressources + cycle de vie des composants : threads, sockets, connexions DB, pooling des instances (mmoire), Persistance, Accs distant aux objets, Threading des clients en attente, Clustering, Monitoring : statistiques, graphiques temps rel du comportement du systme

Constitution d'un EJB : EJB Object

Container = couche d'indirection entre le client et le bean Cette couche est matrialise par un objet unique : l'EJB Object

EJB : classe du Bean et EJB Object

EJ Bean Code simple

Gnration du code partir du Bean

Container EJB

EJB Server

Le code gnr fournit Transactions, Securit, Persistance, Accs Distant, gestion des ressources, etc.

EJB Container

EJ Bean

Serveur EJB

Fournit les services au container

EJB Object : gnration du code

Utilisation du descripteur de dploiement (fourni par l'auteur du Bean)
Container EJB

EJ Bean

Paramtres de dploiement = securit, mappings objets/BD relationelle, etc.)

Serveur EJB Container EJB

Gnration du code pour intgrer le bean dans le container, ajout du plumbing (persistance, securit, etc)

EJ Bean
Code gnr

Les interfaces

Interfaces

Pour chaque EJB session, le dveloppeur doit fournir une (ou 2) interface qui indique les mthodes de lEJB que les clients de lEJB pourront appeler Les autres mthodes de lEJB servent au bon fonctionnement de lEJB Un EJB session peut avoir une interface locale et une interface distante

Interface locale

Si lEJB na quune seule interface locale, il ne peut tre utilis que par les classes qui sont dans le mme container Le dveloppeur peut ne fournir aucune interface ; en ce cas, une interface locale est automatiquement cre, qui contient toutes les mthodes publiques de lEJB

Interface distante

Indispensable si lEJB peut tre utilis par des classes qui ne sont pas dans le mme container (application distribue) Pour manipuler un EJB travers une interface locale, le serveur dapplication utilisera RMIIIOP, ce qui implique

des performances moins bonnes les paramtres et les valeurs de retour sont transmis par recopie des valeurs (rfrences pour un appel local)

Avec les interfaces distantes

Problme : la cration de bean et l'appel de mthode distante cotent cher !

Avec les interfaces distantes

Commentaires sur la figure prcdente

1. 2. 3. 4.

5.
6. 7. 8. 9. 10.

Le client appelle un stub (souche), Le stub encode les paramtres dans un format capable de voyager sur le rseau, Le stub ouvre une connexion sur le skeleton (squelette), Le skeleton dcode les paramtres, Le skeleton appelle l'EJB Object, L'EJB Object effectue les appels middleware, L'EJB Object appelle la mthode du bean, Le Bean fait son travail, On fait le chemin inverse pour retourner la valeur de retour vers le client ! Sans compter le chargement dynamique des classes ncessaires !

Conclusion

Favoriser les interfaces locales

Ne jamais utiliser dinterfaces distantes si les EJBs et leurs clients sont dans le mme container

Packaging

Descripteur de dploiement standard

Pour informer le container des besoins middleware, on utilise un descripteur de dploiement (XML)

Standardis, A l'extrieur de l'implmentation du bean. Attention si on les crit la main ! Outils d'aide au dploiement : IDEs Descripteurs peuvent tre modifis aprs le dploiement sans devoir recompiler

application.xml, web.xml, ejb-jar.xml, facesconfig.xml

Descripteur de dploiement spcifique

Descripteurs spcifiques au serveur d'application

Chaque vendeur ajoute des trucs en plus : loadbalancing, persistance complexe, clustering, monitoring Dans des fichiers spcifiques (glassfishresource.xml, glassfish-web.xml ou glassfishapplication.xml avec GlassFish)

Format de distribution des applications

Les applications Java EE sont distribues avec des fichiers jar (format zip) Le fichier jar contient les interfaces et classes Java, les fichiers de configuration et les ressources utilises par lapplication (images, sons,)

Types de fichiers darchive

Jar (Java ARchive) : fichier darchive habituel qui contient des EJB, des classes Java ordinaires et les ressources associes War (Web ARchive) : fichier darchive pour le Web, qui contient des servlets, des fichiers HTML, des pages JSF, des EJB et les ressources associes Ear (Entreprise ARchive) : runissent des modules jar ou war

Fichier ear

Les applications Web peuvent ne contenir quun seul fichier war Les applications plus complexes, par exemple qui utilisent des MDB, contiennent plusieurs fichiers jar qui sont runis en un seul fichier ear (format jar avec une structure particulire qui permet de contenir plusieurs fichiers jar)

Service Oriented Architecture

SOA (Service Oriented Architecture)

SOA = un paradigme de conception pour lequel une application est compose de services faiblement coupls qui peuvent tourner sur des cpu diffrents et qui sont facilement localisables Service = composant de lapplication qui remplit une fonctionnalit bien dfinie, avec une interface bien dfinie Un service ne dpend pas dun contexte externe

EJB et SOA (Service Oriented Architecture)

Web Service = un exemple de SOA, adapt au Web Exemple : Google fournit de nombreux services Web tels que Google Map ou Google Calendar Plusieurs spcifications de Java EE permettent de crer facilement des services Web partir des EJB (en particulier JAX-WS et JAXB)