Cours sur les Enterprise Java Beans - LITIS

Transcription

NFP111 — Systèmes et Applications Réparties
1 de 38
Plan
Architecture d’un
système d’informations
Architecture en couches
Architecture client/serveur
Architecture 3 niveaux
Middleware
Cours 11 - Les Enterprise Java Beans (Introduction aux
Enterprise Java Beans)
L’architecture J2EE
Les technologies J2EE
Le conteneur EJB
Claude Duvallet
Les serveurs d’applications
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les objets distribués base des EJB
Middleware explicite
Middleware implicite
Exemple d’application J2EE
Université du Havre
UFR Sciences et Techniques
25 rue Philippe Lebon - BP 540
76058 LE HAVRE CEDEX
Courriel : [email protected]
http://litis.univ-lehavre.fr/∼duvallet/
Plan
Introduction aux EJB
Architecture d’un
Middleware
1
Architecture d’un système d’informations
2
3
Les EJB (Enterprise Java Beans)
4
Les objets distribués - base des EJB
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
2 de 38
Plan
Architecture d’un
Middleware
1
2
3
4
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
2 de 38
Plan
Architecture d’un
Middleware
1
2
3
4
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
2 de 38
Plan
Architecture d’un
Middleware
1
2
3
4
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
2 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Prendre en compte :
l’accès aux données,
le traitement des données,
la présentation des données,
Les EJB (Enterprise
Java Beans)
la connectivité réseau,
Les beans sessions
Les beans entités
la construction des transactions,
Les beans messages
Interface d’EJB
la sécurité de l’application.
3 de 38
4 de 38
Plan
L’architecture en couche (1/3)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Elle permet de maîtriser la conception d’un SI, ainsi que son
évolutivité en séparant les rôles sous forme de couches
logicielles.
Une architecture classique est une architecture à 3 couches :
la couche présentation,
la couche métier,
la couche données.
La couche présentation :
elle contient des composants qui réalisent l’interface
graphique de l’application et gèrent les interactions avec
l’utilisateur.
elle peut être développée avec Motif, les MFC ou les JFC
(swing), ou encore une applet Java, un ActiveX ou une page
HTML statique ou dynamique.
5 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
La couche métier :
elle contient des composants qui réalisent les règles de
gestion du processus métier.
Exemple : pour une application bancaire, les composants
peuvent êtres des objets modélisant des comptes, des
contrats... Les objets sont écrits en C, C++, Java...
La couche données :
elle est utilisée par la couche métier pour stocker l’état des
objets métiers sur un support de persistance (SGBD
relationnel ou objet...).
La couche donnée peut changer ou évoluer indépendamment
des autres couches et réciproquement.
6 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Objectif principal de la séparation en couches :
assurer l’indépendance de la logique métier vis à vis des
problèmes de visualisation et de stockage.
⇒ Application plus modulaire, mieux structurée et plus facile à
maintenir (évolutivité).
On peut envisager des couches intermédiaires entre les
couches précédentes :
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
une couche applicative interfaçant les couches présentation
et métier (contrôleurs...),
une couche de services techniques interfaçant les couches
métier et données.
7 de 38
Plan
L’architecture client/serveur (1/2)
Architecture d’un
Middleware
La séparation physique des couches est un autre problème.
Dans une architecture 2 niveaux, deux de ces couches sont
regroupées et donc séparées de la troisième.
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Il s’agit notamment des applications client/serveur où les
traitements et l’affichage sont effectués sur le poste client
alors que les données sont stockées sur un serveur. Il s’agit
de "clients lourds" au coût élevé de déploiement.
Une autre méthode consiste à regrouper sur le serveur la
logique métier (en partie ou en totalité) et le stockage des
données.
8 de 38
Plan
L’architecture client/serveur (2/2)
Architecture d’un
Niveau 1
Niveau 2
Middleware
Le conteneur EJB
Requêtes Envoi des
requêtes
HTTP,
Fichiers,
SQL
Les EJB (Enterprise
Java Beans)
Envoi des
réponses
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Client
Serveur
9 de 38
Plan
L’architecture 3 niveaux (1/3)
Architecture d’un
Les 3 couches peuvent être complètement séparées
physiquement :
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
On peut décomposer chacune de ces couches en
sous-couches situées sur des machines ou des processus
distincts.
Il s’agit alors d’une architecture n niveaux.
C’est le cas d’une application Web :
la couche présentation est constituée de pages JSP et de
servlets,
la logique métier est implémentée dans des beans ou objets
hébergés sur un serveur d’application,
et la couche donnée consiste en une ou plusieurs bases de
données.
Intérêt de l’architecture 3 niveaux :
mieux supporter la montée en charge,
le partage des connexions aux ressources,
la facilité de déploiement, la sécurité.
10 de 38
Plan
Architecture d’un
Niveau 1
Niveau 2
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Requêtes Envoi des
requêtes
HTTP,
Fichiers,
SQL
Les beans entités
Les beans messages
Serveur de
bases de données
Interface d’EJB
SQL
Envoi des
réponses
Les beans sessions
Niveau 3 Requêtes
Client
Serveur
d’applications
11 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Le serveur devient le cœur du système.
Toute la logique de l’application est implémentée par des
composants hébergés sur ce serveur appelé serveur
d’application.
Il leur offre un environnement d’exécution, mais aussi un
ensemble de services.
La logique métier peut être assurer par plusieurs serveurs
d’applications qui communiquent ensemble. Les objets
métiers sont distribués.
Par exemple, dans une application de e-commerce la logique
nécessaire au traitement comptable est supportée par des
composants situés sur un premier serveur alors que les
composants qui gèrent la logique de gestion de stock se
trouvent sur un deuxième serveur.
12 de 38
Plan
Les Middlewares
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les objets distribués nécessitent une infrastructure technique
permettant d’assurer la communication entre ces objets.
Cette infrastructure doit fournir aux objets un accès aux
services transversaux comme les services de nommage, de
gestion des transactions, de gestion de persistance, de
gestion de sécurité...
de manière transparente pour le développeur, c’est à dire
sans qu’il ait besoin de coder des mécanismes pour assurer
ces services.
⇒ Ce type d’infrastructure est appelée Middleware.
D’autres services sont nécessaires :
optimisation des accès aux ressources (pool de
connexions...),
mécanisme d’activation/désactivation des objets,
mécanisme de répartition de charge et de tolérance aux
pannes.
13 de 38
Plan
CORBA et RMI
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
CORBA et RMI sont des Middlewares permettant de bâtir de
telles architectures mais qui posent problèmes :
La portabilité côté serveur est quasi nulle :
le développeur ne peut pas se concentrer sur le
développement des objets métiers.
le développeur doit intégrer les services fournis par le
Middleware (transactions, sécurité, persistance...) en
manipulant des API propriétaires complexes.
La gestion du cycle de vie de objets est à la charge du
développeur.
La gestion des connexions et des accès aux bases de
données, la manipulation des threads sont également à sa
charge.
Ces tâches sont toujours les mêmes, quelle que soit
l’application.
Ces tâches peuvent être automatisées et peuvent être
obtenues par déclaration plutôt que par programmation.
⇒ Les serveurs d’applications sont ainsi apparus.
14 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Malheureusement, ils n’étaient pas interopérables par
manque de standard spécifiant le Middleware à utiliser, les
services offerts, les interfaces pour y accéder...
L’architecture J2EE est un standart proposé par Sun pour les
serveurs d’applications Java.
Au cœur de cette architecture, on trouve un Middleware
standardisé, basé sur RMI/IIOP, et des objets métiers qui
sont des objets Java distribués appelés EJB (Enterprise Java
Bean).
15 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
La technologie EJB fait partie d’une plate-forme plus large
appelée J2EE.
Cette plate-forme constitue une architecture pour le
développement, le déploiement et l’exécution des
applications distribuées.
Ces applications requièrent des services techniques comme
la gestion de transactions, la gestion de la sécurité, l’accès
par les clients, l’accès aux bases de données.
La plate-forme J2EE fournit ces services techniques.
Le développeur peut se concentrer sur la logique métier au
lieu de se disperser sur des problèmes techniques.
16 de 38
Plan
Les technologies J2EE (1/3)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les technologies incluses dans J2EE, fournies sous formes d’API,
permettent :
La communication entre objets distribués avec RMI (Remote
Method Invocation) et RMI/IIOP.
La création d’objets distribués transactionnels avec des EJB
(Enterprise Java Beans).
La recherche et la récupération dans un serveur de noms des
références sur des objets distants avec JNDI (Java Naming
and Directory Interface)
L’accès aux bases de données avec JDBC (Java DataBase
Connectivity)
La gestion des transactions avec JTA (Java Transaction API)
et JTS (Java Transaction Service).
17 de 38
Plan
Architecture d’un
Elles permettent aussi :
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
La communication asynchrone par messages entre objets
distribués avec JMS (Java Message Service)
La réalisation d’interfaces graphiques Web avec les pages
JSP (JavaServer Pages) et les servlets.
L’intégration des objets CORBA avec JavaIDL.
L’envoi de courriers électroniques avec JavaMail.
Les beans entités
Les beans messages
Interface d’EJB
L’intégration des systèmes existants (CICS, progiciels) avec
les connecteurs.
La description du comportement des composants Java en
XML.
18 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
La logique métier sera implémentée dans les EJB qui sont
des composants transactionnels côté serveur et accessibles
à distance par leurs clients.
Les EJB s’exécutent dans des serveurs J2EE fonctionnant
comme des serveurs intermédiaires dans un système
client/serveur.
Deux types de conteneurs sont utilisés : le conteneur Web et
le conteneur EJB.
Le conteneur Web est un environnement d’exécution pour les
pages JSP et les servlets qui constituent une passerelle entre
l’interface utilisateur et les EJB implémentant la logique
métier.
Le conteneur EJB est un environnement d’exécution pour les
EJB. Le conteneur EJB héberge les composants métiers et
leur fournit des services.
19 de 38
Plan
Le conteneur EJB
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Du côté serveur, l’accès aux différentes ressources s’avère
complexe.
Avec les EJB, la plupart des tâches se font par déclaration,
évitant ainsi d’écrire du code spécifique pour gérer les
transactions ou la persistance.
Il s’agit de se concentrer sur le développement des
composants en déléguant au conteneur EJB l’implantation
des services techniques et la fourniture de ces services
durant l’exécution.
À un composant est associé un descripteur de déploiement,
pour signifier par exemple qu’un bean soit persistant,
sécurisé et accessible par plusieurs clients en même temps.
Le serveur est responsable du traitement de ce descripteur et
assure l’exécution de ces services.
20 de 38
Plan
Principales fonctionnalités d’un conteneur EJB (1/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les principales fonctionnalités fournies par un conteneur d’EJB
sont :
La connectivité entre les clients et les EJB :
le conteneur gère les communications entre les clients et les
EJB ;
après le déploiement d’un EJB dans un serveur
d’applications, le client peut invoquer les méthodes de cet
EJB comme si elles étaient situées dans la même machine
virtuelle ;
les communications sont assurées par le Middleware
sous-jacent de manière transparente.
La gestion de la persistance :
les composants persistants peuvent choisir de déléguer leur
persistance sur le support de persistance au conteneur.
La gestion des transactions :
les composants persistants peuvent choisir de déléguer la
gestion de leurs transactions au conteneur, qui implémente
les mécanismes transactionnels nécessaires à la réalisation
21 de 38
Plan
Principales fonctionnalités d’un conteneur EJB (2/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
La gestion de la sécurité :
politiques de sécurité déclarées mais non codées par le
développeur,
support de la sécurité basé sur l’API sécurité de Java,
méthodes liées à la sécurité implémentées par le conteneur,
utilisation des attributs de sécurité définis dans le descripteur
de bean utilisé lors de la phase de déploiement.
La gestion de la concurrence :
Les composants peuvent être invoqués par un seul client ou
par plusieurs clients simultanément.
La gestion du cycle de vie des composants :
création et la destruction des instances des composants.
La gestion du pool de connexions :
connexion à une BD = coûteuse en termes de ressources,
nombre de connexions limité par le nombre de licences,
solution : le conteneur gère un pool de connexions.
22 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un serveur d’application est un environnement complet,
comprenant le conteneur d’EJB et le serveur Web.
Pour assurer la portabilité, Sun a spécifié une suite de
compatibilité consistant en environ 6000 tests que le serveur
doit satisfaire pour obtenir la certification Sun.
Quelques serveurs d’application :
J2SDKEE : serveur de référence Sun j2sdkee
BEA WebLogic Server
IBM WebSphere
JBoss
Jonas
Sun One Application Server
Inprise Application Server
Oracle Application Server
23 de 38
Plan
Les EJB (Enterprise Java Beans) (1/3)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Le développement de logiciel a vu apparaître dans les
années 90 la notion de composant comme des morceaux de
code standards, préconstruits, réutilisables et encapsulant de
la logique métier.
Les composants EJB sont conçus pour encapsuler la logique
métier et éviter au développeur d’applications d’avoir à se
préoccuper de tout ce qui a trait au système : transaction,
sécurité, concurrence, communication, persistance, gestion
d’erreurs...
Un composant EJB est constitué d’une collection de classes
Java et d’un fichier XML, fusionnés en une entité unique.
Le conteneur prend en charge tout ce qui concerne le
système. Cette séparation des tâches est le concept
fondamental de cette technologie.
24 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un composant EJB est conçu comme un ensemble
réutilisable de logiques métiers et fonctionne avec tous les
types de clients : servlets, JSP, application Java/RMI,...
La spécification Enterprise Java Beans 1.1 définit 2 types de
beans : bean entité et bean session.
La spécification Enterprise Java Beans 2.0 introduit un
troisième bean : le bean message. Il existe donc 3 types de
beans :
les beans sessions,
les beans entités,
les beans messages.
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
EJB
|
-------------------------|
|
|
SESSION
ENTITÉ
MESSAGE
|
|
------------|
|
|
|
avec sans CMP
BMP
état état
25 de 38
26 de 38
Plan
Les beans sessions (1/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un bean session représente un processus. C’est une
extension du processus du client dans le serveur
d’applications J2EE.
On distingue 2 types de beans sessions : les beans sessions
sans état (stateless session) et les beans sessions avec état
(statefull session).
Un bean session ne peut avoir qu’un client à un moment
donné.
Pour un bean session sans état, plusieurs clients peuvent
être associés au même bean successivement.
Pour un bean session avec état, c’est le même client qui
réalise toutes les invocations.
Un bean session sans état représente un traitement
fonctionnel, comme le calcul d’un itinéraire entre 2 points ou
la demande d’un virement entre 2 comptes.
27 de 38
Plan
Les beans sessions (2/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un bean session avec état possède un état conversationnel,
c’est à dire un état résultant des interactions avec un même
client.
Exemple de bean session avec état :
un panier sur un site de commerce électronique possédant
deux attributs : un pour le nom du client et un pour les articles
sélectionnés par ce client.
Ce bean peut posséder une méthode telle que
ajouterArticle() que le client va invoquer pour ajouter un
nouvel article dans le panier.
L’état représenté par un bean session est privé et
conversationnel. Le bean est accessible par un client unique.
28 de 38
Plan
Les beans entités (1/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un bean entité représente un objet métier persistant.
Par exemple, un bean entité représente une commande, un
article, un compte bancaire.
Les attributs d’un bean entité peuvent être stockés dans une
base de données ou tout autre support de persistance. Un
bean entité peut être utilisé par plusieurs clients
simultanément.
La persistance d’un bean entité peut être gérée par le bean
lui-même ou bien par le conteneur.
Dans le premier cas, les opérations de lecture et d’écriture
sur le support de persistance doivent être codées dans le
bean (par exemple du code SQL pour une BDR).
⇒ on parle de bean BMP (Bean Managed Persistence).
29 de 38
Plan
Les beans entités (2/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Dans le second cas, la persistance est gérée par le conteneur
et seules les fonctionnalités de recherches avancées doivent
être codées dans le bean, les autres opérations de lecture et
d’écriture sur le support de persistance sont effectués
automatiquement par le conteneur.
⇒ on parle de bean CMP (Container Managed Persistence).
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
L’état représenté par un bean entité est partagé et
transactionnel. Le bean constitue le point d’accés unique à
ces données par différents clients.
30 de 38
Plan
Les beans messages
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les beans sessions et entité sont des composants distribués
invoqués par des clients de manière synchrone, c’est-à-dire
par invocation de méthodes,
Les beans messages sont des beans qui consomment des
messages de manière asynchrone, par l’intermédiaire de
Java Message Service (JMS).
31 de 38
Plan
Interface d’EJB
Architecture d’un
Middleware
Le conteneur EJB
Les composants EJB possèdent des interfaces exposant
leurs services disponibles aux clients.
Les clients utilisent ces interfaces pour exécuter la logique
encapsulée dans le bean.
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Il existent 2 sortes d’interfaces : l’interface Home (Home
Interface) et l’interface métier (Component Interface).
L’interface Home est utilisée pour créer, supprimer les
instances du bean.
L’interface métier est utilisée pour exécuter les méthodes
métiers inclues dans le bean.
32 de 38
Plan
Les objets distribués - base des EJB (1/3)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Les objets distribués sont forts utiles puisqu’ils permettent de
distribuer une application sur un réseau.
Cependant, des exigences telles que les transactions et la
sécurité deviennent indispensables dans des applications
d’entreprise.
Un objet distribué est un objet qui peut être appelé depuis un
système distant, notamment :
depuis un client faisant partie du processus contenant l’objet
(in-process),
depuis un client en dehors de ce processus (out-of-process),
ou bien depuis un client situé n’importe où sur le réseau.
33 de 38
Plan
Architecture d’un
Les modalités d’appel d’un objet distribué sont :
1
Le conteneur EJB
2
Les EJB (Enterprise
Java Beans)
Les beans entités
Les beans messages
Interface d’EJB
Le stub appelle un skeleton sur le réseau, qui est un objet
proxy côté serveur.
Le skeleton masque la communication effectuée au niveau
réseau à destination de l’objet distribué.
Le skeleton est en mesure de recevoir les appels sur une
socket et de manipuler les paramètres dans leur
représentation réseau.
Le skeleton délègue l’appel à l’objet distribué.
Les beans sessions
Le client appelle un stub, qui est un objet proxy côté client.
Le stub masque au client la communication réseau.
Le stub envoie des appels sur le réseau au moyen de sockets,
en manipulant les paramètres comme il convient dans leur
représentation réseau.
Middleware
3
L’objet distribué accomplit sa tâche et renvoie le contrôle au
skeleton, qui le renvoie à son tour au stub pour ce que ce
dernier le renvoie au client.
34 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Le stub et l’objet distribué implémentent la même interface,
appelée interface distante.
Un client qui appelle une méthode de l’objet distribué appelle
en fait une méthode du stub.
On parle de transparence locale/distante.
Différentes technologies permettent d’utiliser des objets
distribués telles que CORBA de OMG, DCOM de Microsoft et
Java RMI-IIOP de Sun.
35 de 38
Plan
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Dans une programmation d’objets distribués classique, telle que la
programmation CORBA, il existe un Middleware standard utilisé
dans le code (qui appelle l’API du Middleware).
On obtient ainsi des transactions en écrivant sur une API de
transaction.
Ce Middleware est dit explicite, puisqu’il faut écrire sur une API
pour l’obtenir.
Par exemple, un objet distribué de compte bancaire, capable de
transférer des fonds d’un compte à un autre utiliserait le code
suivant :
transfert(Compte a, Compte b, long montant){
// 1: appelle l’API Middleware pour effectuer un contrôle de sécurité
// 2: appelle l’API Middleware pour lancer une transaction
// 3: appelle l’API Middleware pour charge les lignes d’une base de données
// 4: extrait le solde d’un compte et l’ajoute à un l’autre
// 5: appelle l’API Middleware pour enregistrer les lignes dans base de données
// 6: appelle l’API Middleware pour clore la transaction
}
L’obtention des services Middleware et la logique métier sont
étroitement liés.
Cela se traduit par des difficultés d’écriture, de maintenance et de
dépendance au Middleware.
36 de 38
Plan
Middleware implicite (1/2)
Architecture d’un
L’écriture de l’objet distribué contient essentiellement la
logique métier :
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
transfert(Compte a, Compte b, long montant){
// 1: extrait le solde d’un compte et l’ajoute à un l’autre
}
La déclaration des services Middleware nécessaires
(transactions, persistance, sécurité) à l’objet distribué se fait
dans un fichier de description distinct.
Un outil associé au Middleware permet de générer un objet
"intercepteur d’appels".
Cet objet intercepte les appels clients, exécute le Middleware
nécessaire (transaction, sécurité, persistance) puis délègue
ces appels à l’objet distribué.
37 de 38
Plan
Middleware implicite (2/2)
Architecture d’un
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Un Middleware implicite (ou déclaratif) apporte une facilité
d’écriture, de maintenance et d’indépendance / support.
Dans l’architecture J2EE, c’est le conteneur EJB qui
intercepte les appels pour exécuter automatiquement les
services du Middleware et délègue à l’instance du bean.
Le conteneur agit comme une couche d’indirection entre le
code client et le bean en utilisant un intercepteur d’appels
nommé objet EJB (EJBObject).
Ces objets sont dépendants du conteneur utilisé. Le client
traite donc avec l’objet EJB et non directement avec le bean.
Il lui permet d’obtenir une référence à cet objet EJB.
Le client fait appel à une fabrique d’objets EJB. Celle-ci est
chargée d’instancier et de détruire les objets EJB. Cette
fabrique est appelée objet d’accueil ou EJBHome.
Le composant ou bean EJB est donc un composant côté
serveur entièrement géré et distribué par le conteneur.
38 de 38
Plan
Architecture d’un
Un exemple type d’application basée sur l’architecture J2EE est
celui d’une application de e-commerce :
Middleware
Le conteneur EJB
Les EJB (Enterprise
Java Beans)
Les beans sessions
Les beans entités
Les beans messages
Interface d’EJB
Le client se connecte sur le site Web d’un magasin, consulte
un catalogue des articles disponibles, en choisit certains qu’il
met dans un panier électronique et règle ses achats.
Du côté du serveur Web, les pages JSP et servlets utilisent :
des beans entités qui correspondent aux objets métiers
comme les articles, clients, commandes, factures et des
beans sessions avec état représentant les paniers des clients.
des beans sessions sans état qui peuvent implémenter des
traitements comme la navigation dans un catalogue ou la
demande d’un devis pour le contenu d’un panier.

Cours sur les Enterprise Java Beans - LITIS

Transcription

Documents pareils

Compte-Rendu sur les Enterprises Java Beans (EJB)

Développement J2EE

Jonathan Weisberg

rapport de projet

Entreprise 11 - Offre 58 - ingénieur études et

Formation perfectionnement

Chapitre 1 - Editions ENI

Stage Ingénieur Informatique Java (HF) Conception et

Intitulé du poste Ingénieur(e) en développement Java/J2ee Type

Ingénieur en Java/J2EE