EJB

Entreprise Java
Beans
Références
 Cours : Mohamed Youssefi
 http://www.mastertheboss.com/jboss-server
Exigences de qualité d’un
système logiciel
La qualité d'un logiciel se mesure par rapport à plusieurs critères:
 Exigences fonctionnelles:
 Une application est créée pour répondre, tout d'abord, aux besoins fonctionnels
des entreprises.
 Exigences Techniques:
 Les performances:
 La rapidité d'exécution et Le temps de réponse
 Eviter le problème de montée en charge
 La maintenance:
 Une application doit évoluer dans le temps.
 Doit être fermée à la modification et ouverte à l'extension
 Sécurité
 Portabilité
 Capacité de communiquer avec d'autres applications distantes.
 Disponibilité et tolérance aux pannes
 Capacité de fournir le service à différents type de clients
 Design des ses interfaces graphiques
 Cout du logiciel
Architectures Distribués
Couches d’une application
Couche Présentation
 Elle implémente la logique présentation de l'application
 La couche présentation est liée au type de client utilisé :
 Client Lourd java Desktop:
 Interfaces graphiques java SWING, AWT, SWT.
 Ce genre de client peut communiquer directement avec les
composants métiers déployés dans le conteneur EJB en utilisant le
middleware RMI (Remote Method Invocation)
 Client Leger Web
 HTML, Java Script, CSS.
 Un client web communique avec les composants web Servlet
déployés dans le conteneur web du serveur d'application en utilisant
le protocole HTTP.
 Un client .Net, PHP, C++, …
 Ce genre de clients développés avec un autre langage de
programmation autre que java, communiquent généralement avec
les composants Web Services déployés dans le conteneur Web du
serveur d'application en utilisant le protocole SOAP (HTTP+XML) ou REST
 Client Mobile
 Android, iPhone, Tablette etc..
 Généralement ce genre de clients communique avec les composants
Web Services en utilisant le protocole HTTP ou SOAP
Couche Application
 Appelée également couche web.
 La couche application sert de médiateur entre la couche
présentation et la couche métier.
 Elle contrôle l'enchainement des tâches offertes par l'application
 Elle reçoit les requêtes http clientes Assure le suivie des sessions
 Vérifier les autorisations d'accès de chaque session
 Assure la validation des données envoyées par le client
 Fait appel au composants métier pour assurer les traitements
nécessaires
 Génère une vue qui sera envoyée à la couche présentation.
 Elle utilise les composants web Servlet et JSP
 Elle respecte le modèle MVC (Modèle Vue Contrôleur)
 Des framework comme JSF, SpringMVC ou Struts sont généralement
utilisés dans cette couche.
Couche Métier
 La couche métier est la couche principale de toute application
 Elle implémente la logique métier d'une entreprise
 Elle se charge de récupérer, à partir des différences sources de données, les données
nécessaires pour assure les traitement métiers déclenchés par la couche application.
 Elle assure la gestion du WorkFlow (Processus de traitement métier en plusieurs étapes)

 Il est cependant important de séparer la partie accès aux données (Couche

DAO) de la partie traitement de la logique métier (Couche Métier ) pour les
raisons suivantes:
 Ne pas se perdre entre le code métier, qui est parfois complexe, et le code d'accès aux
données qui est élémentaire mais conséquent.
 Ajouter un niveau d'abstraction sur laccès aux données pour être plus modulable et par
conséquent indépendant de la nature des unités de stockage de données.
 La couche métier est souvent stable. II est rare qu'on change les processus métier. Alors
que la couche DAO n'est pas stable. II arrive souvent qu'on est contrait de changer de
SGBD ou de répartir et distribués les bases de données.
 Faciliter la répartition des tấches entre les équipes de développement.
 Déléguer la couche DAO à frameworks spécialisés dans l'accès aux données (Hibernate,
Toplink, etc...)
Entreprise Java Entreprise
Java Beans (EJB)
 Enterprise JavaBeans (EJB) est une architecture de
composants logiciels côté serveur pour la plateforme de
développement Java EE.
 Cette architecture propose un cadre (Framework) pour
