Jakarta Enterprise Beans - Jakarta Enterprise Beans

Jakarta Enterprise Beans ( EJB ; anciennement Enterprise JavaBeans) est l'une des nombreuses API Java pour la construction modulaire de logiciels d'entreprise . EJB est un composant logiciel côté serveur qui encapsule la logique métier d'une application. Un conteneur Web EJB fournit un environnement d'exécution pour les composants logiciels liés au Web, y compris la sécurité informatique , la gestion du cycle de vie des servlets Java , le traitement des transactions et d'autres services Web . La spécification EJB est un sous-ensemble de la spécification Java EE .

spécification

La spécification EJB a été initialement développée en 1997 par IBM , puis adoptée par Sun Microsystems (EJB 1.0 et 1.1) en 1999 et améliorée dans le cadre du Java Community Process en tant que JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) et JSR 345 (EJB 3.2).

La spécification EJB fournit un moyen standard d'implémenter le logiciel «métier» côté serveur (également appelé « back-end ») que l'on trouve généralement dans les applications d'entreprise (par opposition au logiciel d' interface utilisateur «front-end» ). Ces logiciels abordent les mêmes types de problèmes et les solutions à ces problèmes sont souvent réimplémentées à plusieurs reprises par les programmeurs. Jakarta Enterprise Beans est destiné à gérer de manière standard des problèmes communs tels que la persistance , l' intégrité transactionnelle et la sécurité , laissant les programmeurs libres de se concentrer sur les parties particulières du logiciel d'entreprise à portée de main.

Responsabilités générales

La spécification EJB détaille la manière dont un serveur d'applications fournit les responsabilités suivantes:

• Transaction en cours
• Intégration avec les services de persistance offerts par Jakarta Persistence (JPA)
• Contrôle de la concurrence
• Programmation événementielle utilisant Jakarta Messaging (JMS) et Jakarta Connectors (JCA)
• Appel de méthode asynchrone
• Planification des tâches
• Services de dénomination et d' annuaire via Java Naming and Directory Interface (JNDI)
• Communication interprocessus à l' aide de RMI-IIOP et des services Web
• Sécurité ( JCE et JAAS )
• Déploiement de composants logiciels dans un serveur d'applications

En outre, la spécification Jakarta Enterprise Beans définit les rôles joués par le conteneur EJB et les EJB, ainsi que la manière de déployer les EJB dans un conteneur. Notez que la spécification EJB ne détaille pas la manière dont un serveur d'applications fournit la persistance (une tâche déléguée à la spécification JPA), mais détaille plutôt comment la logique métier peut facilement s'intégrer aux services de persistance offerts par le serveur d'applications.

Histoire

