¿Qué es EJB? La evolución de Enterprise JavaBeans

Enterprise JavaBeans (EJB) es una especificación para desarrollar aplicaciones comerciales distribuidas a gran escala en la plataforma Java. EJB 1.0 se lanzó en 1998. La versión más actual, EJB 3.2.3, se adoptó para su inclusión en Jakarta EE, donde pasará a llamarse Jakarta Enterprise Beans.

Arquitectura EJB

La arquitectura EJB consta de tres componentes principales: enterprise beans (EJB), el contenedor EJB y el servidor de aplicaciones Java. Los EJB se ejecutan dentro de un contenedor EJB y el contenedor EJB se ejecuta dentro de un servidor de aplicaciones Java.

Hay dos tipos de EJB: beans de sesión y beans controlados por mensajes:

  • Los beans de sesión son invocados por el cliente y hacen que la funcionalidad empresarial, como las transacciones y la gestión de recursos, esté disponible para el cliente mediante programación.
  • Los beans controlados por mensajes también encapsulan y brindan funcionalidad empresarial, pero son asincrónicos y controlados por eventos. Los beans controlados por mensajes escuchan y responden a eventos, y el cliente no puede invocarlos.

Una vez utilizados para proporcionar persistencia en el sistema EJB, los beans de entidad han sido reemplazados por la API de persistencia de Java. Siga leyendo para obtener más información sobre los beans de sesión y los beans controlados por mensajes.

EJB vs JavaBeans

Enterprise JavaBeans fue el primer modelo de desarrollo basado en componentes para Java EE. EJB es similar a JavaBeans al estar basado en componentes, pero ahí es donde termina la similitud:

  • Un JavaBean es una clase Java que encapsula múltiples objetos y se ajusta a ciertas convenciones. Los JavaBeans se utilizan principalmente para el desarrollo del lado del cliente.
  • Un enterprise bean (EJB) es una clase Java imbuida de capacidades específicas del lado del servidor. Los beans empresariales se utilizan en aplicaciones y sistemas comerciales a gran escala.

Frijoles de sesión

Un bean de sesión es el tipo más genérico de enterprise bean, que representa una parte de la funcionalidad empresarial a la que puede llamar un cliente. El cliente en este caso podría ser otra clase en la JVM local o una llamada remota.

El contenedor EJB administra el ciclo de vida del bean de sesión, que está determinado por el estado del bean:

  • Los beans de sesión sin estado son similares al alcance de la solicitud en la API de Java Servlet. Los beans de sesión sin estado contienen una parte de la funcionalidad invocable pero, por lo demás, no tienen estado.
  • Los beans de sesión con estado están asociados con un solo cliente y se adjuntan a la sesión en curso de ese cliente. Los beans de sesión con estado funcionan de manera similar al alcance de la sesión en la API de Servlet.
  • Los beans singleton son similares al alcance de la aplicación en la API de Servlet. Un bean de sesión singleton existe solo una vez para cada cliente.

Seguridad de subprocesos con beans de sesión

Solo un cliente puede acceder a un bean de sesión con estado a la vez, por lo que la seguridad de los subprocesos está garantizada cuando se trabaja con este tipo de bean. Los beans de sesión sin estado y los beans singleton son más flexibles, lo que permite conexiones simultáneas, que deben ser administradas por el desarrollador. Usted es responsable de la seguridad de los subprocesos cuando trabaja con este tipo de beans.

Beans controlados por mensajes

Los beans controlados por mensajes (MDB) se invocan mediante mensajes JMS (Java Message Service). JMS funciona como un patrón de comando distribuido, donde el bean controlado por mensajes actúa como el oyente del comando. Cuando llega un mensaje a un tema o cola, se invoca el bean controlado por mensajes que escucha sobre ese tema.

Los beans controlados por mensajes no se utilizan con tanta frecuencia como los beans de sesión, pero son potentes. Al ser asincrónicos y controlados por eventos, son especialmente útiles para trabajos de larga duración en los que es importante conservar recursos.