créer des composants distribués (c'est-à-dire déployés sur
des serveurs distants) écrit en langage de programmation
Java hébergés au sein d'un serveur applicatif.
 Les EJB permettant de :
 Représenter des données manipulées par l'application (EJB dit
Entity),
 Proposer des services avec ou sans conservation d'état entre les
appels (EJB dit Session),
 Accomplir des tâches de manière asynchrone (EJB dit Message
Driven Bean).
Entreprise Java Entreprise
Java Beans (EJB)
 Tous les EJB peuvent évoluer dans un
contexte transactionnel.
 Les Entreprise Java Bean ou EJB sont des
composants qui permettent de
d'implémenter la logique métier.
 Ce sont des composant distribués qui
s'exécutent au sein d'un conteneur EJB qui
fait partie du serveur d'application JEE.
 Le but des EJB est de faciliter la création
d'applications distribuées pour les entreprises.
Entreprise Java Entreprise
Java Beans (EJB)
 Une des principales caractéristiques des EJB est de permettre aux développeurs
de se concentrer sur les traitements orientés métiers car les EJB et
l'environnement dans lequel ils s'exécutent prennent en charge un certain
nombre de traitements techniques en utilisant les services de l'infrastructure offert
par le serveur d'application tel que :
 La distribution,
 La gestion des transactions,
 La persistance des données,
 Le cycle de vie des objets,
 La montée en charge,
 La concurrence
 La sécurité,
 La sérialisation,
 Journalisation,
 Etc....
 Autrement dit, EjB permet de séparer le code métier qui est propre aux
spécifications fonctionnelles du code technique (spécification non fonctionnel)
Différents types d’EJB
 II existe trois types d'EjB:
 Entity Beans : Les EJB entités
 Représentent les données manipulées par l'application (Composants persistants)
 Chaque EjB Entity est associé à une table au niveau de la base de données Session Beans:
 Les EJB session
 Composants distribués qui implémentent les traitement de la logique métier.
 Ces composants sont accessibles à distance via les protocole RMI et IIOP.
 Il existe trois types d'EJB Session.
 Stateless : sans état
 Une instance est crée par le serveur pour plusieurs connexions clientes.
 Ce type de bean ne conserve aucune donnée dans son état.
 Statefull : avec état
 Création d'une instance pour chaque connexion cliente.
 Ce type de bean peut conserver des données entre les échanges avec le client.
 singleton: Instance Unique
 Création d'une instance unique quelque soit le nombre de connexion.
 Message Driven Beans: Beans de messages
 Un listener qui permet de déclencher des traitements au niveau de l'application suite à la
réception d'un message asynchrone JMS.
EJB Session Singleton
 Création d’une seule instance
EJB Session Stateless
 Création d’un pool d’instances
EJB Session Stateful
 Création d’une instance pour chaque connexion
Conteneur EJB et Services
d’infrastructures
Conteneur EJB
 Le rôle du conteneur EJB et de:
 Gérer le cycle de vie des composants EJB de
l’application :
 Instanciation
 Accès au bean
 Sérialisation
 Désérialisation
 Destruction du bean
 Permettre aux EJB d'accéder aux services
d'infrastructures offerts par le serveur d'application
JEE.
Services d’infrastructure d’un
serveur d’application J2EE
 JDBC (Java Data Base Connectivity) : Pilotes java pour permettre l'accès aux bases
de données
 JPA (Java Persistence API) : Interface qui permet de gérer la persistance des EJB
Entity. Le serveur d'application fournie un Framework implémentant la spécification
JPA pour assurer le mapping objet relationnel (Pour JBOSS c'est Hibernate qui est
utilisé)
 JNDI (Java Naming Directory Interface) : Service permettant de connecter les
composants de l'application vers les services de noms ou d'annuaires comme les
annuaires RMI, CORBA, LDAP, DNS etc... chaque serveur d'application possède son
propre annuaire qui lui permet de publier les références des composants déployés
dans le serveur en leurs associant un nom. Comme ça ils seront accessibles en local
ou à distance par d'autres composants.
 JMS : Service de messagerie asynchrone. Ce service permet aux composants