Les entreprises ont constaté que l'utilisation d'EJB pour encapsuler la logique métier entraînait une baisse des performances. Cela est dû au fait que la spécification d'origine ne permettait que l'invocation de méthode distante via CORBA (et éventuellement d'autres protocoles), même si la grande majorité des applications métier ne nécessitent en fait pas cette fonctionnalité informatique distribuée . La spécification EJB 2.0 a répondu à cette préoccupation en ajoutant le concept d'interfaces locales qui pourraient être appelées directement sans pénalités de performances par des applications qui n'étaient pas distribuées sur plusieurs serveurs.

La spécification EJB 3.0 ( JSR 220) s'écartait de ses prédécesseurs, suivant un nouveau paradigme de légèreté. EJB 3.0 montre une influence de Spring dans son utilisation d'objets Java simples et sa prise en charge de l'injection de dépendances pour simplifier la configuration et l'intégration de systèmes hétérogènes. Gavin King, le créateur d'Hibernate, a participé au processus EJB 3.0 et est un ardent défenseur de la technologie. De nombreuses fonctionnalités à l'origine d'Hibernate ont été incorporées dans l' API Java Persistence , qui remplace les beans entité dans EJB 3.0. La spécification EJB 3.0 repose fortement sur l'utilisation d' annotations (une fonctionnalité ajoutée au langage Java avec sa version 5.0) et de conventions sur la configuration pour permettre un style de codage beaucoup moins verbeux. En conséquence, en termes pratiques, EJB 3.0 est beaucoup plus léger et presque une API complètement nouvelle, ne ressemblant guère aux spécifications EJB précédentes.

Exemple

Voici un exemple de base de ce à quoi ressemble un EJB dans le code:

@Stateless 
public class CustomerService { 
  

  private EntityManager entityManager; 
   
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

Ce qui précède définit une classe de service pour la persistance d'un objet client (via le mappage O / R ). L'EJB s'occupe de gérer le contexte de persistance et la méthode addCustomer () est transactionnelle et thread-safe par défaut. Comme démontré, l'EJB se concentre uniquement sur la logique métier et la persistance et ne sait rien d'une présentation particulière.

Un tel EJB peut être utilisé par une classe dans, par exemple, la couche Web comme suit:

@Named	
@RequestScoped
public class CustomerBacking {
   @EJB 
   private CustomerService customerService;

   public String addCustomer(Customer customer) {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

Ce qui précède définit un bean de sauvegarde JavaServer Faces (JSF) dans lequel l'EJB est injecté au moyen de l'annotation @EJB. Sa méthode addCustomer est généralement liée à un composant d'interface utilisateur, tel qu'un bouton. Contrairement à l'EJB, le bean de sauvegarde ne contient aucune logique métier ou code de persistance, mais délègue ces préoccupations à l'EJB. Le backing bean connaît une présentation particulière, dont l'EJB n'avait aucune connaissance.

Types de beans entreprise

Un conteneur EJB contient deux principaux types de beans:

• Session Beans qui peut être soit "Stateful", "Stateless" ou "Singleton" et accessible via une interface locale (même JVM) ou Remote (JVM différente) ou directement sans interface, auquel cas la sémantique locale s'applique. Tous les beans session prennent en charge l'exécution asynchrone pour toutes les vues (local / distant / sans interface).
• Message Driven Beans (MDB, également appelés Message Beans). Les MDB prennent également en charge l'exécution asynchrone, mais via un paradigme de messagerie.

Beans de session

Beans session avec état

Les beans session avec état sont des objets métier ayant un état : c'est-à-dire qu'ils gardent une trace du client appelant avec lequel ils ont affaire tout au long d'une session et ainsi l'accès à l'instance du bean est strictement limité à un seul client à la fois. Si un accès simultané à un seul bean est tenté de toute façon, le conteneur sérialise ces demandes, mais via l'annotation @AccessTimeout, le conteneur peut à la place lever une exception. L'état des beans session avec état peut être persistant (passivé) automatiquement par le conteneur pour libérer de la mémoire après que le client n'ait pas accédé au bean depuis un certain temps. Le contexte de persistance étendue JPA est explicitement pris en charge par les Stateful Session Beans.

Exemples

• La vérification dans une boutique en ligne peut être gérée par un bean session avec état qui utiliserait son état pour suivre où se trouve le client dans le processus de paiement, en maintenant éventuellement des verrous sur les articles que le client achète (du point de vue d'une architecture système , il serait moins idéal que le client gère ces verrous).

Beans session sans état

Les beans session sans état sont des objets métier auxquels aucun état n'est associé. Cependant, l'accès à une seule instance de bean est toujours limité à un seul client à la fois, l' accès simultané au bean est interdit. Si un accès simultané à un seul bean est tenté, le conteneur achemine simplement chaque requête vers une instance différente. Cela rend un bean session sans état automatiquement thread-safe. Les variables d'instance peuvent être utilisées lors d'un seul appel de méthode d'un client vers le bean, mais le contenu de ces variables d'instance n'est pas garanti d'être conservé à travers les différents appels de méthode client . Les instances de beans session sans état sont généralement regroupées. Si un deuxième client accède à un bean spécifique juste après la fin d'un appel de méthode effectué par un premier client, il peut obtenir la même instance. Le manque de surcharge pour maintenir une conversation avec le client appelant les rend moins gourmands en ressources que les beans avec état.

Exemples

• L'envoi d'un e-mail au support client peut être géré par un bean sans état, car il s'agit d'une opération ponctuelle et ne fait pas partie d'un processus en plusieurs étapes.
• Un utilisateur d'un site Web cliquant sur une case "Tenez-moi informé des futures mises à jour" peut déclencher un appel à une méthode asynchrone du bean session pour ajouter l'utilisateur à une liste dans la base de données de l'entreprise (cet appel est asynchrone car l'utilisateur ne le fait pas besoin d'attendre d'être informé de son succès ou de son échec).
• La récupération de plusieurs éléments de données indépendants pour un site Web, comme une liste de produits et l'historique de l'utilisateur actuel, peut également être gérée par des méthodes asynchrones d'un bean session (ces appels sont asynchrones car ils peuvent s'exécuter en parallèle de cette manière, ce qui potentiellement augmente les performances). Dans ce cas, la méthode asynchrone retournera une instance Future .

Haricots de session singleton

Les Session Beans Singleton sont des objets métier ayant un état global partagé au sein d'une JVM. L'accès simultané à la seule et unique instance du bean peut être contrôlé par le conteneur (accès concurrentiel géré par le conteneur, CMC) ou par le bean lui-même (accès concurrentiel géré par le bean, BMC). CMC peut être réglé à l'aide de l'annotation @Lock, qui indique si un verrou de lecture ou un verrou d'écriture sera utilisé pour un appel de méthode. De plus, Singleton Session Beans peut explicitement demander à être instancié lorsque le conteneur EJB démarre, à l'aide de l'annotation @Startup.

Exemples

• Le chargement d'une liste de prix quotidienne globale qui sera la même pour chaque utilisateur peut être effectué avec un bean session singleton, car cela évitera à l'application d'avoir à faire la même requête à une base de données encore et encore ...

Beans pilotés par message

Les Message Driven Beans sont des objets métier dont l'exécution est déclenchée par des messages plutôt que par des appels de méthode. Le Message Driven Bean est utilisé, entre autres, pour fournir une abstraction de haut niveau facile à utiliser pour la spécification JMS ( Java Message Service ) de niveau inférieur . Il peut s'abonner à des files d'attente de messages JMS ou à des sujets de messages, ce qui se produit généralement via l'attribut activationConfig de l'annotation @MessageDriven. Ils ont été ajoutés dans EJB pour permettre un traitement événementiel. Contrairement aux beans session, une MDB n'a pas de vue client (Local / Distant / Sans interface), i. e. les clients ne peuvent pas rechercher une instance MDB. Un MDB écoute simplement tout message entrant sur, par exemple, une file d'attente ou une rubrique JMS et les traite automatiquement. Seule la prise en charge de JMS est requise par la spécification Java EE, mais Message Driven Beans peut prendre en charge d'autres protocoles de messagerie. Ces protocoles peuvent être asynchrones mais peuvent également être synchrones. Étant donné que les beans session peuvent également être synchrones ou asynchrones, la principale différence entre les beans session et les beans gérés par message n'est pas la synchronicité, mais la différence entre l' appel de méthode (orienté objet) et la messagerie .

Exemples

• L'envoi d'une mise à jour de configuration à plusieurs nœuds peut être effectué en envoyant un message JMS à une `` rubrique de message '' et peut être géré par un Bean piloté par message écoutant cette rubrique (le paradigme de message est utilisé ici car l'expéditeur n'a pas besoin de connaître le nombre de consommateurs, leur emplacement ou même leur type exact).
• La soumission d'un travail à un cluster de travail peut être effectuée en envoyant un message JMS à une `` file d'attente de messages '' et peut également être gérée par un bean piloté par message, mais cette fois en écoutant une file d'attente (le paradigme du message et la file d'attente sont utilisés, car l'expéditeur n'a pas à se soucier du travailleur qui exécute le travail, mais il a besoin de l'assurance qu'un travail n'est exécuté qu'une seule fois).
• Le traitement des événements de synchronisation à partir du planificateur Quartz peut être géré par un Message Driven Bean; lorsqu'un déclencheur Quartz se déclenche , la MDB est automatiquement invoquée. Comme Java EE ne connaît pas Quartz par défaut, un adaptateur de ressources JCA serait nécessaire et la MDB serait annotée avec une référence à cela.

Exécution

Les EJB sont déployés dans un conteneur EJB, généralement au sein d'un serveur d'applications . La spécification décrit comment un EJB interagit avec son conteneur et comment le code client interagit avec la combinaison conteneur / EJB. Les classes EJB utilisées par les applications sont incluses dans le javax.ejb package. (Le javax.ejb.spi package est une interface de fournisseur de services utilisée uniquement par les implémentations de conteneur EJB.)

Les clients des EJB n'instancient pas ces beans directement via le nouvel opérateur Java, mais doivent obtenir une référence via le conteneur EJB. Cette référence n'est généralement pas une référence au bean d'implémentation lui-même, mais à un proxy , qui implémente dynamiquement l'interface métier locale ou distante demandée par le client ou implémente dynamiquement un sous-type du bean réel. Le proxy peut alors être directement casté vers l'interface ou le bean. On dit qu'un client a une «vue» sur l'EJB, et l'interface locale, l'interface distante et le type de bean lui-même correspondent respectivement à la vue locale, à la vue distante et à la vue sans interface.

Ce proxy est nécessaire pour donner au conteneur EJB la possibilité de fournir de manière transparente des services transversaux (de type AOP ) à un bean, tels que les transactions, la sécurité, les interceptions, les injections et la communication à distance. Par exemple, un client appelle une méthode sur un proxy, qui démarre d'abord une transaction à l'aide du conteneur EJB, puis appelle la méthode bean réelle. Lorsque la méthode bean revient, le proxy met fin à la transaction (c'est-à-dire en la validant ou en effectuant une annulation) et renvoie le contrôle au client.

Le conteneur EJB est chargé de s'assurer que le code client dispose de droits d'accès suffisants à un EJB. Les aspects de sécurité peuvent être appliqués de manière déclarative à un EJB via des annotations.

Transactions

Les conteneurs EJB doivent prendre en charge les transactions ACID gérées par conteneur et les transactions gérées par bean.

Les transactions gérées par conteneur (CMT) sont par défaut actives pour les appels aux beans session. Autrement dit, aucune configuration explicite n'est nécessaire. Ce comportement peut être réglé de manière déclarative par le bean via des annotations et si nécessaire, une telle configuration peut être remplacée ultérieurement dans le descripteur de déploiement. Le réglage comprend la désactivation des transactions pour l'ensemble du bean ou des méthodes spécifiques, ou la demande de stratégies alternatives pour la propagation de la transaction et le démarrage ou la jonction d'une transaction. Ces stratégies traitent principalement de ce qui devrait se passer si une transaction est ou n'est pas déjà en cours au moment où le bean est appelé. Les variantes suivantes sont prises en charge:

Alternativement, le bean peut également déclarer via une annotation qu'il souhaite gérer les transactions par programme via l' API JTA . Ce mode de fonctionnement est appelé Bean Managed Transactions (BMT), car le bean lui-même gère la transaction au lieu du conteneur.

Événements

JMS ( Java Message Service ) est utilisé pour envoyer des messages des beans aux clients, pour permettre aux clients de recevoir des messages asynchrones de ces beans. Les MDB peuvent être utilisés pour recevoir des messages de clients de manière asynchrone à l'aide d'une file d'attente JMS ou d'une rubrique.

Services de dénomination et d'annuaire

Comme alternative à l'injection, les clients d'un EJB peuvent obtenir une référence à l'objet proxy du bean session (le stub EJB) à l'aide de Java Naming and Directory Interface (JNDI) . Cette alternative peut être utilisée dans les cas où l'injection n'est pas disponible, comme dans le code non géré ou les clients Java SE distants autonomes, ou lorsqu'il est nécessaire de déterminer par programme le bean à obtenir.

Les noms JNDI des beans session EJB sont attribués par le conteneur EJB via le schéma suivant:

(les entrées entre crochets indiquent les parties facultatives)

Un seul bean peut être obtenu par n'importe quel nom correspondant aux modèles ci-dessus, en fonction de «l'emplacement» du client. Les clients du même module que le bean requis peuvent utiliser la portée du module et des portées plus grandes, les clients de la même application que le bean requis peuvent utiliser la portée de l'application et plus, etc.

Par exemple, un code s'exécutant dans le même module que le bean CustomerService (comme indiqué par l'exemple montré plus haut dans cet article) pourrait utiliser le code suivant pour obtenir une référence (locale) à celui-ci:

CustomerServiceLocal customerService =
    (CustomerServiceLocal) new InitialContext().lookup("java:module/CustomerService");

Exécution à distance / distribuée

Pour communiquer avec un client écrit dans le langage de programmation Java, un bean session peut exposer une vue distante via une interface annotée @Remote. Cela permet à ces beans d'être appelés à partir de clients dans d'autres JVM qui peuvent eux-mêmes être situés sur d'autres systèmes (distants). Du point de vue du conteneur EJB, tout code dans une autre JVM est distant.

Les beans session sans état et singleton peuvent également exposer une «vue client de service Web» pour la communication à distance via WSDL et SOAP ou XML brut. Cela suit les spécifications JAX-RPC et JAX-WS . La prise en charge de JAX-RPC est toutefois proposée pour une suppression future. Pour prendre en charge JAX-WS, le bean session est annoté avec l'annotation @WebService et les méthodes qui doivent être exposées à distance avec l'annotation @WebMethod.

Bien que la spécification EJB ne mentionne en aucun cas l'exposition en tant que services Web RESTful et ne prenne pas explicitement en charge cette forme de communication, la spécification JAX-RS prend explicitement en charge les EJB. Conformément à la spécification JAX-RS, les beans session Stateless et Singleton peuvent être des ressources racine via l'annotation @Path et les méthodes métier EJB peuvent être mappées aux méthodes de ressources via les annotations @GET, @PUT, @POST et @DELETE. Cependant, cela ne compte pas comme une «vue client de service Web», qui est utilisée exclusivement pour JAX-WS et JAX-RPC.

La communication via les services Web est typique pour les clients non écrits dans le langage de programmation Java, mais est également pratique pour les clients Java qui ont des difficultés à atteindre le serveur EJB via un pare-feu. De plus, la communication basée sur le service Web peut être utilisée par les clients Java pour contourner les exigences obscures et mal définies pour les soi-disant «bibliothèques clientes»; un ensemble de fichiers jar qu'un client Java doit avoir sur son chemin de classe afin de communiquer avec le serveur EJB distant. Ces bibliothèques clientes sont potentiellement en conflit avec les bibliothèques que le client peut déjà avoir (par exemple, si le client lui-même est également un serveur Java EE complet) et un tel conflit est considéré comme très difficile, voire impossible à résoudre.

Héritage

Interfaces domestiques et interface professionnelle requise

Avec EJB 2.1 et versions antérieures, chaque EJB devait fournir une classe d' implémentation Java et deux interfaces Java. Le conteneur EJB a créé des instances de la classe d'implémentation Java pour fournir l'implémentation EJB. Les interfaces Java ont été utilisées par le code client de l'EJB.

Descripteur de déploiement requis

Avec EJB 2.1 et versions antérieures, la spécification EJB nécessitait la présence d'un descripteur de déploiement. Cela était nécessaire pour mettre en œuvre un mécanisme qui permettait aux EJB d'être déployés de manière cohérente, quelle que soit la plate-forme d'EJB spécifique choisie. Les informations sur la manière dont le bean devrait être déployé (comme le nom de l'interface domestique ou distante, si et comment stocker le bean dans une base de données, etc.) devaient être spécifiées dans le descripteur de déploiement.

Le descripteur de déploiement est un document XML ayant une entrée pour chaque EJB à déployer. Ce document XML spécifie les informations suivantes pour chaque EJB:

• Nom de l'interface d'accueil
• Classe Java pour le Bean (objet métier)
• Interface Java pour l'interface d'accueil
• Interface Java pour l'objet métier
• Magasin persistant (uniquement pour Entity Beans)
• Rôles et autorisations de sécurité
• Stateful ou Stateless (pour Session Beans)

Les anciens conteneurs EJB de nombreux fournisseurs nécessitaient plus d'informations de déploiement que celles de la spécification EJB. Ils auraient besoin des informations supplémentaires sous forme de fichiers XML séparés ou d'un autre format de fichier de configuration. Un fournisseur de plate-forme EJB a généralement fourni ses propres outils qui liraient ce descripteur de déploiement et éventuellement généré un ensemble de classes qui implémenteraient les interfaces Home et Remote désormais obsolètes.

Depuis EJB 3.0 ( JSR 220 ), le descripteur XML est remplacé par les annotations Java définies dans l'implémentation Enterprise Bean (au niveau source), bien qu'il soit toujours possible d'utiliser un descripteur XML à la place (ou en plus) des annotations. Si un descripteur XML et des annotations sont tous deux appliqués au même attribut dans un Enterprise Bean, la définition XML remplace l'annotation de niveau source correspondante, bien que certains éléments XML puissent également être additifs (par exemple, une propriété activation-config en XML avec un un nom différent de celui déjà défini via une annotation @ActivationConfigProperty sera ajouté au lieu de remplacer toutes les propriétés existantes).

Variantes de conteneurs

À partir de EJB 3.1, la spécification EJB définit deux variantes du conteneur EJB; une version complète et une version limitée. La version limitée adhère à un sous - ensemble approprié de la spécification appelé EJB 3.1 Lite et fait partie du profil Web de Java EE 6 (qui est lui-même un sous-ensemble de la spécification Java EE 6 complète).

EJB 3.1 Lite exclut la prise en charge des fonctionnalités suivantes:

• Interfaces distantes
• Interopérabilité RMI-IIOP
• Points de terminaison du service Web JAX-WS
• Service de minuterie EJB (@Schedule, @Timeout)
• Invocations de bean session asynchrones (@Asynchronous)
• Beans pilotés par message

EJB 3.2 Lite exclut moins de fonctionnalités. En particulier, il n'exclut plus @Asynchronous et @ Schedule / @ Timeout, mais pour @Schedule, il ne prend pas en charge l'attribut "persistent" que l'EJB 3.2 complet prend en charge. La liste complète des exclus pour EJB 3.2 Lite est:

• Interfaces distantes
• Interopérabilité RMI-IIOP
• Points de terminaison du service Web JAX-WS
• Minuteries persistantes (attribut "persistent" sur @Schedule)
• Beans pilotés par message

Historique des versions

EJB 4.0, version finale (22/05/2020)

Jakarta Enterprise Beans 4.0 , dans le cadre de Jakarta EE 9, était une version d'outillage qui déplaçait principalement les noms de packages d'API du package de niveau supérieur javax.ejb vers le jakarta.ejb package de niveau supérieur .

D'autres modifications ont inclus la suppression des API obsolètes qui étaient inutiles pour passer au nouveau package de niveau supérieur et la suppression des fonctionnalités qui dépendaient de fonctionnalités qui ont été supprimées de Java ou ailleurs dans Jakarta EE 9. Les API suivantes ont été supprimées:

• méthodes reposant sur java.security.Identity qui a été supprimé de Java 14.
• méthodes reposant sur Jakarta XML RPC pour refléter la suppression de XML RPC de la plateforme Jakarta EE 9.
• EJBContext.getEnvironment() méthode obsolète .
• "Prise en charge de l'interopérabilité distribuée" pour refléter la suppression de CORBA de Java 11 et de la plate-forme Jakarta EE 9.

D'autres modifications mineures incluent le marquage du groupe d'API Enterprise Beans 2.x comme "facultatif" et le fait de rendre l' Schedule annotation répétable.

EJB 3.2.6, version finale (23/08/2019)

Jakarta Enterprise Beans 3.2 , dans le cadre de Jakarta EE 8, et malgré l'utilisation de l'abréviation "EJB", cet ensemble d'API a été officiellement renommé "Jakarta Enterprise Beans" par la Fondation Eclipse afin de ne pas marcher sur Oracle "Java "marque déposée.

EJB 3.2, version finale (2013-05-28)

JSR 345 . Enterprise JavaBeans 3.2 était une version relativement mineure qui contenait principalement des clarifications de spécification et levait certaines restrictions imposées par la spécification, mais avec le temps, elle ne semblait pas servir de véritable objectif. Quelques fonctionnalités d'EJB complètes existantes ont également été exigées pour être dans EJB 3 lite et la fonctionnalité qui était proposée pour être élaguée dans EJB 3.1 a en effet été élaguée (rendue facultative).

Les fonctionnalités suivantes ont été ajoutées:

• La passivation d'un bean session avec état peut être désactivée via l'attribut sur l'annotation @Stateful (passivationCapable = false)
• TimerService peut récupérer tous les temporisateurs actifs dans le même module EJB (auparavant, il ne pouvait récupérer que les temporisateurs du bean dans lequel le TimerService était appelé)
• Les méthodes de cycle de vie (par exemple @PostConstruct) peuvent être transactionnelles pour les beans session avec état en utilisant l'annotation @TransactionAttribute existante
• Interface autoclosable implémentée par un conteneur intégrable

EJB 3.1, version finale (2009-12-10)

JSR 318 . L'objectif de la spécification Enterprise JavaBeans 3.1 est de simplifier davantage l'architecture EJB en réduisant sa complexité du point de vue du développeur, tout en ajoutant de nouvelles fonctionnalités en réponse aux besoins de la communauté:

• Vue locale sans interface (vue sans interface)
• Emballage .war des composants EJB
• EJB Lite: définition d'un sous-ensemble d'EJB
• Noms JNDI globaux d'EJB portables
• Singletons (haricots de session singleton)
• Événements d'initialisation et d'arrêt de l'application
• Améliorations du service de minuterie EJB
• Asynchronisme simple (@Asynchrone pour les beans session)

EJB 3.0, version finale (11/05/2006)

JSR 220 - Modifications majeures : cette version a rendu beaucoup plus facile l'écriture d'EJB, en utilisant des «annotations» plutôt que les «descripteurs de déploiement» complexes utilisés dans la version 2.x. L'utilisation d'interfaces domestiques et distantes et le fichier ejb-jar.xml n'étaient plus nécessaires dans cette version, ayant été remplacés par une interface métier et un bean qui implémente l'interface.

EJB 2.1, version finale (2003-11-24)

JSR 153 - Changements majeurs :

• Prise en charge du service Web (nouveau): les beans session sans état peuvent être appelés via SOAP / HTTP . En outre, un EJB peut facilement accéder à un service Web à l'aide de la nouvelle référence de service.
• Service de minuterie EJB (nouveau): mécanisme basé sur les événements pour appeler des EJB à des moments spécifiques.
• Les beans gérés par message acceptent les messages provenant de sources autres que JMS .
• Des destinations de message (la même idée que les références EJB, les références de ressources, etc.) ont été ajoutées.
• Ajouts au langage de requête EJB (EJB-QL): ORDER BY, AVG, MIN, MAX, SUM, COUNT et MOD.
• Le schéma XML est utilisé pour spécifier les descripteurs de déploiement, remplace les DTD

EJB 2.0, version finale (22/08/2001)

JSR 19 - Changements majeurs : Objectifs généraux :

• L'architecture de composant standard pour la création d'applications métier orientées objet distribuées en Java .
• Rendre possible la création d'applications distribuées en combinant des composants développés à l'aide d'outils de différents fournisseurs .
• Facilitez l'écriture d'applications (d'entreprise): les développeurs d'applications n'auront pas à comprendre les détails de la gestion des transactions et des états de bas niveau, le multi-threading, le regroupement de connexions et d'autres API complexes de bas niveau.
• Suivra la philosophie «Ecrire une fois, exécuter n'importe où» de Java . Un bean entreprise peut être développé une fois, puis déployé sur plusieurs plates-formes sans recompilation ni modification du code source.
• Traitez les aspects de développement, de déploiement et d'exécution du cycle de vie d'une application d'entreprise.
• Définissez les contrats qui permettent aux outils de plusieurs fournisseurs de développer et de déployer des composants pouvant interagir lors de l'exécution.
• Soyez compatible avec les plates-formes de serveur existantes. Les fournisseurs pourront étendre leurs produits existants pour prendre en charge les EJB.
• Soyez compatible avec d'autres API Java .
• Fournit l'interopérabilité entre les Enterprise Beans et les composants Java EE ainsi que les applications de langage de programmation non Java.
• Être compatible avec les protocoles CORBA (RMI-IIOP).

EJB 1.1, version finale (17/12/1999)

Changements majeurs :

• Descripteurs de déploiement XML
• Contextes JNDI par défaut
• RMI sur IIOP
• Sécurité - axée sur les rôles et non sur les méthodes
• Prise en charge de Entity Bean - obligatoire, non facultative

Objectifs de la version 1.1:

• Fournir un meilleur support pour l'assemblage et le déploiement d'applications.
• Précisez plus en détail les responsabilités des différents rôles EJB.

EJB 1.0 (24/03/1998)

Annoncé à JavaOne 1998 , troisième conférence des développeurs Java de Sun (du 24 au 27 mars) Objectifs de la version 1.0:

• Définition des «rôles EJB» distincts assumés par l'architecture des composants.
• Définition de la vue client des beans enterprise.
• Définition de la vue du développeur Enterprise Bean.
• Définition des responsabilités d'un fournisseur de conteneurs EJB et d'un fournisseur de serveurs; Ensemble, ils forment un système qui prend en charge le déploiement et l'exécution des beans enterprise.

Les références

Liens externes

• Site officiel
• Javadocs API Java EE 8
• Javadocs API EJB 3.0
• La spécification EJB 3.0
• Tutoriel EJB 3.0 de Sun
• Glossaire EJB (3.0)
• FAQ EJB
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• "Travailler avec des beans pilotés par message" d'EJB3 en action, deuxième édition
• Le client appelle un EJB