La arquitectura más simple consistiría en la aplicación EJB y su contenedor y servidor, que se coordinan con el servicio de mensajes que procesa los MDB. En producción, su arquitectura probablemente incluiría un tercer componente dedicado a consumir los beans. En desarrollo, todos estos componentes podrían ejecutarse en la misma máquina local.

La Figura 1 muestra una arquitectura típica impulsada por eventos con beans controlados por mensajes.

Matthew Tyson

Trabajar con beans controlados por mensajes es más complicado que usar beans de sesión. En un entorno impulsado por eventos, normalmente necesitará un agente de mensajes como ActiveMQ.

Si bien los beans de sesión son más simples y, por lo tanto, se usan más comúnmente en EJB, las arquitecturas controladas por eventos se han vuelto populares, especialmente con la explosión de los microservicios. 

Anotaciones EJB

Definir y consumir beans empresariales fue un punto de fricción para muchos desarrolladores hasta EJB 3.0, que introdujo anotaciones en la especificación EJB. Las anotaciones facilitan la configuración de beans empresariales para una amplia gama de funciones que se encuentran en Java EE. Siga leyendo para comenzar con las anotaciones EJB.

@Stateless: define un bean de sesión sin estado

Para designar una clase como un bean de sesión sin estado, use la javax.ejb.Statelessanotación, como se muestra en el Listado 1.

Listado 1. Ejemplo de anotación @Stateless

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

Este bean sin estado contiene una firma simple que no toma argumentos y devuelve una cadena. Sin embargo, no se deje engañar por la simplicidad: este bean puede hacer todo lo que necesite, incluida la interacción con otros beans, servicios o la capa de datos de su aplicación.

@EJB: consumir un bean de sesión sin estado

Una vez que haya definido un bean de sesión, usarlo es muy simple:

Listado 2. Ejemplo de anotación @EJB

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

Aquí, inyectamos el bean sin estado en un servlet y luego está disponible para su uso. Observe cómo se identifica el frijol debajo de la @EJBanotación. La designación "sin estado" nos dice que este bean no rastreará al cliente. Debido a que no tiene estado, también sabemos que este bean está sujeto a subprocesos si realiza algún trabajo fuera del método invocado.

@Remote: define una interfaz EJB remota

En los ejemplos anteriores, asumí que el cliente EJB y EJB se estaban ejecutando en la misma JVM. Si el enterprise bean y su cliente se ejecutan en JVM independientes, el EJB debe definir una @Remoteinterfaz. En este caso, depende de usted definir e implementar la interfaz, como se muestra en el Listado 3.

Listado 3. Ejemplo de anotación @Remote

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

La interfaz remota se envía al cliente para que la invoque. Las llamadas a él serán luego cumplidas por la implementación del lado del servidor de EJB. El MyStatelessBeanejemplo del Listado 4 implementa la interfaz remota.

Listado 4. Implementación de una interfaz remota

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

Una interfaz remota se implementa como una clase normal que implementa una interfaz. Como consumidor de un EJB remoto, la aplicación cliente debe poder acceder a la definición de clase para la interfaz remota. Puede empaquetar la definición de clase para la interfaz remota como un JAR de dependencia.

Interfaz local vs remota

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 fue la primera especificación que ofreció una forma fácil de encapsular y reutilizar la lógica empresarial en aplicaciones empresariales Java. Lejos de ser el gigante de peso pesado de antaño, EJB hoy es un marco esbelto basado en anotaciones que le permite acceder a una amplia gama de funcionalidades empresariales, de inmediato. Considere EJB la próxima vez que se le pida que desarrolle rápidamente una aplicación comercial escalable y distribuida. Puede que se sorprenda gratamente.

Esta historia, "¿Qué es EJB? La evolución de Enterprise JavaBeans" fue publicada originalmente por JavaWorld.