1. Qu'est-ce que EJB?
EJB (Enterprise Java Beans) est une technologie de composante d'application commerciale à Javaee et est l'une des trois principales composantes de Javaee (Servlet, JSP, EJB). EJB fournit un cadre pour permettre aux clients d'utiliser des objets distribués à distance, simplifiant considérablement le développement d'applications de niveau d'entreprise avec une bonne évolutivité. La structure des composants EJB est une structure informatique distribuée basée sur des composants et est un composant d'un système d'application distribué.
EJB est une spécification du framework de service côté serveur Java et définit une spécification technique pour le système de composants côté serveur. Cette spécification peut fournir une architecture standard, distribuée et orientée objet. Il bloque les implémentations fonctionnelles sous-jacentes au niveau du système complexes pour les développeurs et les utilisateurs de composants, permettant aux développeurs de se concentrer sur la mise en œuvre de la logique métier, et certains des services sous-jacents complexes sont responsables des conteneurs EJB. EJB peut être élargi en fonction de la croissance de l'application, et le serveur EJB fournit des fonctions d'équilibrage de charge, ainsi que le contrôle d'accès aux ressources.
2. Communication entre le conteneur EJB et les composants
Les conteneurs EJB fournissent un environnement de fonctionnement pour les composants EJB. La façon dont les conteneurs EJB gèrent EJBS sont similaires à la façon dont les conteneurs Web gèrent les servlets. Les EJB doivent fonctionner dans des conteneurs EJB. Les conteneurs EJB gèrent principalement la persistance EJB, la gestion du cycle de vie, la gestion de la sécurité, la gestion des transactions, la connexion à distance, le traitement simultané, le clustering et l'équilibrage de charge. Le conteneur gère les instances de composants EJB, permettant aux composants EJB d'obtenir des performances maximales et une utilisation de la mémoire. Le conteneur peut activer et passer les composants EJB, gérer les pools d'instructions, etc. Les conteneurs sont responsables de la gestion des problèmes complexes du traitement des transactions distribuées, de la gestion des problèmes de communication de bas niveau pour les connexions à distance et de la dissimulation des problèmes de communication pour les développeurs et les clients des composants EJB. Par conséquent, les développeurs de composants EJB peuvent se concentrer sur l'encapsulation de la logique commerciale, et les conteneurs sont responsables de la gestion de toutes les autres transactions. EJB interagit avec les conteneurs via des mécanismes tels que les fonctions EJBContent, JNDJ, de rappel.
JBoss est un conteneur et un serveur qui gère EJB, prend en charge les spécifications EJB1.1, EJB2.0 et EJB3, et est généralement lié à Tomcat ou à Jetty.
Veuillez consulter la figure 1 (le schéma de travail du conteneur EJB):
Figure 1: Principe de travail du conteneur EJB
Un composant EJB est un objet distribué qui, lorsqu'il est instancié, peut communiquer avec les applications dans d'autres espaces d'adresse. L'instance EJB est encapsulée dans un objet squelette, qui communique avec le client via un objet Stub. Le talon n'inclut pas la logique métier, mais met en œuvre une interface commerciale. Chaque fois qu'une méthode commerciale sur l'interface commerciale Stub est appelée, le stub envoie un message réseau au framework et lui dit quelles méthodes il a appelés. Le framework appelle la méthode correspondante de l'instance EJB et envoie les résultats renvoyés par l'instance EJB vers le stub, et le stub renvoie ces résultats à l'application correspondante. À travers les deux objets, talons et cadres intermédiaires, le processus de communication complexe entre les objets distribués est bloqué. Le cadre est implémenté par des conteneurs, tandis que les talons sont automatiquement générés par des outils de développement, qui ne nécessitent aucun code d'écriture. Veuillez consulter la figure 2 (schéma de communication des composants EJB):
Figure 2: Principe de communication entre les composants EJB
3. Classification EJB
Les composants EJB peuvent être divisés en deux types: le bean de session et le bean piloté par le message. Le haricot de session résume la logique commerciale. Le client peut appeler les méthodes de bean de session via des services locaux, distants et Web pour accéder aux applications déployées sur le serveur, appelant ainsi les méthodes d'autres haricots. Le haricot de session n'est pas persistant, c'est-à-dire que ses données ne sont pas enregistrées dans la base de données. Parmi eux, le haricot de session comprend trois types: les haricots de session et les haricots de session sans état et les haricots de session monobloc. Les haricots axés sur les messages sont souvent utilisés comme auditeurs pour des types spécifiques de messages, permettant à Javaee de gérer les messages asynchrones, et les clients n'accèdent pas aux haricots axés sur les messages via des interfaces.
Ce qui suit présentera le bean de session avec état, le bean de session sans état, le bean de session monobile et le bean de session axé sur les messages.
4. Bean de session sans état
Les haricots de session sans état ne fournissent que la logique commerciale pour les clients et ne conservent pas l'état de session pour les clients. Lorsque le client appelle la méthode d'un bean de session sans état, les propriétés du bean de session correspondant décriront l'état d'appel, mais ne maintiennent cet statut que pendant l'appel de la méthode. Lorsque l'appel de méthode est terminé, l'état est effacé.
Le cycle de vie d'un haricot sans état est contrôlé par le conteneur. Lorsque le conteneur EJB reçoit la demande d'un client pour un bean de session sans état, si l'EJB n'existe pas, le conteneur créera une instance du bean, injectez les ressources requises dans le composant, puis le conteneur rappelle la méthode postconstruct et le composant est créé. À l'heure actuelle, le haricot passe de l'état «non existé» à l'état de «l'existence». Lorsque l'appel client est terminé, le conteneur rappelle la méthode Prestestroy et le haricot sera détruit. À l'heure actuelle, le haricot sera converti de l'état "existant" à l'état "non existant". Veuillez consulter la figure 3 (le cycle de vie d'un haricot sans état):
Figure 3: Cycle de vie d'un haricot sans état
5. Bean de session avec état
Un haricot de session avec état conserve un état de session pour l'utilisateur. Il ne peut pas être placé dans le pool de composants pour que différents utilisateurs puissent partager comme un bean de session sans état. Pour un bean de session avec état, tant qu'un client envoie une demande, le conteneur crée une instance correspondant au client et qu'un client correspond à une instance. Au cours de la vie, le haricot de session avec état maintient les informations de l'utilisateur, et une fois la session terminée, le cycle de vie du bean de session d'État se termine également.
Un haricot de session avec état a trois états actifs: la non-existence, la activité et la passivation. Lorsque le bean de session avec état est actif pendant une période de temps, si la demande du client externe n'est toujours pas reçue, afin d'économiser des ressources système, le conteneur sérialisera les informations d'état dans le bean de session d'état dans l'espace de stockage temporaire et supprimera le bean de session d'état de la mémoire. Ce processus est appelé "passivation". Le conteneur rappelle la méthode avant-tue avant la passivation. Lorsque le conteneur reçoit une demande de haricot de session avec état qui a été passivé, il réinitialise l'instance du haricot de session et élimine les informations d'état de l'espace temporaire pour le retourner à l'état actif. Ce processus est appelé "activation". Après l'activation, le conteneur rappelle la méthode Proactivate. Lorsque le haricot de session avec état passe pendant une période de temps, le conteneur effacera complètement l'instance et rappellera la méthode Prestestroy. Veuillez consulter la figure 4 (le cycle de vie d'un haricot de session d'État):
Figure 4: Cycle de vie d'un haricot de session avec état
6. Haricot de séance à une pièce
Un bean de session en une seule pièce est instancié une fois pour chaque application et est toujours présent tout au long du cycle de vie de l'application. Un bean de session unique est conçu pour des scénarios spécifiques, et les clients peuvent accéder à cette instance EJB unique en mode partagé et simultané.
Un haricot de session en une seule pièce est très similaire à un haricot de session sans état. La différence est qu'un bean de session unique n'a qu'une seule instance dans l'application, tandis qu'un bean de session sans état peut avoir de nombreuses instances, chaque instance est placée dans le pool de composants que les utilisateurs peuvent partager.
Un haricot de session en une seule pièce est comme un haricot sans état, jamais passivé. Son cycle de vie ne contient que deux types de corps: «inexistante» et «existence». Veuillez consulter la figure 5 (le cycle de vie d'un haricot de session en une seule pièce):
Figure 5: Cycle de vie d'un haricot de session en une seule pièce
7. Bean axé sur les messages
Les haricots basés sur des messages sont des composants conçus pour gérer spécifiquement les demandes basées sur des messages. Les haricots basés sur des messages intègrent les fonctions du service de messages Java (JMS) et des haricots d'entreprise. Le client ne peut pas obtenir directement sa référence et appeler la méthode, mais ne peut être démarré que par les messages système.
Les conteneurs EJB créent généralement un pool composant de haricots basés sur des messages. Semblable aux haricots sans état, les haricots basés sur les messages ne sont jamais passivés et leur cycle de vie ne contient que deux étapes: la non-existence et l'existence.
La classe de bean axée sur les messages doit implémenter l'interface MessageListener. Lorsque le conteneur détecte un message dans la file d'attente que le bean écoute, il appelle la méthode OnMessage () et passe le message en tant que paramètre.
La compréhension complète ci-dessus de l'EJB de base de J2EE est tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.