INTRODUCTION

Les Entreprise Java Beans (EJB) sont des composants logiciels conçus pour être exécutés côté serveur. Ils sont
utilisés pour encapsuler les règles et les processus qui gèrent les données et les opérations principales de
l'application.

En utilisant les EJB, les développeurs peuvent séparer les fonctions hébergées sur le serveur des tâches
effectuées par le front-end, ce qui permet de rendre l'application plus efficace et plus modulaire.

Les EJB permettent également une plus grande flexibilité dans la gestion des tâches sur le serveur, en
permettant une répartition des tâches plus fine et plus efficace.

Les EJB sont conçus pour gérer les transactions complexes dans les applications d'entreprise. Les transactions
peuvent inclure plusieurs opérations simultanées sur plusieurs sources de données, et les EJB assurent
l'intégrité de ces opérations en les gérant de comme une seule opération indivisible.

Cela garantit que les données sont cohérentes et fiables, même en cas d'erreurs ou de pannes.

Avantages des EJB

Le développeur EJB peut se concentrer uniquement sur la logique métier (règles de validation et de contrôle,
des calculs de prix et de coûts, des opérations de gestion de stocks et de commandes, etc. ) et la résolution des
problèmes car les EJB encapsulent la logique métier dans des composants côté serveur. Cela permet aux
développeurs de se concentrer sur la résolution des problèmes métier sans se soucier des détails techniques de
mise en œuvre.

Les EJB offrent une sécurité gratuite en utilisant des mécanismes de sécurité standard, tels que la sécurité
d'authentification et la sécurité d'autorisation. Cela permet aux développeurs de se concentrer sur la logique
métier sans avoir à se soucier de la sécurité, ce qui peut être une tâche complexe et fastidieuse.

Les EJB offrent également des capacités d'accès à distance, ce qui signifie que les clients peuvent accéder aux
composants EJB à partir de n'importe où sur le réseau. Les composants EJB peuvent également être regroupés
pour des raisons d'évolutivité, ce qui permet aux applications de s'adapter facilement aux changements de
charge et d'augmenter les performances.

Les concepts de la programmation orientée objet (POO), tels que l'héritage, sont pris en charge dans les EJB.
Cela permet aux développeurs de concevoir des applications plus flexibles et modulaires, en utilisant des
techniques de POO bien établies.

Les EJB offrent également l'utilisation et l'accès gratuits de ressources complexes, telles que les connexions de
base de données et les transactions distribuées. Cela permet aux développeurs de se concentrer sur la logique
métier sans avoir à se soucier des détails complexes de mise en œuvre des ressources

Inconvénients

L'utilisation des EJB peut potentiellement conduire à la création d'une solution plus coûteuse et complexe. En
effet, l'utilisation des EJB nécessite souvent l'utilisation de serveurs d'application coûteux, ainsi que d'autres
technologies de développement associées, tels que des outils de développement spécialisés et des frameworks.

De plus, l'utilisation excessive des EJB peut également entraîner une utilisation excessive des ressources et des
artefacts. Les EJB peuvent nécessiter l'utilisation de serveurs d'application et de bases de données plus puissants
pour gérer les demandes de l'application, ce qui peut entraîner des coûts supplémentaires pour les
infrastructures et les ressources nécessaires.
L'utilisation des EJB peut également augmenter le temps de développement. La configuration et la mise en
œuvre de ces composants peuvent être complexes et prendre du temps, ce qui peut ralentir le développement
de l'application.

Enfin, les EJB peuvent être complexes à comprendre et à développer pour les développeurs débutants ou
inexpérimentés. Les EJB impliquent souvent des concepts avancés de développement d'applications, tels que la
gestion des transactions et la mise en cache, ce qui peut rendre leur utilisation complexe pour les développeurs
débutants ou inexpérimentés.

En somme, les EJB peuvent offrir des avantages significatifs dans certains cas d'utilisation, mais leur utilisation
excessive ou inappropriée peut entraîner des coûts supplémentaires, des complexités inutiles et des délais de
développement plus longs. Il est donc important de bien évaluer les avantages et les inconvénients des EJB
avant de décider de les utiliser dans le développement d'une application.

