Qu'est-ce que l'EJB? L'évolution des Enterprise JavaBeans

Enterprise JavaBeans (EJB) est une spécification pour le développement d'applications commerciales distribuées à grande échelle sur la plate-forme Java. EJB 1.0 a été publié en 1998. La version la plus récente, EJB 3.2.3, a été adoptée pour être incluse dans Jakarta EE, où elle sera renommée Jakarta Enterprise Beans.

Architecture EJB

L'architecture EJB se compose de trois composants principaux: les beans entreprise (EJB), le conteneur EJB et le serveur d'applications Java. Les EJB s'exécutent dans un conteneur EJB et le conteneur EJB s'exécute dans un serveur d'applications Java.

Il existe deux types d'EJB: les beans session et les beans gérés par message:

  • Les beans session sont appelés par le client et mettent à la disposition du client des fonctionnalités d'entreprise telles que les transactions et la gestion des ressources par programmation.
  • Les beans gérés par message encapsulent et fournissent également des fonctionnalités d'entreprise, mais ils sont asynchrones et événementiels. Les beans gérés par message écoutent et répondent aux événements, et ne peuvent pas être appelés par le client.

Autrefois utilisés pour assurer la persistance dans le système EJB, les beans entité ont été supplantés par l'API Java Persistence. Continuez à lire pour en savoir plus sur les beans session et les beans gérés par message.

EJB vs JavaBeans

Enterprise JavaBeans a été le premier modèle de développement basé sur des composants pour Java EE. EJB est similaire aux JavaBeans en ce qu'il est basé sur des composants, mais c'est là que s'arrête la similitude:

  • Un JavaBean est une classe Java qui encapsule plusieurs objets et se conforme à certaines conventions. Les JavaBeans sont principalement utilisés pour le développement côté client.
  • Un bean entreprise (EJB) est une classe Java dotée de capacités spécifiques côté serveur. Les beans entreprise sont utilisés dans des applications et des systèmes d'entreprise à grande échelle.

Beans de session

Un bean session est le type le plus générique de bean entreprise, représentant une partie de la fonctionnalité métier qui peut être appelée par un client. Dans ce cas, le client peut être une autre classe de la JVM locale ou un appel distant.

Le conteneur EJB gère le cycle de vie du bean session, qui est déterminé par l'état du bean:

  • Les beans session sans état sont similaires à la portée de la requête dans l'API Java Servlet. Les beans session sans état contiennent une partie de la fonctionnalité appelable, mais sont autrement sans état.
  • Les beans session avec état sont associés à un seul client et attachés à la session en cours de ce client. Les beans session avec état fonctionnent de la même manière que la portée de session dans l'API Servlet.
  • Les beans singleton sont similaires à la portée de l'application dans l'API Servlet. Un bean session singleton n'existe qu'une seule fois pour chaque client.

Sécurité des threads avec les beans session

Un bean session avec état n'est accessible que par un client à la fois, donc la sécurité des threads est garantie lorsque vous travaillez avec ce type de bean. Les beans session sans état et les beans singleton sont plus flexibles, permettant des connexions simultanées, qui doivent être gérées par le développeur. Vous êtes responsable de la sécurité des threads lorsque vous travaillez avec ces types de beans.

Beans pilotés par message

Les beans gérés par message (MDB) sont appelés via des messages JMS (Java Message Service). JMS fonctionne comme un modèle de commande distribué, dans lequel le bean géré par message joue le rôle d'écouteur de la commande. Lorsqu'un message arrive sur un sujet ou une file d'attente, le bean géré par message écoutant ce sujet est appelé.

Les beans gérés par message ne sont pas aussi couramment utilisés que les beans session, mais ils sont puissants. Étant asynchrones et pilotés par les événements, ils sont particulièrement utiles pour les travaux de longue durée où il est important de conserver les ressources.

L'architecture la plus simple consisterait en l'application EJB et son conteneur et son serveur, qui se coordonnent avec le service de messagerie traitant les MDB. En production, votre architecture inclurait probablement un troisième composant dédié à la consommation des beans. En développement, tous ces composants pourraient fonctionner sur la même machine locale.

La figure 1 montre une architecture événementielle typique avec des beans gérés par message.

Matthew Tyson

Travailler avec des beans gérés par message est plus complexe que des beans session. Dans un environnement événementiel, vous aurez généralement besoin d'un courtier de messages comme ActiveMQ.

Alors que les beans session sont plus simples et donc plus couramment utilisés dans les EJB, les architectures événementielles sont devenues populaires, en particulier avec l'explosion des microservices. 

Annotations EJB

La définition et la consommation des beans enterprise était un point de friction pour de nombreux développeurs jusqu'à EJB 3.0, qui a introduit des annotations dans la spécification EJB. Les annotations facilitent la configuration des beans entreprise pour un large éventail de fonctionnalités présentes dans Java EE. Continuez à lire pour commencer avec les annotations EJB.

@Stateless: définir un bean session sans état

Afin de désigner une classe comme bean session sans état, vous utilisez l' javax.ejb.Statelessannotation, comme indiqué dans le Listing 1.

Listing 1. Exemple d'annotation @Stateless

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

Ce bean sans état contient une signature simple qui ne prend aucun argument et renvoie une chaîne. Cependant, ne vous laissez pas tromper par la simplicité: ce bean peut faire tout ce dont vous avez besoin, y compris interagir avec d'autres beans, services ou la couche de données de votre application.

@EJB: consommer un bean session sans état

Une fois que vous avez défini un bean session, son utilisation est si simple:

Listing 2. Exemple d'annotation @EJB

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Here, we inject the stateless bean into a servlet, and then it's available for use. Notice how the bean is identified under the @EJB annotation. The "stateless" designation tells us this bean will not track the client. Because it's stateless, we also know this bean is subject to threading if it does any work outside the invoked method.

@Remote: Define a remote EJB interface

In the above examples, I assumed the EJB and EJB client were running in the same JVM. If the enterprise bean and its client are running in separate JVMs, then the EJB must define a @Remote interface. In this case, it's up to you to define and implement the interface, as shown in Listing 3.

Listing 3. @Remote annotation example

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

The remote interface is sent to the client to invoke. Calls to it will then be fulfilled by the EJB's server-side implementation. The MyStatelessBean example in Listing 4 implements the remote interface.

Listing 4. Implementing a remote interface

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

A remote interface is implemented just like a normal class implementing an interface. As the consumer of a remote EJB, the client application must be able to access the class definition for the remote interface. You can package the class definition for the remote interface as a dependency JAR.

Local vs remote interface

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

Enterprise JavaBeans a été la première spécification à offrir un moyen simple d'encapsuler et de réutiliser la logique métier dans les applications Java d'entreprise. Loin du monstre lourd de l'ancien, EJB est aujourd'hui un framework allégé basé sur des annotations qui vous permet d'accéder à un large éventail de fonctionnalités d'entreprise, dès la sortie de la boîte. Pensez à EJB la prochaine fois que l'on vous demandera de monter rapidement une application métier distribuée et évolutive. Tu pourrais être agréablement surpris.

Cette histoire, "Qu'est-ce que EJB? L'évolution des Enterprise JavaBeans" a été initialement publiée par JavaWorld.