comme les MDB de se connecter à une file d'attente du service de messagerie inter-
application JMS pour envoyer et recevoir d'une manière asynchrone les message
JMS à destination et en provenance de d'autres composants distants. Chaque
serveur d'application possède son propre provider JMS qui permet de déployer de
nouvelles files d'attente JMS.
 JMX : service qui permet de modifier les paramètres de configuration du serveur
d'application à chaud
Services d’infrastructure d’un
serveur d’application J2EE
 JCA (Java Connector Architecture): pour connecter les
composants d'une application J2EE vers d'autres systèmes
d'informations d'entreprises comme les ERP.
 JAXWS : Spécification pour l'implémentation des web
services SOAP. Chaque serveur d'application possède sa
propre implémentation JaxWS (CXF, AXIS,...)
 JAXRS : Spécification pour l'implémentation des web
services REST FULL. Chaque serveur d'application possède
sa propre implémentation JaxRS (Jersey, RestEasy,...)
 JSTL (Java Server Pages Stadard Tag Library) : Bibliothèques
de tag JSP qui permettent de faciliter l'écriture des pages
web dynamique JSP.
 JSF (Java Server faces) : Framework MVC pour développer
les application web J2EE au même titre que Struts et Spring
MVC.
EJB Session
 Un EJB Session est un composant qui possède
 Une interface remote : qui permet de déclarer les
méthodes qui sont accessibles à distance. C'est-à-dire
accessible aux composants qui sont déployés dans
d'autres machines.
 Une interface Local : qui permet de déclarer les
méthodes qui sont accessible en local. C'est-à-dire les
méthodes accessible par les composants déployés
dans le même serveur d'application.
 La classe du bean qui implémente les deux interfaces
remote et local. l'implémentation des méthodes de
cette classe représentent les traitements métier de
l'application
Exemple
 On souhaite créer une application qui permet de gérer des comptes.
 Chaque compte est défini par son code, son solde et sa date de création
 L'application doit permettre de réaliser les opérations suivantes:
 Ajouter un compte
 Consulter tous les comptes
 Consulter un compte
 Effectuer le versement d'un montant dans un compte
 Effectuer le retrait d'un montant d'un compte
 Effectuer un virement d’un compte vers un autre
 L'application doit être accessible par:
 Un client lourd java distant
 Une application web basée sur Servlet et JSP
 Un client SOAP
 On supposera, dans un premier temps, que les comptes sont stockés dans une liste non
persistante.
 Par la suite nous aborderons la persistance des comptes dans une base de données
en utilisant JPA.
Architecture
Installation du plugin Jboss
Tools pour Eclipse
• Help>Eclipse Marketplace
 Installation du plugin Jboss
Tools pour Eclipse

• Il n’est pas nécessaire d’installer tous les outils fournis par JbossTools
• Désactiver le plugin pour ne sélectionner que les plugins souhaités
 Installation du plugin Jboss
Tools pour Eclipse

• Activer Uniquement JBossAS Tools

• Pour installer les outils du serveur d’application Jboss
 Installation du plugin Jboss
Tools pour Eclipse

• Acceptez la licence
• Une fois l’installation terminée, L’assistant vous demandera de redémarrer Eclipse
Création d’un projet EJB

• New > EJB Project

 Création d’un projet EJB

• Après avoir spécifié le nom du projet,

• Cliquez sur le bouton New Runtime, pour associer un serveur à ce projet
 Associer un serveur au projet

• Dans notre cas, nous utilisons wildfly 18.0

• A télécharger sur le site de Jboss :
https://www.wildfly.org/downloads/
 Associer un serveur au projet

• Spécifier le chemin du serveur Wildfly

• Sélectionner un JRE installé
 Associer un serveur au projet

• Finir la création du projet EJB

Structure du Projet EJB
• Projet vide • Projet à créer
Les données manipulées
(Entités) : Compte.java
 On commence par créer les structures de
données manipulées par l’application.
 Il s’agit des entités (Entities) de
l’application. Dans notre cas, notre
application traite des comptes. Pour le
moment nous n’allons pas traiter la
persistance des entités
 Nous considérons que Compte est un