L' architecture EJB

L'architecture EJB (Enterprise Java Beans) est une architecture de développement logiciel pour les applications
d'entreprise qui repose sur la plateforme Java EE (Enterprise Edition). Elle est basée sur la notion de composants
logiciels réutilisables, appelés EJBs, qui encapsulent la logique métier de l'application.

Dans cette architecture, les EJBs sont déployés sur un serveur d'applications, qui fournit un environnement
d'exécution pour les EJBs.

Les clients d'application (par exemple, des navigateurs web, des clients mobiles, des applications de bureau,
etc.) accèdent aux EJBs via une interface distante standardisée, fournie par l'EJB Server.

Voici les principaux éléments de l'architecture EJB :

Le client : C'est le composant qui accède aux EJBs pour effectuer des opérations sur l'application. Le client peut
être une application web, une application mobile, une application de bureau, etc.

L'EJB Home : Il fournit une interface de classe distante pour créer et gérer des instances d'EJB. L'EJB Home est
utilisé par le client pour obtenir une référence à l'EJB Object.

L'EJB Object : Il représente une instance d'un EJB spécifique et fournit des méthodes d'accès à la logique métier
encapsulée par l'EJB. Le client utilise l'EJB Object pour appeler des méthodes sur l'EJB.

L'EJB Server : Il est responsable de l'instanciation et de la gestion des EJBs. Il fournit également des services tels
que la gestion des transactions, la sécurité, la mise en cache, etc.

Le conteneur EJB : Il fournit un environnement d'exécution pour les EJBs. Il gère la création, l'initialisation et la
destruction des instances d'EJB, ainsi que la gestion des ressources telles que la mémoire, le temps d'exécution
et la sécurité.

La base de données ou le composant : L'EJB peut accéder à une base de données pour stocker et récupérer des
données. Alternativement, l'EJB peut accéder à d'autres composants logiciels tels que des services web ou des
systèmes de messagerie.

l'architecture EJB fournit un moyen standardisé de développer des applications d'entreprise hautement
transactionnelles et réutilisables. Elle utilise des composants logiciels encapsulés pour séparer la logique métier
de l'accès aux données, fournit des services communs pour les applications d'entreprise et utilise une interface
distante standardisée pour permettre l'accès aux EJBs.
Types des EJB

Session Beans : sont des composants côté serveur, est comme un exécuteur de tâches, il est responsable de
l’exécution d’une tâche pour un client, telles que la gestion de sessions, l'accès aux données, la validation des
entrées utilisateur, etc.

Entity Beans : sont des composants côté serveur qui représentent des données stockées dans une base de
données, Ils sont utilisés pour la création, la lecture, la mise à jour et la suppression d'enregistrements.

Message Driven Beans : est un bean de lecteur de message qui traite essentiellement les messages de manière
asymétrique, l’opération ne bloque pas le reste des opérations, Il ne répond pas aux événements client, mais
aux messages internes à l’application globale.

Message Driven Bean(MDB)

Est un composant de service de messagerie en Java qui permet de créer et de gérer des communications
asynchrones via un écouteur JMS (Java Message Service). L'objectif principal de MDB est de consommer les
messages provenant d'une file d'attente ou d'un abonnement à un sujet, ce qui permet de fournir une
communication asynchrone fiable et efficace entre les différentes parties de l'application. Les MDB peuvent être
déployés dans un environnement EJB (Enterprise Java Beans) pour tirer parti des services transactionnels et de
sécurité fournis par la plateforme Java EE.

Les MDB (Message-Driven Beans) sont utilisés pour établir un système de messagerie interne entre les différents
éléments d'un conteneur EJB (Enterprise Java Beans). Ils sont généralement de type Stateless, ce qui signifie
qu'ils n'ont pas de mémoire d'état associée à un client particulier.

Le JMS provider est responsable de l'administration et du contrôle des messages échangés entre les différents
clients JMS. Les clients JMS peuvent produire et accepter des messages, tandis que les messages eux-mêmes
sont les objets que vous conservez et communiquez avec les clients JMS.

