Intro à EJB Fichier

Informatique Repartie
Chapitre 5 : Web Services – REST (III)
Cecilia Zanni‐Merk
cecilia.zanni‐merk@insa‐rouen.fr
Bureau BO B R1 04
Références
• Le cours de M Pauchet sur Moodle
• Architectures réparties en Java Annick Fron
ISBN 9782100738700. Editions Dunod
• Java EE. Guide de développement d'applications web en Java
Jérôme Lafosse
Livre numérique. Editions ENI
2
Références et cours sur le Web
• The Java EE 6 tutorial
http://docs.oracle.com/javaee/6/tutorial/doc/index.html
• Cours Sun http://miageprojet2.unice.fr/@api/deki/files/99/=FY09TechDays_RES
T_Carol_(1).odp
• Cours M. Baron http://mbaron.developpez.com/soa/jaxrs/
• JAX‐RS 2.0 https://jax‐rs‐spec.java.net/
3
Les clients REST
4
Les clients REST
• Comme évoqué précédemment, plusieurs implémentations de la spécification JAX‐RS existent : JERSEY (Oracle, référence), CXF (Apache), RESTEasy (JBoss/WildFly), RESTlet
• La spécification ne décrit que la partie serveur, la partie client dépend de chaque implémentation
• En conséquence, il y a plusieurs possibilités pour développer un client pour consommer des services REST
•
•
•
•
Avec JERSEY Avec Java.net.URL ( déjà discuté)
Avec Apache HttpClient
Avec le framework pour les clients proposé par RESTeasy
5
Le framework RESTeasy
• http://resteasy.jboss.org/
• https://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/RESTEasy_Client
_Framework.html
• Attention : le classpath des clients doit contenir
•
•
•
•
•
•
•
•
commons‐io‐2.3.jar
commons‐logging‐1.1.1.jar
httpclient‐4.2.3.jar
httpcore‐4.2.3.jar
jaxrs‐api‐3.0.9.Final.jar
resteasy‐client‐3.0.9.Final.jar
resteasy‐jaxb‐provider‐3.0.9.Final.jar
resteasy‐jaxrs‐3.0.9.Final.jar
6
Clients de test pour la boutique
• ClientGet : Effectue une requête http sur l’URL du premier visiteur
7
Clients de test pour la boutique
• ClientGet : Effectue une requête http sur l’URL du premier visiteur
7
Clients de test pour la boutique
• ClientPost : pour créer un nouvel enregistrement
8
Clients de test pour la boutique
• ClientPost : pour créer un nouvel enregistrement
8
Clients de test pour la boutique
• ClientPut : va nous permettre de modifier le courriel de Lara avec PUT
9
Clients de test pour la boutique
• ClientPut : va nous permettre de modifier le courriel de Lara avec PUT
9
Clients de test pour la boutique
• ClientDelete : Va nous permettre de supprimer le client 2
10
Clients de test pour la boutique
• ClientDelete : Va nous permettre de supprimer le client 2
10
Clients de test pour la boutique
• ClientGetAll : pour nous permettre de lister tous les visiteurs
11
Clients de test pour la boutique
• ClientGetAll : pour nous permettre de lister tous les visiteurs
11
Informatique Repartie
Chapitre 6 : Introduction à EJB
Cecilia Zanni‐Merk
cecilia.zanni‐merk@insa‐rouen.fr
Bureau BO B R1 04
Références
• Le cours de M Pauchet sur Moodle
• Java EE. Guide de développement d'applications web en Java
Jérôme Lafosse
Livre numérique. Editions ENI
• Le cours « Les Enterprise Java Beans » de Jean‐Marc Farinone (CNAM Paris)
13
Références et cours sur le Web
• The Java EE 6 tutorial, ORACLE
http://docs.oracle.com/javaee/6/tutorial/doc/index.html
• Java EE programming, WIKIBOOKS
https://en.wikibooks.org/wiki/Java_EE_Programming
• Java Persistence, WIKIBOOKS
http://en.wikibooks.org/wiki/Java_Persistence
14
Un peu d’histoire sur les architectures (rappel)
• Années 70 : architectures Mainframe (1 tier)
• Années 80 : architectures 2 tiers (BD)
• Fin des années 80 : architectures 3 tiers (RPC)
• Années 90 : architectures 3 tiers Objet (RMI/Corba)
• Années 00 : architectures orientées services (Web Services)
• Fin des années 00 : architectures orientées ressources (RESTful)
15
Un peu d’histoire sur les aspects programmation
• Années 70‐80 : Programmation procédurale
• alors que les premiers langages objets datent de la fin des années 60 !
• Années 90 : Programmation objet
• Fin des années 90 : Programmation orientée composants
• Les composants peuvent être physiquement distants
• Si changement, pas besoin de tout recompiler et de tout relinker
• Similaire à la POO, car on utilise une approche objet, pas au sein du code, mais au niveau de l’architecture générale du logiciel
16
J2EE • Cadre de développement par composants avec services proposé par SUN
• J2EE (Java 2 Edition Enterprise), qui propose des API pour :
•
•
•
•
•
•
•
•
•
•
•
L'invocation de méthodes distantes : RMI, CORBA, Web Services
L'accès aux bases de données relationnelles : JDBC
L'accès aux annuaires et services de nommage : JNDI
La sérialisation par XML : JAXB
HTML dynamique et traitement de requêtes HTTP : JSP et Servlet
La gestion du Mail : JavaMail
La gestion des composants distribués transactionnels: EJB
La gestion des messages entre composants : Java Message Service (JMS)
La gestion des droits d'accès : Java Authentication and Authorization
Gestion de la persistence de données : JPA
… entre autres
17
Architecture
18
Les composants Java EE
• Sont des unités de software auto‐contenues intégrées dans une application Java EE • Les applications clients et les applets sont des composants qui s’exécutent du côte client
• Les composants qui utilisent les technologies Java Servlet, JavaServer Faces et JSP (JavaServer Pages) sont des composants web qui s’exécutent du côte serveur
• Les Enterprise JavaBeans (EJB) sont des composants métier qui s’exécutent du côte serveur 19
J2EE et les conteneurs Web (rappels)
• La spécification J2EE fournit les éléments suivants pour la conception et la réalisation d'application Web :
• Servlets Java et JSP. • Les servlets et JSP constituent les blocs de construction du développement d'applications web avec J2EE
• En terme J2EE, les servlets et pages JSP sont des composants web
• Application web
• Collection de servlets et de pages JSP, d'autres classes annexes ou de bibliothèques de classes, ainsi que des ressources statiques telles que des documents HTML, XHTML ou XML, images, etc.
20
J2EE et les conteneurs Web (rappels)
• Eléments de la spécification J2EE (suite) :
• Conteneur web
• Essentiellement un environnement d'exécution Java pour les applications web
• Responsable de l'initialisation, de l'invocation et de la gestion de la durée de vie des servlets Java et des pages JSP
• Structure de paquetage et descripteur de déploiement
• Le descripteur de déploiement est un fichier XML
21
J2EE et les conteneurs Web (rappels)
• Quelques examples open source
• Tomcat (Apache)
• http://www.apache.org
• GlassFish (Oracle)
• https://glassfish.java.net/
• Jboss Application Server (maintenant WildFly) (Red Hat Inc)
• http://wildfly.org/
• Jetty (Eclipse)
• http://www.eclipse.org/jetty/
22
Les Enterprise Beans
• Les Enterprise Beans sont des composants Java EE qui implémentent la technologie Enterprise JavaBeans (EJB)
• Les Enterprise Beans s’exécutent dans un conteneur EJB
• Un conteneur EJB fournit tous les services au niveau système, de manière transparente pour le développeur
•
•
•
•
Transactions
Sécurité
Persistence
Cycle de vie
• Les Enterprise Beans sont le coeur des applications transactionnelles
Java EE 23
Les Enterprise Beans
• Les Enterprise Beans sont des composants Java EE qui implémentent la technologie Enterprise JavaBeans (EJB)
• Les Enterprise Beans s’exécutent dans un conteneur EJB
• Un conteneur EJB fournit tous les services au niveau système, de manière transparente pour le développeur
•
•
•
•
Transactions
Sécurité
Persistence
Cycle de vie
• Les Enterprise Beans sont le coeur des applications transactionnelles
Java EE 23
Les Enterprise Beans
• Les Enterprise Beans encapsulent la logique métier de l’application.
• Ils simplifient le développement des grandes applications distribuées
• Comme le conteneur EJB fournit les services au niveau du système, le développeur du bean se concentre sur la résolution des problèmes métier
• Comme les beans contiennent la logique métier, les clients sont légers
• Comme les beans sont des composants portables, ils peuvent être réutilisés pour d’autres applications
• Les beans s’avèrent utiles quand l’application doit être scalable, quand on doit assurer l’intégrité des données ou quand l’application a une diversité de clients
24
Les services des conteneurs EJB
• Persistance. Possibilité pour l'EJB d‘être persistant dans une BD
• Transactions déclaratives. Possibilité de gérer des transactions complexes (sans utiliser des API spécifiques)
• Mémoire cache. Possibilité d'améliorer les performances
• Sécurité déclarative. Possibilité de gérer l'accès aux composants
• Gestion d'erreurs. La spécification EJB définit la manière dont les erreurs affectent les transactions, les résultats au niveau client, la connexion et la restauration des composants
• Portabilité. EJB = Spécification = possibilité de porter un EJB sur un autre serveur plus puissant
25
Les services des conteneurs EJB
• Persistance. Possibilité pour l'EJB d‘être persistant dans une BD
• Transactions déclaratives. Possibilité de gérer des transactions complexes (sans utiliser des API spécifiques)
• Mémoire cache. Possibilité d'améliorer les performances
• Sécurité déclarative. Possibilité de gérer l'accès aux composants
• Gestion d'erreurs. La spécification EJB définit la manière dont les Sans écrire une seule erreurs affectent les transactions, les résultats au niveau client, la connexion et la restauration des composantsligne de code
• Portabilité. EJB = Spécification = possibilité de porter un EJB sur un autre serveur plus puissant
25
Comment le conteneur fournit‐il ces services?
• 3 concepts de bases pour les EJB
• Le concept de contrat
• Services orthogonaux aux EJB
• Interposition du conteneur entre le client et l'EJB
• Contrat
• Répartition des responsabilités entre chaque couche du logiciel (Client, Conteneur, EJB, Gestionnaire de persistance (dans la version 2.0))
• Services orthogonaux
• Le conteneur EJB fournit des services au programmeur
• Le programmeur de l'EJB n'a plus qu'a respecter les règles pour exploiter automatiquement ces services
• Ces règles sont spécifiées dans le descripteur de déploiement
26
Comment le conteneur fournit‐il ces services?
• Interposition
1.
2.
3.
4.
5.
6.
7.
Le client exécute un appel sur un Stub RMI
Ce stub RMI assemble et envoie des informations au serveur
Le skeleton désassemble les paramètres et les transmets au conteneur EJB
Le conteneur examine les références de sécurité de l'appelant de la méthode
Le conteneur démarre ou rejoint toute transaction nécessaire
Le conteneur exécute tous les appels nécessaires aux fonctions de persistance
Le conteneur déclenche diverses méthodes callback pour permettre au composant EJB d'acquérir des ressources
8. La méthode « logique métier » est appelée
9. Le conteneur exécute quelques autres taches relatives aux transactions, à la persistance, aux méthodes callback
10. Le conteneur renvoie le résultat de la méthode métier ou une exception au client
27
Comment le conteneur fournit‐il ces services?
• Interposition
1.
2.
3.
4.
5.
6.
7.
Le client exécute un appel sur un Stub RMI
Ce stub RMI assemble et envoie des informations au serveur
Le skeleton désassemble les paramètres et les transmets au conteneur EJB
Le conteneur examine les références de sécurité de l'appelant de la méthode
Le conteneur démarre ou rejoint toute transaction nécessaire
Le conteneur exécute tous les appels nécessaires aux fonctions de persistance
Le conteneur déclenche diverses méthodes callback pour permettre au composant EJB d'acquérir des ressources
8. La méthode « logique métier » est appelée
9. Le conteneur exécute quelques autres taches relatives aux transactions, à la persistance, aux méthodes callback
10. Le conteneur renvoie le résultat de la méthode métier ou une exception au client
27
Les clients qui utilisent les beans …
• Doivent
• localiser le Bean par JNDI (Java Naming and Directory Interface)
• utiliser le Bean
• via la Home Interface : méthodes liées au cycle de vie du bean : create(), remove(), …
• via la Remote Interface : services métiers par le bean
• Le conteneur implémente le mécanisme de délégation permettant de faire suivre l’appel au bean
28
L’architecture d’utilisation d’un bean
• Les clients d'un Bean lui parlent au travers d'interfaces
• Ces interfaces, de même que le Bean, suivent la spécification EJB
• Cette spécification requiert que le Bean expose certaines méthodes
• En général (pour les beans de type Session et Entity, voir la section suivante), le bean doit proposer une interface de création (Home) et une interface d’utilisation (Remote)
29
L’architecture d’utilisation d’un bean
• Les clients d'un Bean lui parlent au travers d'interfaces
• Ces interfaces, de même que le Bean, suivent la spécification EJB
• Cette spécification requiert que le Bean expose certaines méthodes
• En général (pour les beans de type Session et Entity, voir la section suivante), le bean doit proposer une interface de création (Home) et une interface d’utilisation (Remote)
29
L’architecture d’utilisation d’un bean
• Plus éventuellement 2 interfaces d’accès local, pour lier deux clients partageant la même machine virtuelle
30
L’architecture d’utilisation d’un bean
• Plus éventuellement 2 interfaces d’accès local, pour lier deux clients partageant la même machine virtuelle
30
Récapitulatif : Local vs Remote
• Pour spécifier la manière d’accéder a l’EJB => l’implémentation des services est identique
• Interface Local
• ≠ appel a un EJB se trouvant sur la même machine
• = appel a un EJB se trouvant dans la même JVM
• Interface Remote
• utilise RMI (Remote Method Invocation) (=> plus lent qu’un appel local) et JNDI (Java Naming and Directory Interface)
• utilisé dans la majorité des cas
31
Processus de développement
• Développement d’un bean
•
•
•
•
Ecrire la Home interface
Ecrire la Remote interface
Ecrire l’implémentation (classe) du bean
Compiler ces classes et interfaces
• Déploiement du Bean
• Construire le descripteur de déploiement
• Construire le fichier d’archive .jar ou .ear
• Utilisation du Bean
• Ecrire, compiler et exécuter le client, qui peut être une servlet ou une application Java ou une applet, etc.
32
Processus de développement
• Développement d’un bean
•
•
•
•
Ecrire la Home interface
Ecrire la Remote interface
Ecrire l’implémentation (classe) du bean
Compiler ces classes et interfaces
• Déploiement du Bean
• Construire le descripteur de déploiement
• Construire le fichier d’archive .jar ou .ear
• Utilisation du Bean
• Ecrire, compiler et exécuter le client, qui peut être une servlet ou une application Java ou une applet, etc.
32
Types d’EJB
33
Trois types d’Enterprise Beans
• EJB Session
• stateless
• stateful
• EJB Entity
• CMP (Container Managed Persistence)
• BMP (Bean Managed Persistence)
• EJB Message Driven
34
Les EJB Session
• Réalisent une tâche pour un client, optionnellement peuvent implémenter un web service
• Modélisent une suite d’interactions avec les données
• En général c’est par ces beans que commence la première connexion. Puis les beans session accèdent aux entity beans
• Si le service proposé est un ajout fonctionnel au client, définir un EJB Session stateless (sans état)
• Exemple : un convertisseur de monnaies
• Un tel EJB est partageable consécutivement par de multiples clients
• Si l’interaction doit être suivie, on utilise un EJB session stateful (avec état)
• Exemple : un panier de commandes
• Un tel EJB est propre à un client pendant toute la durée de la session
• Il gère une conversation avec un client
35
Les EJB Session
• Réalisent une tâche pour un client, optionnellement peuvent implémenter un web service
• Modélisent une suite d’interactions avec les données
• En général c’est par ces beans que commence la première connexion. Puis les beans session accèdent aux entity beans
Seuls EJB interfaçables
• Si le service proposé est un ajout fonctionnel au client, définir un EJB Session stateless (sans état)
par les clients
• Exemple : un convertisseur de monnaies
• Un tel EJB est partageable consécutivement par de multiples clients
• Si l’interaction doit être suivie, on utilise un EJB session stateful (avec état)
• Exemple : un panier de commandes
• Un tel EJB est propre à un client pendant toute la durée de la session
• Il gère une conversation avec un client
35
Les EJB stateless
• Les attributs de l’EJB sont réinitialisées entre chaque appel même s’il s’agit du même client
• Sont spécialement pensés pour être robustes et fiables lorsqu’il y a beaucoup d’appels en concurrence
• Lorsqu’un client appelle l’EJB, une instance de ce dernier sert le client, puis, retourne dans le pool d’EJB (cette dernière est donc prête a être réutilisée pour un autre client)
36
Les EJB stateless
• Les attributs de l’EJB sont réinitialisées entre chaque appel même s’il s’agit du même client
• Sont spécialement pensés pour être robustes et fiables lorsqu’il y a beaucoup d’appels en concurrence
• Lorsqu’un client appelle l’EJB, une instance de ce dernier sert le client, puis, retourne dans le pool d’EJB (cette dernière est donc prête a être réutilisée pour un autre client)
36
Les EJB Session stateful
• Les attributs de l’EJB sont sauvegardes durant toute la session
• Lorsqu’un client appelle l’EJB, une instance de ce dernier est créée, puis sert le client. Cette instance reste disponible pour les futurs appels de ce client uniquement. • Cette instance sera détruite a la fin de la session (timeout ou appel a une méthode portant l’annotation @Remove)
• S’il y a trop d’instances d’un EJB en mémoire, ces dernières peuvent être sorties de la mémoire de travail. • Elles passent ainsi en mode passif (voir cycle de vie plus tard) (=sauvegardées sur disque => tous les attributs doivent être sérialisables = types implémentant l’interface Serializable)
37
Les EJB Session stateful
• Les attributs de l’EJB sont sauvegardes durant toute la session
• Lorsqu’un client appelle l’EJB, une instance de ce dernier est créée, puis sert le client. Cette instance reste disponible pour les futurs appels de ce client uniquement. • Cette instance sera détruite a la fin de la session (timeout ou appel a une méthode portant l’annotation @Remove)
• S’il y a trop d’instances d’un EJB en mémoire, ces dernières peuvent être sorties de la mémoire de travail. • Elles passent ainsi en mode passif (voir cycle de vie plus tard) (=sauvegardées sur disque => tous les attributs doivent être sérialisables = types implémentant l’interface Serializable)
37
Les EJB Entity
• Représentation orientée objet des données dans une base de données
• Les clients peuvent y accéder en toute sécurité simultanément
• La durée de vie de l'EJB est exactement identique a celle des données qu'il représente
• La relation d'un EJB entité avec les données de la base de données peut être gérée par
• le développeur : persistance gérée par l'EJB
• le conteneur : persistance gérée par le conteneur
• Cette distinction se révèlera souvent essentielle du point de vue des performances
• Cependant on peut utiliser n'importe quel type d'EJB de manière interchangeable dans la conception
38
Les EJB Message Driven
• Sont les beans réactifs à des événements
• Sont abonnés à des fils de discussion (suite de messages)
• Sont informés lorsqu’un message doit leur être délivré
• S’appuient sur JMS (Java Message Service)
• Permettent l'envoi de messages asynchrones
• Permettent l'envoi multiple (1  n)
39
Les EJB Message Driven
• Sont les beans réactifs à des événements
• Sont abonnés à des fils de discussion (suite de messages)
• Sont informés lorsqu’un message doit leur être délivré
• S’appuient sur JMS (Java Message Service)
• Permettent l'envoi de messages asynchrones
• Permettent l'envoi multiple (1  n)
39
Cycles de Vie des EJB
40
Gestion des ressources
• Le serveur EJB maintient un « pool » (une réserve) d’instances de beans (pour les EJB entity et les EJB session stateless)
• Les clients des EJB interagissent avec les interfaces Remote qui sont implémentées par les objets EJB.
• Les applications clientes n’ont jamais un accès direct au bean réel. Elles interagissent avec des objets EJB
• Le pool exploite cet accès indirect aux beans pour offrir de meilleures performances. En d'autres termes, les clients n'ayant jamais accès aux beans directement, il n'y a aucune raison fondamentale de conserver une copie distincte de chaque bean pour chaque client. 41
Les EJB Session stateless
42
Les EJB Session stateful
43
Les EJB Entity
44
Les EJB Message‐Driven
45
Un peu de syntaxe …
46
Annotations Java
• Intégrées au JDK 1.5, elles permettent d'ajouter des Meta‐informations au code (i.e. marquer des éléments Java an de leur ajouter une propriété)
• Peuvent être utilisées sur n'importe quel type d‘ élément Java (package, class, attribut, méthode, paramètre, etc.)
• Plusieurs annotations peuvent être utilisées sur un même élément
• Non prises en compte par la JVM (mais présentes dans le .class) : il faut écrire du code ou des outils qui utilise ces informations
• Utilisées a la compilation ou a l'exécution
• Utilisation : @ suivi du mot‐clef correspondant a l'annotation
• L'API Java 5.0 propose de base 3 annotations : @Deprecated, @Override et @SuppressWarnings
• Déclaration et création de nouvelles annotations : comme une interface en utilisant le mot‐clef @interface (java.lang.annotation.Annotation) • Possibilité de passer des informations a une annotation : nom=valeur
47
Exemples
48
EJB3 et les annotations
• Les EJB3 utilisent les annotations pour simplifier le code a produire :
• Moins de code a écrire
• Génération automatique des descripteurs de déploiement
49
Les EJB session stateless
• Composés d'une ou deux interfaces et d'une classe métier :
• Interface de description du contrat pour accès distant (XXRemote.java)
• Utilisation de l'annotation @Remote (importation de javax.ejb.Remote) juste avant la définition de l'interface
• Interface de description du contrat pour accès local (XXLocal.java)
• Utilisation de l'annotation @Local (importation de javax.ejb.Local) juste avant la définition de l'interface
• Classe de définition de la logique métier (XXBean.java)
•
•
•
•
Importation de javax.ejb.Stateless
Utilisation de l'annotation @Stateless avant la définition de classe Implémentation des interfaces précédentes
Ne doit pas être final
50
Les EJB session stateless
• Rappel du cycle de vie
51
Les EJB session stateless
• Rappel du cycle de vie
• Dans XXXBean.java
• @PostConstruct suivi de la méthode postConstruct
• @PreDestroy suivi de la méthode preDestroy
51
Les EJB session stateful
• Composés d'une ou deux interfaces et d'une classe métier :
• Interface de description du contrat pour accès distant (XXRemote.java)
• Utilisation de l'annotation @Remote (importation de javax.ejb.Remote) juste avant la définition de l'interface
• Interface de description du contrat pour accès local (XXLocal.java)
• Utilisation de l'annotation @Local (importation de javax.ejb.Local) juste avant la définition de l'interface
• Classe de définition de la logique métier (XXBean.java)
•
•
•
•
importation de javax.ejb.Stateful
Utilisation de l'annotation @Stateful avant la définition de la classe
Implémentation des interfaces précédentes
Ne doit pas être final
52
Les EJB session stateful
• Rappel du cycle de vie
• Méthodes liées au cycle de vie
•
•
•
•
•
•
@PostConstruct suivi de la méthode postConstruct
@Init suivi de la méthode init
@PrePassivate suivi de la méthode prePassivate
@PostActivate suivi de la méthode postActivate
@Remove suivi de la méthode remove
@PreDestroy suivi de la méthode preDestroy
53
Exemple
• Un compteur pour illustrer la différence entre les EJB session stateless
et stateful
54
Exemple
• Un compteur pour illustrer la différence entre les EJB session stateless
et stateful
54
Exemple
• Un compteur pour illustrer la différence entre les EJB session stateless
et stateful
54
Exemple
55
Exemple
55
Exemple
•@Local et @Remote peuvent être portées par la même interface
•Il faut au moins une annotation @Local ou @Remote
•Toutes les annotations peuvent éventuellement être placées directement dans l'EJB. L'interface doit alors être précisée :
@ Stateless
@ Remote (NomInterface.class)
public class EJBStateless implements NomInterface {
...
}
55
Exemple
56
Exemple
56
Exemple
56
Exemple
56
Côté client
• Nommage d'un EJB
• Service de nommage : JNDI
• Nommage d'un EJB : ejb:AppName(ear)/ModuleName(jar)/BeanName!InterfaceName
• Attention ! Pour un EJB Stateful, une session JNDI doit être créée : on ajoute ?stateful lors de la récupération du stub
57
Côté client
• Nommage d'un EJB
• Service de nommage : JNDI
• Nommage d'un EJB : ejb:AppName(ear)/ModuleName(jar)/BeanName!InterfaceName
• Attention ! Pour un EJB Stateful, une session JNDI doit être créée : on ajoute ?stateful lors de la récupération du stub
57
Sorties
58
Déploiement avec JBoss
• Voir les instructions détaillées pour la compilation et le déploiement du côté serveur et du côté client dans les exemples sur Moodle
• Voir le cours de M Pauchet pour le passage de paramètres par valeur, l’envoi d’exceptions et les callbacks 59