simple Java Bean et non pas un EJB Entity
Les données manipulées
(Entités) : Compte.java
Interface Remote
Une interface Remote d’un EJB Session doit
être annotée @Remote
L’interface Local
 Une interface Locale d’un EJB Session doit être annotée
@Local
 Dans notre cas, nous supposons que toutes les
méthodes de l’EJB Session son accessible à distance et
en local
Implémentation d’un EJB
Session Statless
 Un EJB Session est une classe qui implémente ses deux interfaces Local et Remote.
 Cette classe doit être annoté par l’une des annotations suivantes:
 @Statless : Un pool d’instances de cet EJB sera créé par le serveur
 @Statfull : Pour chaque connexion, le serveur crée une instance
 @Singleton : Un instance unique sera créée quelque soit le nombre de
connexions
 Après instanciation d’un EJB Session, ses références Remote (IP, Port, Adresse
Mémoire) et Locale (Adresse Mémoire) seront publiée dans l’annuaire JNDI.
 L’attribut name de ces trois annotations, permet de spécifier le nom JNDI qui sera
associé aux références de l’EJB dans l’annuaire JNDI
 Par défaut, c’est le nom de la classe qui sera utilisé.
 Ce nom sera combiné à d’autres informations techniques pour garantir l’unicité de
ce nom.
 Avec Wildfly, le nom complet JNDI d’un EJB Session est de la forme suivante :
 Pour un statless et singleton
 Nom_Projet_EAR/Nom_Projet_EJB/Name!Package.NomInterface
 Pour un statful
 Nom_Projet_EAR/Nom_Projet_EJB/Name!Package.NomInterface?statful
Implémentation de L’EJB Session
Implémentation d’un EJB
Session Statless (Suite)
Déployer le projet EJB
Aperçu de la console du
serveur après démarrage
Client Java Remote
 Créer un nouveau projet Java pour le client
 New > Java Project
Le client a besoin de l’interface
Remote de l’EJB Session et de l’entité
Compte
 Première solution (Phase de Test):
 Lier le classpath du projet client au classpath du projet EJB. De cette
façon, tous les composants du projet EJB seront accessible au projet
Java
 Afficher la fenêtre propriétés du projet client java
 Java Build Path > Onglet Projects > Add
Ajouter jboss-client.jar au
classpath du projet client
 Pour accéder à distance à l’EJB session via le protocole RMI, le client
a besoin d’un proxy dynamique (Stub) dont l’implémentation et ses
dépendances sont définies dans un fichier jar unique « jbossclient.jar
» fournie par jboss.
 Ce fichier ce trouve dans le dossier bin/client de jboss
 Il faut l’ajouter au classpath du projet client Java Build Path >
Librairies > Add External JARs…
Diagramme de séquence de
communication Remote entre le client
java et l’EJB Session
Propriétés JNDI
 Pour que le client java puisse se connecter à
l’annuaire JNDI pour chercher la référence
remote de l’EJB, il a besoin de connaitre un
cernain nombre de propriétés JNDI.
 Ces propriétés sont généralement définies
dans le fichier jndi.properties.
 Pour le cas de wildfly, l’essentiel des
propriétés peuvent être définie dans le fichier
jboss-ejb-client.properties .
Propriétés JNDI
 jndi.properties

 jboss-ejb-client.properties
Configuration pour tous les
clients
 Un changement affectant vos clients est que l'ancien fichier jboss-ejb-
client.properties est déprécié, vous êtes donc encouragé à migrer vers
le fichier Elytron wildfly-config.xml qui unifie toute la configuration client
en un seul endroit. Pour les besoins de notre exemple, nous allons
simplement ajouter un fichier wildfly-config.xml par défaut qui utilise
n'importe quel sélecteur de mécanisme SASL disponible pour
l'authentification..
Configuration de la sécurité
dans le projet client EJB
 D'autre part, si vous devez fournir des informations
d'identification, vous pouvez les ajouter dans le fichier
wildfly-config.xml comme dans l'exemple suivant:

Pour créer l'utilisateur sur le serveur, exécutez simplement le script add-user.sh

comme suit:
$ ./add-user.sh -a -u ejbuser -p password1!
Client EJB