En résumé, les MDB sont utilisés pour établir un système de messagerie interne dans un environnement EJB,
avec le JMS provider responsable de la gestion des messages échangés entre les clients JMS. Les messages sont
les objets échangés entre les clients JMS, tandis que les MDB sont des composants Stateless qui ne conservent
pas de mémoire d'état associée à un client particulier.

Avantages MDB par rapport aux autres types d'EJB

Les MDB (Message-Driven Beans) offrent plusieurs avantages par rapport aux autres types d'EJB. Tout d'abord,
Scalabilité : Les MDB utilisent un modèle de traitement asynchrone, ce qui signifie qu'ils peuvent traiter
plusieurs messages simultanément, permettant ainsi de gérer des volumes de messages importants.

Fiabilité : Les MDB garantissent la livraison des messages en utilisant un système de files d'attente. Cela signifie
que si un message ne peut pas être traité immédiatement, il sera mis en attente dans la file d'attente et sera
traité dès que possible.

Déploiement facile : Les MDB sont faciles à configurer et à déployer, ce qui permet de gagner du temps et de
réduire les coûts.

Performance : Les MDB sont conçus pour être hautement performants et sont capables de traiter des volumes
de messages importants en utilisant des ressources système minimales.
Les inconvénients par rapport aux autres types d'EJB

Bien que les MDB (Message-Driven Beans) offrent des avantages, ils ont également certains inconvénients par
rapport aux autres types d'EJB. Tout d'abord,

Complexité et maintenance : Les MDB peuvent être plus complexes à développer et à maintenir que les autres
types d'EJB. Ils nécessitent une compréhension plus approfondie de la gestion des messages et de la
configuration des files d'attente.

Difficultés de débogage : Comme les MDB sont conçus pour traiter des messages de manière asynchrone, il peut
être difficile de suivre et de déboguer le traitement des messages. Les erreurs peuvent être difficiles à identifier
et à résoudre.

Risque de perte de messages : Les MDB utilisent des files d'attente pour stocker les messages en attente de
traitement. En cas de panne du système ou de la file d'attente, il existe un risque de perte de messages.

Infrastructure supplémentaire : Les MDB nécessitent une infrastructure supplémentaire pour la gestion des
messages, notamment des files d'attente, qui doivent être configurées et gérées de manière appropriée.

Approche générale MDB :

La mise en œuvre d'un MDB implique un serveur et un client.

Côté serveur, on crée une classe qui implémente l'interface MessageListener et remplace la méthode
onMessage(). Cette classe est marquée avec l'annotation @MessageDriven, généralement avec un type de file
donné dans activationConfig qui donne le nom et les propriétés de la file de messages spécifiques au serveur.

Côté client, on crée une classe principale qui trouve la ConnectionFactory et la file d'attente dans InitialContext,
crée une session et un MessageProducer, et envoie des messages de différents types (TextMessage,
ObjectMessage, etc.) à plusieurs reprises.

Le fichier [Link] est utilisé de la même manière que pour les Session Beans.

En résumé, cette approche générale utilise un écouteur JMS pour créer une communication asynchrone entre
un serveur MDB et un client qui produit et envoie des messages à une file d'attente ou un abonnement à un
sujet, offrant une grande fiabilité, tolérance aux pannes, sécurité et intégrité accrues pour les applications
robustes et hautement scalables.

Concepts Des MDB

Les MDB (Message Driven Beans) sont une composante clé de la plateforme Java EE (Enterprise Edition) qui
permet de développer des applications d'entreprise distribuées. Ils sont basés sur le standard JMS (Java
Messaging Service) qui définit une API pour l'envoi et la réception de messages entre des composants d'une
application distribuée.

Les interfaces JMS fournissent des méthodes pour la création et la manipulation de connexions, sessions,
producteurs et consommateurs de messages, ainsi que pour la gestion des transactions et des exceptions liées à
la messagerie. Les principaux interfaces de JMS sont:

