Une introduction aux Enterprises Java Bean

Une introduction aux
Enterprises Java Bean
Cours très complet…
Plus de 500 transparents
Que nous allons faire d’une manière incomplète
Nous allons en regarder uniquement une 100 aines
Nombreux transparents masqués
Michel RIVEILL – Université de Nice – Sophia Antipolis
Mais visible dans version pdf par 4
http://www.polytech.unice.fr/~riveill - [email protected]
Pour nous arrêté uniquement sur les principes de
base
© 2006, M. Riveill
2
Les promesses des EJB
Motivation des EJBs
Enterprise JavaBeans
Considérons :
Standard industriel pour un modèle de composant logiciel
distribué,
un site de gestion de portefeuille boursier,
Permet d'implémenter des "objets métier" d'une manière propre et
réutilisable,
un centre d'appel,
une application bancaire,
un système d'analyse de risque,
Pour le développement RAD d'applications côté serveur
…
Fait partie des spécifications J2EE
© 2006, M. Riveill
3
© 2006, M. Riveill
4
Choses à considérer lorsqu'on
construit une application distribuée
Choses à considérer lorsqu'on
construit une application distribuée
Protocoles d'accès distants (CORBA, RMI, IIOP…)
Gestion de la charge,
Gestion des pannes,
Persistence, intégration au back-end,
Gestion des transactions,
Clustering,
Redéploiement à chaud,
Arrêt de serveurs sans interrompre l'application,
Gestion des traces, règlages (tuning and auditing),
Programmation multithread
Problèmes de nommage
Securité, performances,
Gestion des états
Cycle de vie des objets
Gestion des ressources (Resource pooling)
Requête par message (message-oriented midddleware)
Si on prend une application monolithique
Puis
on la transforme en application distribuée,
plusieurs clients se connectent sur plusieurs serveurs
Les serveurs utilisent plusieurs SGBD.
Que faut-il mettre en place ?
© 2006, M. Riveill
5
© 2006, M. Riveill
Qui s'occupe de tout ceci :
l’intergiciel (middleware) !
6
Serveur d'application : mutualiser les
compétences !
Dans le passé, la plupart des entreprises programmaient leur
propre intergiciel
Un serveur d'application fournit les services
intergiciels les plus courants,
Qui adressaient rarement tous les problèmes,
Transaction, sécurité, cycle de vie, …
Qui demandait des compétences spécifiques,
Différentes du secteur d'activité de l'entreprise (banque, commerce…)
Permettent de se focaliser sur l'application que l'on
développe, sans s'occuper du reste.
Difficulté de développement, de maintenance
Aujourd’hui, les entreprises achètent un produit
Le code est déployé sur le serveur d'application.
Oracle, IBM, BEA, …
proposent depuis plusieurs années des solutions…
Séparation des métiers et des spécificités :
Il y a aussi plusieurs proposition ‘libre’
d'un côté la logique métier,
Consortium ObjectWeb (Bull, France Telecom et l’INRIA)
de l'autre les aspects techniques.
Aujourd’hui les intergiciels intègrent : le web, l’accès aux données…
serveurs d'application.
© 2006, M. Riveill
7
© 2006, M. Riveill
8
Encore mieux ! Utilisons des
composants
Serveurs d'application : construction des
applications selon le modèle 3-parties
Il est possible d'acheter ou de réutiliser une partie de
la logique métier !
Development Tools
Presentation
HTML
Business Logic
Distributed
Objects
HTML
Transactions
Java
Content
Management
Java
Application
Vous développez votre application à l'aide de
composants.
Data Access
Code qui implémente des interfaces prédéfinies.
Sorte de boîte noire.
Un bout de logique facilement réutilisable.
Un composant n'est pas une application complète.
Juste un bout.
On assemble les composants comme un puzzle, afin de résoudre
des problèmes importants.
Et on les configure pour les adapter au problème à résoudre
Data Access
Objects
Enterprise Data
Connectors
Data
Enterprise Deployment Services
Scalability
Reliability
Security
Manageability
© 2006, M. Riveill
9
© 2006, M. Riveill
10
Composant logiciel réutilisable
Composant logiciel réutilisable
Une entreprise peut acheter un composant
Ce composant répond à un besoin récurrent
On parle alors de COTS
Vente en ligne de matériel informatique,
et l'intégrer avec des composants qu'elle a développé.
Gestion des coûts sur une chaîne de production automobile,
Par exemple, un composant qui sait gérer des prix.
Facturation interne à une entreprise,
On lui passe une liste de produits et il calcule le prix total.
Etc…
Simple en apparence,
mais la gestion des prix peut devenir très complexe :
remises,
promotions,
lots,
clients privilégiés,
règles complexes en fonction du pays,
des taxes,
etc…
© 2006, M. Riveill
11
© 2006, M. Riveill
12
Composant logiciel réutilisable
© 2006, M. Riveill
Composant logiciel réutilisable
13
© 2006, M. Riveill
Composant logiciel réutilisable
14
Quel intérêt ?
Moins d'expertise requise pour répondre à certains
points du cahier des charges,
Développement plus rapide.
Normalement, les vendeurs de composants assurent
un service de qualité (BEA, IBM…)
Réduction des frais de maintenance.
Naissance d'un marché des composants.
Pas encore l'explosion attendue mais…
© 2006, M. Riveill
15
© 2006, M. Riveill
16
Architectures de composants
Architectures de composants
Plus de 50 serveurs d'applications ont vu le jour
depuis une dizaine d'années,
Au début, composants propriétaires uniquement.
Nécessité de standardiser la notion de composants
Ensemble de définitions d'interfaces entre le serveur d'application
et les composants
Pas de cohabitation entre composants développés pour différents
serveurs d'application
Dépendant d'un fabriquant une fois le choix effectué.
Ainsi n'importe quel composant peut tourner ou être recompilé sur
n'importe quel serveur
Dur à avaler pour les développeurs java qui prônent
la portabilité et l'ouverture !
Un tel standard s'appelle une architecture de
composants
Penser aux CDs audio, à la télé, au VHS, etc…
© 2006, M. Riveill
17
© 2006, M. Riveill
Architecture à composants
18
Enterprise JavaBeans (EJB)
Qu’est-ce qui est important pour définir un
composant ?
Le standard EJB
http://java.sun.com/products/ejb/index.html
Plusieurs réponses possibles
EJB est une architecture de composants pour des
composants serveur écrits en java.
Java Beans
CCM
.Net components
Adopté par l'industrie. "Train once, code anywhere"
J2EE components
Portable facilement
Rapid Application Development (RAD)
La notion de composants est en train de dérivé vers
la notion de services
Attention : EJB != Java Beans
La aussi plusieurs réponses possible
Java beans = composants côté client
Services Web
http://java.sun.com/docs/books/tutorial/javabeans/index.html
© 2006, M. Riveill
19
© 2006, M. Riveill
20
Enterprise Java Beans
Enterprise JavaBeans
EJB signifie deux choses :
Cahier des charges
Une spécification
Rendre une application
Un ensemble d'interfaces
facile à développer, déployer et administrer
Permet la création d’applications réparties selon
l’architecture 3 parties
indépendamment de la plate-forme permettant son exécution
Favoriser la réutilisation
interface
Un EB (EnterpriseBean) n’est pas spécifique de la plate-forme dans
laquelle il est utilisé
Traitement – c’est la partie concernée par les EJB
persistance
Accélerer le déploiement
Le composant de traitement est exécuté sur un
serveur et il est appelé par un client généralement
distant
© 2006, M. Riveill
Le déploiement d’un EB se fait sans recompilation ou modification
du code source
21
© 2006, M. Riveill
22
La plate-forme Java J2EE
La plate-forme Java J2EE
Les EJB ne sont qu’une partie de la spécification J2EE
Chaque API dans J2EE à sa propre spécification
(PDF)
J2EE = architecture distribuée en java
Batterie de logiciels pour valider les implémentations
Pour le développement d'application serveur
test suites
Ensemble de spécifications et d'APIs
Implémentation de référence
Java contient deux autres architectures
1.
J2ME (Java 2 Micro Edition) : pour les mobiles
2.
J2SE : pour applications et applets standards
J2EE est livrée avec un serveur d'application qui sert d’exemple…
Ensemble de "blueprints«
Non attaché à un vendeur particulier.
Définit précisément le rôle de chaque API (PDF)
Quiconque respecte les spécification est "J2EE compliant"
Donne des conseils pour construire une application et utiliser
l’architecture
Applications développées indépendantes des vendeurs d'outils.
© 2006, M. Riveill
23
© 2006, M. Riveill
24
J2EE : les APIs
Plate-forme Enterprise Java
J2EE comprend en plus de J2ME et J2SE
EJB : standard de définition de composants
Java 2 RMI et RMI-IIOP : objets distribués
JNDI (Java Naming and Directory Interface)
JDBC (Java Data Base Connectivity)
JTA (Java Transaction API)
JMS (Java Messaging Service)
Java Servlets and Java Pages (JSP)
Java IDL (Corba)
JavaMail
JCA (J2EE Connector Architecture) : ponts vers SAP/3, CICS…
JAXP (Java API for XML Parsing)
JAAS (Java Authentification and Authorization Service)
Composants Java beans
RMI (JRMP, IIOP)
Composants Enterprise Java Beans
Plate-forme EJB
(Conteneur + Serveur)
JMS
JTA
JDBC
JNDI
...
...
Plate-forme Serveur (Unix, NT) + JVM + JDK
© 2006, M. Riveill
25
© 2006, M. Riveill
26
EJB
Caractéristiques principales
Consistent, Integrated Architecture
Development and Deployment Tools
L’architecture EJB identifie les éléments suivants :
composants logiciels ou beans (EB),
conteneurs,
Presentation
HTML
Java
Application
Business Logic
EJB
Visual Servlets
Triggers
On Demand
Java
Content
Management
JNDI
serveurs,
JDBC 2.0
Servlets/JSP
JTS/JTA
Data Access
clients.
Distributed
Data Cache
JavaMail
Les conteneurs isolent les beans du client et d’une
implémentation spécifique d’un serveur
Data Access
Objects
Enterprise Data
Connectors
RMI-IIOP
Rappel : les beans sont dans la partie serveur
Data
Conteneurs et serveurs implémentent les
mécanismes de bas niveau utilisés par les
applications
JMS
Enterprise Deployment Services
Scalability
© 2006, M. Riveill
Reliability
Security
Manageability
transactions, persistance, gestion mémoire, …
27
© 2006, M. Riveill
28
EJB
Caractéristiques principales
L’écosystème des EJBs
Mise en évidence de différents rôles
Fournisseur d’EB
EJB s’intéresse aux activités liées au développement, au
déploiement et à l’exécution d’une application
Enterprise Bean (EB)
Assembleur d’application
Application
EJB définit différents rôles associés aux différentes
parties intervenant dans la production d’une application
L’installateur
EJB définit des contrats associés à un bean
Développement
de l’application
Déploiement
et exécution
Ces contrats sont passés entre le conteneur et les clients qui utilisent le
bean.
=> ce sont des règles (obligations) qui doivent être respectées par le
Fournisseur de conteneur EJB
fournisseur de l’EB et de conteneur
Conteneu
r
Fournisseur de serveur EJB
Serveur
Développement
du serveur
EJB
Produit
Utilise
© 2006, M. Riveill
29
© 2006, M. Riveill
L'écosystème EJB
30
L'écosystème EJB
2 - L'assembleur d'application
Pour déployer et exécuter un projet à base d'EJBs,
six métiers sont impliqués
Il s'agit de l'architecte de l'application
Il est client des EJBs achetées ou développées
1 - Le fournisseur d'EJBs
Il décide de la combinaison de composants dont il a besoin
Peut-être un membre de votre équipe, ou bien une entreprise qui
vend des EJBs (www.componentsource.com ou
www.flashline.com pour voir une liste)
Fournit un GUI à l'application
Conçoit et développe de nouveau composants
Conçoit et développe les programmes clients
Définit le mapping avec les données manipulées par les différents
composants
En général, c'est un expert en Génie Logiciel, en UML et en
développement Java.
Il peut s'agir d'un intégrateur de systèmes, d'un consultant, d'une
équipe de développeurs/concepteurs maison…
© 2006, M. Riveill
31
© 2006, M. Riveill
32
L'écosystème EJB
L'écosystème EJB
3 - Le déployeur d'EJBs
4 - L'administrateur système
Après que l'application ait été assemblée, elle doit être déployée
sur un ou plusieurs serveurs d'application
Vérifie le bon fonctionnement de l'application en exploitation.
Il utilise les outils de monitoring des serveurs d'application.
Attention à la sécurité (firewall, etc…)
Il effectue la maintenance hardware et software (lancement, arrêt)
Branchement de services annexes (LDAP, Lotus Notes, Microsoft
Active Directory, etc…) sur le serveur d'applications.
du système.
Certains serveurs d'application savent téléphoner et appeler
l'administrateur système en cas de problème.
Choix du hardware, des SGBD, etc…
Paramétrage du serveur d'application, optimisation des
performances…
Ponts avec les outils de Tivoli, Computer Associates, … via
JMX.
Il adapte les composants et le serveur à l'application
Il peut être une équipe ou une personne, un consultant ou un
vendeur d'hébergement de serveurs d'applications.
Exemples aux USA : www.hostJ2EE.com ou www.loudcloud.com
© 2006, M. Riveill
33
© 2006, M. Riveill
L'écosystème EJB
34
L'écosystème EJB
5 - Le fournisseur du serveur d'application et des
containers
6 - Les vendeurs d'outils
EJB container = environnement au sein du serveur dans lequel les
EJB vivent.
Développer une application à base d'EJB est assez lourd. Pourtant
la manière de développer, construire, maintenir, déployer les EJBs
est standard.
Le container EJB fournit les services middleware et manage les
EJBs.
Il est très pratique d'utiliser un IDE pour simplifier les tâches
répétitives comme le déploiement, etc…
Exemples : Weblogic, Websphere, BES, Oracle Orion Server, JRun,
JBoss…
Principaux IDEs : JBuilder, Visual Age, Visual Cafe.
Il existe d'autre containers spécialisés (container Web comme
Tomcat, Resin…)
Outil de test (JUnit), de stress (LodeRunner), etc…
Autres outils : les outils UML comme Together/J, Rational Rose
Le fournisseur du serveur d'application est le même que le
fournisseur de containers EJB.
On confond en général container et serveur d'application.
© 2006, M. Riveill
35
© 2006, M. Riveill
36
La spécification EJB défini plusieurs
contrats
Les différents métiers…
client
Nécessaire
Bientôt un nouveau métier : le "persistence manager"
Garantir la complémentarité
Développe des outils qui se "branchent" sur le serveur
d'application et implémentent les mécanismes de persistance.
des différents métiers
Garantir la portabilité du code
Mapping BD relationnelles/Objets
Contrat
client
Fournir un modèle de
développement uniforme
pour les applications qui
utilisent les composants EB
Mapping BD objet/Objets
Etc…
Enterprise
Bean
Contrat
conteneur
EBJ conteneur
EJB serveur
Contrat
parckaging
Fichier ejb-jar
© 2006, M. Riveill
37
© 2006, M. Riveill
38
La spécification EJB défini plusieurs
contrats
Contrat coté client
EJB
Le contrat coté client
client
Un client accède toujours à un bean par son interface
fournir une vue uniforme du
bean au client.
vue est indépendante de la
plate-forme de déploiement
Localiser le bean
Contrat
client
utilisation de JNDI
Enterprise
Bean
Utiliser le bean
utilisation de l’interface standard fournie par l’EB provider
Home Interface (méthodes liées à la gestion du bean : create, remove,
finder, ...)
Contrat
conteneur
EBJ conteneur
Remote Interface (méthodes de l’application)
EJB serveur
Le container implémente le mécanisme de délégation permettant
de “faire suivre” l’appel au bean
Contrat
parckaging
le client ne communique pas directement avec le bean mais avec le
container
Fichier ejb-jar
© 2006, M. Riveill
39
© 2006, M. Riveill
40
La spécification EJB défini plusieurs
contrats
Contrat coté conteneur
EJB
Le contrat du “conteneur”
client
L’EJB conteneur permet
permettre la portabilité des
beans sur différents serveurs
EJB
gestion du cycle de vie, gestion de l’état, sécurité, transaction
distribuée, concurrence, extensibilité
Contrat
client
Enterprise
Bean
ces services appellent des méthodes fournies par le bean (callback
methods)
Contrat
conteneur
Les conteneurs gèrent plusieurs types de beans
propriétés et cycle de vie différent selon la nature du Bean
EBJ conteneur
Avec ou sans état
EJB serveur
Avec ou sans données persistantes
Contrat
parckaging
Communication par appel de méthode ou envoie de message
Fichier ejb-jar
© 2006, M. Riveill
41
© 2006, M. Riveill
La spécification EJB défini plusieurs
contrats
Contrat coté “packaging”
(ejb-jar file)
fournir un format de fichier
standard pour “packager” les
beans. Ce format doit être
Enterprise Bean
en résumé
client
Contrat
client
42
Composant serveur qui peut être déployé
Composé de un ou plusieurs objets
Les clients d'un Bean lui parlent au travers d'une
interface
Enterprise
Bean
supporter par tous les outils
Contrat
conteneur
liés aux EJB
EBJ conteneur
Cette interface, de même que le Bean, suivent la
spécification EJB
Cette spécification requiert que le Bean expose
certaines méthodes
EJB serveur
Contrat
parckaging
Fichier ejb-jar
© 2006, M. Riveill
43
© 2006, M. Riveill
44
Enterprise Bean
3 types de Beans : Session Bean
Le client d'un Bean peut être
Session Beans
Une servlet
Modélisent un traitement (business process)
Une applet
Correspondent à des verbes, à des actions
Une application classique
Ex : gestion de compte bancaire, affichage de catalogue de produit,
Un autre Bean
vérifieur de données bancaires, gestionnaire de prix…
On peut décomposer une application en un graphe de
tâches/sous-tâches
Les actions impliquent des calculs, des accès à une base de
données, consulter un service externe (appel téléphonique, etc.)
Exemple : achat d'un CD à partir du code-barre
Souvent clients d'autres Beans
Scanner (qui a une JVM embarquée) client d'un Bean sur le Serveur
Ce Bean client d'autres Beans : gestion de catalogue, de commandes, de
gestion de transaction VISA, etc…
Modèle flexible, extensible…
© 2006, M. Riveill
45
© 2006, M. Riveill
46
3 types de Beans : Message-Driven
Bean
3 types de Beans : Entity Bean
Entity beans
Message-Driven Beans
Modélisent des données
Nouveau dans EJB 2.0,
Correspondent à des noms
Similaire aux Session bean : représentent des verbes ou des
Ex : un Bean Personne, un Bean compte bancaire, un Bean produit, un
actions,
Bean commande.
On les invoque en leur envoyant des messages,
Ce sont des objets java qui cachent des données d'une base de données
Ex : message pour déclencher des transactions boursières, des
autorisations d'achat par CB,
Ils sont persistants
Servent de proxy entre la logique métier et les base de données
Souvent clients d'autres beans…
Permettent le mapping d’une base de donnée relationnelle dans un
langage à objets
Sont très souvent utilisé par des Beans Session
Rarement par un client
© 2006, M. Riveill
47
© 2006, M. Riveill
48
Exemple de Session/Entity bean
3 types de Beans : pourquoi ?
Pas d'Entity Beans dans les solutions Microsoft par
exemple…
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
Standard EJB plus difficile à apprendre,
Gestion d'achats
Commande, Produit, ligne de
commande
Risque de mauvaise utilisation mais…
DataSet est l’objet qui s’en rapproche le plus
Nombreuses compagnies impliquées dans les
standards EJB/J2EE
Leurs clients ont des besoins variés,
Solution proposée flexible mais plus complexe,
© 2006, M. Riveill
On est gagnant sur le long terme.
49
© 2006, M. Riveill
Clients interagissant avec un serveur
à base d'EJBs
© 2006, M. Riveill
50
Les objets distribués au cœur des
EJBs
51
© 2006, M. Riveill
52
Les objets distribués
et l’intergiciel (middleware)
Intergiciel explicite
Lorsqu'une application devient importante, des
besoins récurrents apparaissent : sécurité,
transactions, cycle de vie, etc…
C'est là qu'intervient l’intergiciel (middleware) !
Deux approches
Intergiciel explicite,
Intergiciel implicite
© 2006, M. Riveill
53
© 2006, M. Riveill
Intergiciel explicite
54
Intergiciel explicite
Explicite
Difficile à écrire,
C’est le composant qui appelle les services techniques
Difficile à maintenir,
Exemple :
Votre code est dépendant des API du vendeur de
middleware que vous utilisez
transfert d'un compte bancaire vers un autre
transfert(Compte c1, Compte c2, long montant)
La portabilité est loin d’être acquise
Appel vers l'API middleware qui fait une vérification de
sécurité,
Appel vers l'API de transaction pour démarrer une transaction,
Appel vers l'API pour lire des lignes dans des tables d'une BD,
Faire le calcul : enlever de l'argent d'un compte pour le mettre
dans l'autre
Appeler l'API pour mettre à jour les lignes dans les tables,
Appeler l'API de transaction pour terminer la transaction.
© 2006, M. Riveill
55
© 2006, M. Riveill
56
Intergiciel implicite
Le principe de mise en oeuvre
Interposition
Object, Home et descripteurs
© 2006, M. Riveill
57
Constitution d'un EJB : Enterprise
Bean class
Constitution d'un EJB : Enterprise
Bean class
La classe du Bean (Enterprise Bean class)
Interfaces implémentées par la classe du Bean
Une classe qui implémente une interface précise et qui respecte
certaines règles,
Tous les beans implémentent javax.ejb.EnterpriseBean
Il s'agit de l'implémentation du bean lui-même,
Important
Juste un marqueur,
Session Bean : logique métier, calculs, transfert de compte
bancaire, saisie de commandes, etc…
Cette interface dérive de Serializable
Sera utilisé pour ‘passivé’ / ‘activé’ le bean
Entity Bean : logique orientée donnée, par exemple comment
changer le nom d'un client, diminuer un compte bancaire…
Chaque type de bean implémente des interfaces plus spécifiques :
Javax.ejb.SessionBean
Message-Driven Bean : logique orientée message, traitement
après réception d'un ordre d'achat d'actions boursières…
Javax.ejb.EntityBean
Javax.ejb.MessageDrivenBean
© 2006, M. Riveill
59
© 2006, M. Riveill
60
Constitution d'un EJB : EJB Object
Constitution d'un EJB : EJB Object
Que se passe-t-il lors de l'interception ?
Les clients n'invoquent jamais directement les
méthodes de la classe du Bean
Prise en compte des transactions,
Sécurité : le client est-il autorisé ?
Les appels de méthodes (requests) sont interceptés
par le Container, afin d'assurer le traitement
middleware implicite,
Gestion des ressources + cycle de vie des composants : threads,
sockets, connexions DB, pooling des instances (mémoire),
Persistance,
Accès distant aux objets,
Une fois ce traitement effectué, le container appelle
les méthodes de la classe du Bean
Threading des clients en attente,
Activation / passivation,
Le développeur de composant se concentre sur la
logique, ignore la partie intergiciel
Clustering,
Monitoring : statistiques, graphiques temps réel du comportement
du système…
Et donc les appels aux services technique
…
© 2006, M. Riveill
61
© 2006, M. Riveill
Constitution d'un EJB : EJB Object
62
Constitution d'un EJB : EJB Object
Container = couche d'indirection entre le client et le
bean
L'EJB Object contient du code spécifique au
container (vendeur-dépendant)
Cette couche est matérialisée par un objet unique :
l'EJB Object
Il appelle les méthodes de la classe du Bean,
Il est généré par le container !
Chaque container est livré avec des outils pour
générer les EJB Object pour chaque Bean.
© 2006, M. Riveill
63
© 2006, M. Riveill
64
EJB : classe du Bean et EJB Object
EJ
EJBean
Bean
Serveur
EJB
• Utilisation du descripteur
de déploiement (fourni
par l'auteur du Bean)
• Code simple
• Génération du code à
partir du Bean
Container
EJB
EJB Object : génération du code
• Le code généré fournit
Transactions, Securité,
Persistance, Accès
Distant, Gestion des
ressources, etc.
EJB Server
EJ
EJBean
Bean
EJB Container
Container
EJB
EJ
EJBean
Bean
Serveur
EJB
Container
EJB
• Fournit les services au
container
• Paramètres de
déploiement = securité,
mappings objets/BD
relationelle, etc.)
• Génération du code pour
intégrer le bean dans le
container, ajout du
‘plumbing’ (persistance,
securité, etc…)
EJ
EJBean
Bean
Code généré
© 2006, M. Riveill
65
© 2006, M. Riveill
Constitution d'un EJB
l'interface distante
Constitution d'un EJB
l'interface distante
Les clients invoquent les méthodes des EJB Objects,
Le programmeur du Bean dérivera son interface
distante de javax.ejb.EJBObject,
Ces EJB Objects doivent cloner toutes les méthodes
que le bean expose,
Rajoutera les signatures des méthodes qu'il souhaite
exposer,
Comment l'outil qui génère l'EJB Object peut-il
connaître la liste des méthodes à cloner ?
L'EJB Object sera généré par le container !
Réponse : il utilise une interface fournie par le
programmeur du bean, l'interface distante
© 2006, M. Riveill
66
Presque rien à faire pour le développeur de bean !
67
© 2006, M. Riveill
68
Constitution d'un EJB
Home Object
Constitution d'un EJB
Home Object
Nous avons vu comment les clients appelaient les
méthodes d'un Bean : via l'EJB Object.
L'EJB factory est responsable de l'instanciation et de
la destruction des EJB Objects.
Mais comment obtiennent-ils une référence sur l'EJB
Object ?
La spécification EJB appelle cette factory un Home
Object.
En effet : pas d'instanciations lorsque on travaille
avec des objets distants !
Responsabilités du Home Object
Créer les EJB Objects,
Trouver les EJB Objects existants (Entity beans seulement)
Solution : le client demande la référence à une
fabrique d'EJB Objects (EJB Object Factory)
Supprimer les EJB Objects.
Design pattern que vous avez sûrement utilisé dans le cadre de
Java RMI
© 2006, M. Riveill
69
© 2006, M. Riveill
Constitution d'un EJB
Home Object
70
Constitution d'un EJB : l'interface
Home
Comme les EJB Objects, les Home Objects sont
générés par le container
Comme pour les EJB Objects, le développeur du
bean doit spécifier une interface Home
Contiennent du code spécifique,
L'interface Home définit
Assurent le load-balancing, etc…
Les méthodes pour créer, détruire et localiser les EJB Objects
Le Home Object (généré par le container) implémente cette
interface.
L'interface fournie par le développeur dérive de javax.ejb.EJBHome
Javax.ejb.EJBHome dérive de java.rmi.Remote
Les Home objects sont aussi des objets distants, compatibles RMIIIOP
© 2006, M. Riveill
71
© 2006, M. Riveill
72
Constitution d'un EJB
les interfaces locales
Constitution d'un EJB
Commentaires sur la figure précédente
Le client appelle un stub (souche),
Le stub encode les paramètres dans un format capable de voyager sur le
réseau,
Le stub ouvre une connexion sur le skeleton (squelette),
Le skeleton décode les paramètres,
Le skeleton appelle l'EJB Object,
L'EJB Object effectue les appels middleware,
L'EJB Object appelle la méthode 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 nécessaires !
Attention : la création de bean et l'appel de méthode distante
coûtent cher !
© 2006, M. Riveill
73
© 2006, M. Riveill
Constitution d'un EJB
les interfaces locales
Constitution d'un EJB
les interfaces locales
Pour améliorer les performances… dans le cadre
d’appels locaux
Pour l'appel distant de méthodes, le développeur peut
fournir une interface locale, qui sera implémentée par
le container en tant que Local Object
Nouveau dans EJB 2.0 : les interfaces locales.
Introduit la notion de Local Object, en remplacement
de EJB Object
A distinguer du cas "normal" (EJB 1.1) ou on a interface distante
implémentée par EJB Object
Pour la création/localisation de beans, le développeur
peut fournir une interface home interface locale, qui
sera implémentée par le container en tant que Home
Object local
Les Local Objects implémentent une interface locale
au lieu d'une interface distante
Exemple d'appel de méthode distante
Le client appelle le Local Object,
Le Local Object appelle le middleware puis la méthode du bean
A comparer avec Home Interface implémentée par le container en
tant que Home Object
La valeur de retour est renvoyée au Local Object, puis au client
© 2006, M. Riveill
74
75
© 2006, M. Riveill
76
Constitution d'un EJB
les interfaces locales
Constitution d'un EJB
les descripteurs de déploiement
Pour informer le container des besoins ‘intergiciel’,
on utilise un descripteur de déploiement (XML)
Les interfaces locales ne tournent que si les EJB sont
dans le même processus (même container),
Standardisé,
Attention, paramètres et valeurs de retour (lors des
appels de méthodes) se passent maintenant par
référence
A l'extérieur de l'implémentation du bean.
Attention si on les écrit à la main!
Toujours par valeur dans le cas d'appels distants!
Outils d'aide au déploiement : IDEs (Jbuilder, Visual Cafe), outils
spécifiques (Borland Application Server, Weblogic 6.1)
Plus performant mais sémantique différente.
Descripteurs peuvent être modifiés après le déploiement.
Descripteurs spécifiques au serveur d'application
Difficile de passer d'une implémentation locale à une
implémentation classique
Chaque vendeur ajoute des trucs en plus : load-balancing,
persistance complexe, clustering, monitoring…
Aurait pu être fait dans les descripteurs (weblogic)
© 2006, M. Riveill
Dans des fichiers spécifiques (inprise-ejb.xml avec Borland)
77
© 2006, M. Riveill
Déploiement : un fichier .jar
78
Les EJB en résumé
Enterprise Bean class
Interface distante (remote interface)/Interface locale
EJB Object/Local Object
Home interface/Local Home interface
Home Object/Local Home Object
Descripteur de déploiement standard
Descripteurs spécifiques au vendeur
Fichier .jar de l'EJB
© 2006, M. Riveill
79
© 2006, M. Riveill
80
Principaux bénéfices
Mon premier Bean…
Application complexe “facile” à écrire
gestion des transaction de manière déclarative
gestion de la persistance
gestion intégré de la sécurité
gestion de la répartition
La plate-forme et le bus logiciel (middleware) sont
indépendants des applications
Hello world… pour faire original
Extensibilité du modèle
© 2006, M. Riveill
81
Comment s'y prendre ?
Modèle objet du bean HelloWorld
Ordre typique des opérations
1.
Ecrire les fichiers .java qui composent le bean,
2.
Ecrire le descripteur du bean,
3.
Compiler les .java de l'étape 1,
4.
Créer un .jar contenant les .class et le descripteur,
5.
Deployer le .jar (via outil ou simple copie),
6.
Vérifier que le serveur fonctionne et a bien déployé le bean, sinon,
vérifier la config,
7.
© 2006, M. Riveill
Ecrire, compiler, exécuter un client de test du bean.
83
© 2006, M. Riveill
84
L'interface distante
L'interface locale
package examples;
/**
* This is the HelloBean remote interface.*
* This interface is what clients operate on when
* they interact with EJB objects. The container
* vendor will implement this interface; the
* implemented object is the EJB object, which
* delegates invocations to the actual bean.
*/
package examples;
/**
* This is the HelloBean local interface.
*
* This interface is what local clients operate
* on when they interact with EJB local objects.
* The container vendor will implement this
* interface; the implemented object is the
* EJB local object, which delegates invocations
* to the actual bean.
*/
public interface Hello extends javax.ejb.EJBObject {
/**
* The one method - hello - returns a greeting to the client.
*/
public String hello() throws java.rmi.RemoteException;
}
© 2006, M. Riveill
public interface HelloLocal extends javax.ejb.EJBLocalObject {
/**
* The one method - hello - returns a greeting to the client.
*/
public String hello();
}
85
© 2006, M. Riveill
L'interface Home
L'interface Home locale
package examples;
/**
* This is the home interface for HelloBean. This interface
* is implemented by the EJB Server's tools - the
* implemented object is called the Home Object, and serves
* as a factory for EJB Objects.
*
* One create() method is in this Home Interface, which
* corresponds to the ejbCreate() method in HelloBean.
*/
package examples;
/**
* This is the local home interface for HelloBean.
* This interface is implemented by the EJB Server's
* tools - the implemented object is called the
* local home object, and serves as a factory for
* EJB local objects.
*/
public interface HelloLocalHome extends javax.ejb.EJBLocalHome {
/*
* This method creates the EJB Object.
*
* @return The newly created EJB Object.
*/
HelloLocal create() throws javax.ejb.CreateException;
}
public interface HelloHome extends javax.ejb.EJBHome {
/*
* This method creates the EJB Object.
*
* @return The newly created EJB Object.
*/
Hello create() throws java.rmi.RemoteException,
javax.ejb.CreateException;
}
© 2006, M. Riveill
86
87
© 2006, M. Riveill
88
La classe du bean
La classe du bean
package examples;
/**
* Demonstration stateless session bean.
*/
public class HelloBean implements javax.ejb.SessionBean {
private SessionContext ctx;
//
// EJB-required methods
public void ejbCreate() { System.out.println("ejbCreate()"); }
public void ejbRemove() { System.out.println("ejbRemove()"); }
public void ejbActivate() { System.out.println("ejbActivate()"); }
public void ejbPassivate() { System.out.println("ejbPassivate()"); }
public void setSessionContext(javax.ejb.SessionContext ctx) { this.ctx = ctx;}
//
// Business methods
public String hello() {
System.out.println("hello()");
return "Hello, World!";
}
}
© 2006, M. Riveill
89
ejbCreate()
correspond au create() de l'interface Home
Une seule méthode métier : hello()
On la retrouve dans les interfaces distante et locales.
ejbActivate() et ejbPassivate() n'ont pas d'utilité dans
le cas de session bean stateless
Elles sont vides.
Etudiées plus tard.
© 2006, M. Riveill
Les EJBContexts : le lien avec le
container
90
Les EJBContexts : le lien avec le
container
Sert à encapsuler le domaine dans lequel évolue le
bean dans un objet.
Tous les contextes implémentent
public interface javax.ejb.EJBContext {
setSessionContext() appelé par le container.
/*
Un contexte par type de Bean
* Call these from within your bean to access
* your own home object or local home object.
SessionContext, EntityContext, MesageDrivenContext
*
Méthodes correspondantes
* You can use them to create, destroy, or
* find EJB objects and EJB local objects
setSessionContext(),
* of your own bean class type.
setEntityContext(),
*/
setMessageDrivenBeanContext()
public javax.ejb.EJBHome getEJBHome();
public javax.ejb.EJBLocalHome getEJBLocalHome();
…
© 2006, M. Riveill
91
© 2006, M. Riveill
92
Les EJBContexts : le lien avec le
container
Les EJBContexts : le lien avec le
container
...
/*
* These are transaction methods – sera vu plus tard ☺
*/
public boolean getRollbackOnly();
public void setRollbackOnly();
public javax.transaction.UserTransaction getUserTransaction();
/*
* These are security methods – ne sera pa vu
*/
public boolean isCallerInRole(java.lang.String);
public java.security.Principal getCallerPrincipal();
}
© 2006, M. Riveill
93
© 2006, M. Riveill
Le descripteur de déploiement
spécifique
Le descripteur de déploiement
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd">
Selon les serveurs d'application, il peut y avoir un
descripteur en plus, spécifique.
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>Hello</ejb-name>
<home>examples.HelloHome</home>
<remote>examples.Hello</remote>
<local-home>examples.HelloLocalHome</local-home>
<local>examples.HelloLocal</local>
<ejb-class>examples.HelloBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
© 2006, M. Riveill
94
Voir pendant les exercices…
Nous allons utiliser Jonas
Et il y a un container spécifique
95
© 2006, M. Riveill
96
Le fichier .jar de l'EJB
Déployer le bean
Il faut mettre tous les fichiers compilés
Cette étape varie selon le container
+ descripteurs
Simple copie dans un répertoire spécifique avec JBoss,
dans un .jar
A l'aide d'un outil de déploiement spécifique avec Jonas
A faire depuis un IDE ou à la main
Lors du déploiement
jar cf HelloWorld.jar *
Vérification du fichier.jar,
Contenu de HelloWorld.jar
Le container génère les EJBObjects et EJBHome,
META-INF/MANIFEST.MF
Le container génère les stubs et skeletons pour les appels RMIIIOP.
META-INF/ejb-jar.xml
examples/HelloBean.class
Vérifier le déploiement
examples/HelloLocalHome.class
examples/HelloHome.class
Le serveur doit vous avertir qu'il a bien chargé le bean.
examples/HelloLocal.class
examples/Hello.class
© 2006, M. Riveill
97
© 2006, M. Riveill
98
Client : localiser (lookup) un objet
Home,
Écriture d'un client
Deux types de clients
On ne sait pas où se trouve l'objet…
Clients JAVA RMI-IIOP : ils utilisent JNDI pour localiser les objets
et Java Transaction API pour contrôler les transactions.
Utilisation de JNDI
JNDI sert à lier des ressources sur des noms logiques :
utilisateurs, services, imprimantes, EJB, Datasource (base de
données)…
Clients CORBA : par exemple écrits en C++… Ils utilisent COS
Naming Service et Object Transaction Service (OTS) pour les
transactions…
JNDI est un pont vers des services d’annuaire tels que LDAP,
Microsoft Active Directory, Lotus Notes Domino Server, iPlanet
Directory Server…
Quel que soit le client
Localiser (lookup) un objet Home,
JNDI permet de rendre transparente la localisation
des objets…
Utiliser cet objet Home pour créer (create) un EJBObject,
Appeler les méthodes de l'EJBObject,
Supprimer (remove) l'EJBObject.
© 2006, M. Riveill
99
© 2006, M. Riveill
100
Client : les étapes en images
Client : le code
package examples;
import javax.naming.Context;
import javax.naming.InitialContext;
import java.util.Properties;
/**
* This class is an example of client code which invokes
* methods on a simple stateless session bean.
*/
public class HelloClient {
public static void main(String[] args) throws Exception {
/* Setup properties for JNDI initialization.
* These properties will be read-in from
* the command-line. */
Properties props = System.getProperties();
…
© 2006, M. Riveill
101
© 2006, M. Riveill
Client : le code
102
Client : le code
...
/* Get a reference to the home object - the
* factory for Hello EJB Objects */
Object obj = ctx.lookup("HelloHome");
/* Home objects are RMI-IIOP objects, and so
* they must be cast into RMI-IIOP objects
* using a special RMI-IIOP cast.
* See Appendix X for more details on this. */
HelloHome home = (HelloHome)
javax.rmi.PortableRemoteObject.narrow(obj, HelloHome.class);
/* Use the factory to create the Hello EJB Object */
Hello hello = home.create();
/* Call the hello() method on the EJB object. The
* EJB object will delegate the call to the bean,
* receive the result, and return it to us.
* We then print the result to the screen. */
System.out.println(hello.hello());
/* Done with EJB Object, so remove it.
* The container will destroy the EJB object. */
hello.remove();
…
/* Obtain the JNDI initial context.
* The initial context is a starting point for
* connecting to a JNDI tree. We choose our JNDI
* driver, the network location of the server, etc
* by passing in the environment properties. */
Context ctx = new InitialContext(props);
…
}
}
© 2006, M. Riveill
103
© 2006, M. Riveill
104
Exécution du client de test
Introduction aux Session Beans
Place aux exercices !!!!
A faire en TP lors de la première séance pour vérifier que vous avez
bien compris
Tiens, une question
que représente le mot-clé this pour un EJB ?
© 2006, M. Riveill
105
Session Bean : rappel
Durée de vie d'un Session Bean
Durée de vie = la session
Un Session Bean représente
En gros, le temps qu'un client reste connecté sur le bean.
une action, un verbe,
Dans une logique e-commerce, le temps qu'un utilisateur est connecté sur
une logique métier, un algorithme,
le site.
Un enchaînement de tâches…
Le container crée une instance lorsqu'un client se connecte sur
le Session Bean.
Exemples
© 2006, M. Riveill
Saisie d'une commande,
Il peut le détruire lorsque le client se déconnecte.
Compression vidéo,
Les Session Beans ne résistent pas à des crashes du serveur.
Gestion d'un caddy, d'un catalogue de produits,
Ce sont des objets en mémoire, non persistants.
Transactions bancaires…
Le contraire des Entity Beans que nous verrons plus tard.
107
© 2006, M. Riveill
108
Types de Session Beans
Stateful Session Beans
Chaque EJB a un moment donné entretient une
conversation avec un client.
Certaines conversations se déroulent sous forment
de requêtes successives.
Conversation = suites d'appels de méthodes.
Exemple : un client surfe sur un site de e-commerce, sélectionne
des produits, remplit son caddy…
Il existe deux types de Session Beans
1.
Stateful Session Beans,
2.
Stateless Session Beans.
D'une requête HTTP à l'autre, il faut un moyen de
conserver un état (le caddy par ex.)
Autre exemple : une application bancaire. Le client effectue
plusieurs opérations. On en va pas à chaque fois lui redemander
son No de compte…
Chacun modélisant un type particulier de
conversation.
© 2006, M. Riveill
109
© 2006, M. Riveill
110
Stateful Session Beans
Stateless Session Beans
Certaines conversations peuvent se résumer à un appel de
méthode, sans besoin de connaître l'état courant du Bean
En résumé, un Stateful Session Bean est utile pour
maintenir un état pendant la durée de vie du client
Ex : simple traitement, simple calcul (validation de No de CB),
au cours d'appels de méthodes successifs.
compression…
Au cours de transactions successives.
Le client passe toutes les données nécessaires au traitement lors de l'appel
Si un appel de méthode change l'état du Bean, lors d'un autre
de méthode.
appel de méthode l'état sera disponible.
Le container est responsable de la création et de la destruction
du Bean
Conséquence : une instance de Stateful Session
Bean par client.
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.
Avec certains containers, les Stateful Session Beans
peuvent être persistants (BAS/BES…) par
sérialisation.
© 2006, M. Riveill
Conséquence : une instance de Stateless Session Bean n'est
pas propre à un client donné, elle peut être partagée entre
chaque appel de méthode.
111
© 2006, M. Riveill
112
Pooling de Stateless Session Beans
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…
© 2006, M. Riveill
113
© 2006, M. Riveill
114
Pooling des Stateful Session Beans
Pooling des Stateful Session Beans
Avec un OS : on utilise le concept de mémoire
virtuelle…
Avec les Stateful Session Beans on fait pareil !
Entre chaque appel de méthode, un client ne fait rien (Idle),
Un utilisateur d'un site de e-commerce lit les infos sur la page
Lorsqu'un processus ne fait plus rien (Idle), on
swappe son état mémoire sur disque dur, libérant de
la place.
www, réfléchit… de temps en temps il clique sur un bouton…
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.
Lorsqu'on a de nouveau besoin de ce processus, on
fait l'inverse.
Etc…
Ceci arrive souvent lorsqu'on passe d'une application
à l'autre…
© 2006, M. Riveill
115
© 2006, M. Riveill
116
En quoi consiste l'état d'un Bean
Stateful?
Pooling des Stateful Session Beans
Ceci a un coût :
L'état conversationnel d'un bean suit les règles de la
sérialisation d'objets en java.
l'activation/passivation génère des E/S
En effet, la passivation (swap de la mémoire d’exécution vers la
mémoire de stockage - disque) et l'activation (l'inverse) sont
réalisées par sérialisation.
Choix du bean à swapper par LRU le plus souvent
(Least Recent Used)
Choix du bean à activer : lorsqu'on le demande
Rappelez-vous que javax.ejb.EnterpriseBean
implémente java.io.Serializable
(just in time)
Tous les attributs du Bean non transients sont donc
concernés.
© 2006, M. Riveill
117
© 2006, M. Riveill
En quoi consiste l'état d'un Bean
Stateful?
118
Passivation d'un Stateful Session
Bean
Sont concernées également tous les attributs issus
du container
Références vers EJBObject, EJBHome, EJBContext, contextes
JNDI…
© 2006, M. Riveill
119
© 2006, M. Riveill
120
Activation d'un Stateful Session
Bean
Activation/Passivation callbacks
Lorsqu'un bean va être mis en passivation
le container l'avertit en appelant sa méthode
ejbPassivate()
Il peut libérer des ressources (connexions…)
Idem lorsque le bean vient d'être activé,
le container appelle
ejbActivate()
© 2006, M. Riveill
121
© 2006, M. Riveill
Cycle de vie d'un Session Bean
stateless
© 2006, M. Riveill
122
Cycle de vie d'un Session Bean
stateful
123
© 2006, M. Riveill
124
Count : l'interface distante
Un exemple de statefull session bean
package examples;
import javax.ejb.*;
import java.rmi.RemoteException;
/**
* These are CountBean ’s business logic methods.
*
* This interface is what clients operate on when they
* interact with EJB objects.The container vendor will
* implement this interface;the implemented object is
* the EJB object,which delegates invocations to the
* actual bean.
*/
public interface Count extends EJBObject {
/**
* Increments the int stored as conversational state
*/
public int count()throws RemoteException;
}
© 2006, M. Riveill
CountBean : la classe du bean
CountBean : la classe du bean
/** Counts up */
public int count(){
System.out.println("count()");
return ++val;
}
//
// EJB-required methods
//
public void ejbCreate(int val)throws CreateException {
this.val =val;
System.out.println("ejbCreate()");
}
public void ejbRemove(){
System.out.println("ejbRemove()");
}
public void ejbActivate(){
System.out.println("ejbActivate()");
}
public void ejbPassivate(){
System.out.println("ejbPassivate()");
}
public void setSessionContext(SessionContext ctx){
}
package examples;
import javax.ejb.*;
/**
* Demonstration Stateful Session Bean.This Bean is initialized
* to some integer value,and has a business method which
* increments the value.
*
* This example shows the basics of how to write a stateful
* session bean,and how passivation/activation works.
*/
public class CountBean implements SessionBean {
// The current counter is our conversational state.
public int val;
//
//Business methods
//
© 2006, M. Riveill
126
127
© 2006, M. Riveill
}
128
CountBean : la classe du bean
CountHome : l'interface Home
Val est serializable, représente l'état du bean
Le bean est stateful mais ce n'est précisé nulle part
dans le code.
setSessionContext(SessionContext)
Appelé par le container,
L'objet SessionContext implémente
public interface javax.ejb.SessionContext extends javax.ejb.EJBContext {
public javax.ejb.EJBLocalObject getEJBLocalObject();
public javax.ejb.EJBObject getEJBObject();
}
Ces deux méthodes permettent de récupérer une référence sur
l'EJBObject associé au Bean, remplace le this pour les EJB !
© 2006, M. Riveill
129
package examples;
import javax.ejb.*;
import java.rmi.RemoteException;
/**
* This is the home interface for CountBean. This interface
* is implemented by the EJB Server’s glue-code tools - the
* implemented object is called the Home Object, and serves
* as a factory for EJB Objects.
*
* One create() method is in this Home Interface, which
* corresponds to the ejbCreate() method in the CountBean file.
*/
public interface CountHome extends EJBHome {
/*
* This method creates the EJB Object.
* @param val Value to initialize counter to
* @return The newly created EJB Object.
*/
Count create(int val) throws RemoteException, CreateException;
}
© 2006, M. Riveill
ejb-jar.xml : descripteur de
déploiement
130
Descripteur de déploiement
propriétaire
<!DOCTYPE ejb-jar PUBLIC
Rien de spécial à signaler…
"-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
Truc intéressant à faire : indiquer au container que
l'on ne désire pas plus de deux instances de l'EJB
dans le pool.
"http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>Count</ejb-name>
Si on crée trois Beans, ça va obliger le container à mettre en œuvre
le pooling, à swapper l'état d'une instance lors des requêtes…
<home>examples.CountHome</home>
<remote>examples.Count</remote>
<ejb-class>examples.CountBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
© 2006, M. Riveill
131
© 2006, M. Riveill
132
Client de l'EJB
Client de l'EJB
package examples;
import javax.ejb.*;
import javax.naming.*;
import java.util.Properties;
/** This class is a simple example of client code.
* We create 3 EJB Objects in this example, but we only allow
* the container to have 2 in memory. This illustrates how
* beans are passivated to storage. */
public class CountClient {
public static void main(String[] args) {
try {
/* Get System properties for JNDI initialization */
Properties props = System.getProperties();
/* Get a reference to the Home Object - the
* factory for EJB Objects */
Context ctx = new InitialContext(props);
CountHome home = (CountHome)
javax.rmi.PortableRemoteObject.narrow(
ctx.lookup("CountHome"),
CountHome.class);
/* An array to hold 3 Count EJB Objects */
Count count[] = new Count[3];
int countVal = 0;
/* Create and count() on each member of array */
System.out.println("Instantiating beans . . . ");
for (int i=0; i < 3; i++) {
/* Create an EJB Object and initialize it
* to the current count value */
count[i] = home.create(countVal);
/* Add 1 and print */
countVal = count[i].count();
System.out.println(countVal);
/* Sleep for 1/2 second */
Thread.sleep(500);
} // try
...
© 2006, M. Riveill
133
© 2006, M. Riveill
Exécution du client, déploiement du
Bea,n
Client de l'EJB
Sortie client
/* Let’s call count() on each EJB Object to
* make sure the beans were passivated and
* activated properly. */
System.out.println("Calling count() on beans . . . ");
for (int i=0; i < 3; i++) {
/* Add 1 and print */
countVal = count[i].count();
System.out.println(countVal);
/* Sleep for 1/2 second */
Thread.sleep(500);
} // for
/* Done with EJB Objects, so remove them */
for (int i=0; i < 3; i++) {
count[i].remove();
}
} catch (Exception e) {
e.printStackTrace();
} // try
} // main
Instantiating beans . . .
1
2
3
Calling count() on beans . . .
2
3
4
}
© 2006, M. Riveill
134
135
© 2006, M. Riveill
Sortie serveur
ejbCreate()
count()
ejbCreate()
count()
ejbCreate()
ejbPassivate()
count()
ejbPassivate()
ejbActivate()
count()
ejbPassivate()
ejbActivate()
count()
ejbPassivate()
ejbActivate()
count()
ejbPassivate()
ejbActivate()
ejbRemove()
ejbActivate()
ejbRemove()
…
136
Introduction aux Entity Beans