ConnectionFactory: une fabrique qui permet de créer des connexions vers une queue/topic JMS.
Connection: une connexion à un serveur JMS qui peut être utilisée pour créer des sessions.
Session: une période de temps pour l'envoi ou la réception de messages dans une queue/topic JMS. Les sessions
peuvent être transactives ou non transactives.
MessageProducer: un producteur de messages qui envoie des messages vers une queue/topic JMS.
MessageConsumer: un consommateur de messages qui reçoit des messages depuis une queue/topic JMS.
MessageListener: une interface pour la réception de messages de manière asynchrone.
Les MDB utilisent ces interfaces JMS pour recevoir des messages de manière asynchrone à partir d'une
queue/topic JMS et pour effectuer des traitements en réponse à ces messages. Les MDB sont déployés dans un
conteneur d'applications Java EE et sont gérés par le serveur d'application.

Les étapes du JMS

Les étapes pour utiliser JMS (Java Messaging Service) afin d'envoyer un message à une queue/topic sont les
suivantes :

Création d'une connexion : créer une connexion avec le serveur de messagerie en utilisant une usine de
connexion (ConnectionFactory). La connexion peut être configurée avec des paramètres tels que le nom
d'utilisateur et le mot de passe.

Création d'une session : créer une session avec la connexion en utilisant la méthode createSession() de l'objet
Connection. La session peut être transactive ou non transactive.

Création d'un message : créer un objet de message en utilisant l'une des classes de message fournies par JMS
(TextMessage, ObjectMessage, BytesMessage, etc.). Remplir le message avec les données à envoyer.

Envoi du message : envoyer le message à la queue/topic en utilisant un producteur de message

Fermeture de la session : fermer la session en appelant la méthode close() de l'objet Session. Cela libère les
ressources associées à la session.

Fermeture de la connexion : fermer la connexion en appelant la méthode close() de l'objet Connection. Cela
libère les ressources associées à la connexion.

Il est important de noter que les étapes 5 et 6 sont facultatives car les ressources seront finalement libérées par
le garbage collector, mais il est recommandé de les fermer explicitement pour libérer les ressources
immédiatement.

@JMSDestinationDefinition(name = "jms/NewMassage", interfaceName = "[Link]",

Cette annotation définit la destination des messages que l'application va écouter. Dans ce cas, la destination est
une file d'attente nommée "NewMassage".

@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "jms/NewMassage"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "[Link]")
})
Cette annotation indique que la classe est un MDB qui va écouter les messages d'une file d'attente de type
"[Link]".
public class NewMessageBean implements MessageListener {

Cette ligne définit la classe "NewMessageBean" qui implémente l'interface "MessageListener". Cette interface
est nécessaire pour écouter les messages de la file d'attente.

@Resource
private MessageDrivenContext mdc;
Cette ligne indique que l'application va utiliser le contexte du MDB pour gérer les messages.
@PersistenceContext(unitName = "ProduitApp-ejbPU")
private EntityManager em;
Cette ligne définit une instance de l'EntityManager qui sera utilisée pour persister les objets reçus.

public NewMessageBean() { }

Ce bloc de code correspond au constructeur de la classe.

@Override

public void onMessage(Message message) {

Cette méthode est appelée à chaque fois qu'un message est reçu dans la file d'attente. Elle prend en paramètre
le message reçu.

ObjectMessage msg=null;
try{
if ( message instanceof ObjectMessage){
msg = (ObjectMessage ) message;
ProduitEntity e =(ProduitEntity) [Link]();
save(e);}
} catch(JMSException e){
[Link]();
[Link]();
} catch(Throwable te){
[Link]();}
Ce bloc de code extrait l'objet contenu dans le message reçu (s'il s'agit bien d'un message de type
"ObjectMessage") et le sauvegarde dans la base de données. En cas d'erreur, le contexte est rollbacké.

public void save(Object object) {

[Link](object);}

Cette méthode utilise l'EntityManager pour persister l'objet reçu dans la base de données.

En résumé, ce code définit un MDB qui écoute les messages d'une file d'attente, extrait l'objet contenu dans le
message et le sauvegarde dans une base de données à l'aide d'un EntityManager.