Beans de sesión Java EE

Programación

1. Introducción

Los beans de sesión empresariales se pueden clasificar en términos generales en:

  1. Beans de sesión sin estado
  2. Beans de sesión con estado

En este artículo rápido, vamos a discutir estos dos tipos principales de beans de sesión.

2. Configuración

Para usar Enterprise Beans 3.2 , asegúrese de agregar la última versión a la sección de dependencias del archivo pom.xml :

 javax javaee-api 7.0 provided
La última dependencia se puede encontrar en el repositorio de Maven. Esta dependencia asegura que todas las API de Java EE 7 estén disponibles durante el tiempo de compilación. El alcance proporcionado asegura que una vez implementado; la dependencia la proporcionará el contenedor donde se ha implementado.

3. Frijoles sin estado

Un bean de sesión sin estado es un tipo de bean empresarial que se usa comúnmente para realizar operaciones independientes. No tiene ningún estado de cliente asociado, pero puede conservar su estado de instancia.

Echemos un vistazo a un ejemplo para demostrar cómo funciona un bean sin estado.

3.1 Creación del bean sin estado

Primero, creemos el bean StatelessEJB . Usamos la anotación @Stateless para marcar el bean como sin estado:

@Stateless public class StatelessEJB { public String name; }

Luego creamos el primer cliente del bean sin estado anterior, llamado EJBClient1 :

public class EJBClient1 { @EJB public StatelessEJB statelessEJB; }

Luego declaramos otro cliente, llamado EJBClient2, que accede al mismo bean sin estado:

public class EJBClient2 { @EJB public StatelessEJB statelessEJB; }

3.2 Prueba del bean sin estado

Para probar la apatridia del EJB, podemos usar los dos clientes que declaramos anteriormente de la siguiente manera:

@RunWith(Arquillian.class) public class StatelessEJBTest { @Inject private EJBClient1 ejbClient1; @Inject private EJBClient2 ejbClient2; @Test public void givenOneStatelessBean_whenStateIsSetInOneBean _secondBeanShouldHaveSameState() { ejbClient1.statelessEJB.name = "Client 1"; assertEquals("Client 1", ejbClient1.statelessEJB.name); assertEquals("Client 1", ejbClient2.statelessEJB.name); } @Test public void givenOneStatelessBean_whenStateIsSetInBothBeans _secondBeanShouldHaveSecondBeanState() { ejbClient1.statelessEJB.name = "Client 1"; ejbClient2.statelessEJB.name = "Client 2"; assertEquals("Client 2", ejbClient2.statelessEJB.name); } // Arquillian setup code removed for brevity }

Comenzamos inyectando los dos clientes EBJ en la prueba unitaria.

Luego, en el primer método de prueba, establecemos la variable de nombre en el EJB que se inyectó en EJBClient1 en el valor Cliente 1. Ahora, cuando comparamos el valor de la variable de nombre en ambos clientes, deberíamos ver que el valor es igual . Esto muestra que el estado no se conserva en beans sin estado .

Demostremos que esto es cierto de una manera diferente. En el segundo método de prueba, vemos que una vez que establecemos la variable de nombre en el segundo cliente, esta 'sobrescribe' cualquier valor que se le haya dado a través de ejbClient1 .

4. Frijoles con estado

Los beans de sesión con estado mantienen el estado tanto dentro como entre transacciones. Es por eso que cada bean de sesión con estado está asociado con un cliente específico. Los contenedores pueden guardar y recuperar el estado de un bean automáticamente mientras administran grupos de instancias de beans de sesión con estado.

4.1 Creación del Bean con estado

Un bean de sesión con estado se marca con la anotación @Stateful . El código para el bean con estado es el siguiente:

@Stateful public class StatefulEJB { public String name; }

El primer cliente local para nuestro bean con estado se escribe de la siguiente manera:

public class EJBClient1 { @EJB public StatefulEJB statefulEJB; }

También se crea un segundo cliente llamado EJBClient2 al igual que EJBClient1 :

public class EJBClient2 { @EJB public StatefulEJB statefulEJB; }

4.2 Prueba del Stateful Bean

La funcionalidad del bean con estado se prueba en la prueba unitaria EJBStatefulBeanTest de la siguiente manera:

@RunWith(Arquillian.class) public class StatefulEJBTest { @Inject private EJBClient1 ejbClient1; @Inject private EJBClient2 ejbClient2; @Test public void givenOneStatefulBean_whenTwoClientsSetValueOnBean _thenClientStateIsMaintained() { ejbClient1.statefulEJB.name = "Client 1"; ejbClient2.statefulEJB.name = "Client 2"; assertNotEquals(ejbClient1.statefulEJB.name, ejbClient2.statefulEJB.name); assertEquals("Client 1", ejbClient1.statefulEJB.name); assertEquals("Client 2", ejbClient2.statefulEJB.name); } // Arquillian setup code removed for brevity }

Como antes, los dos clientes EJB se inyectan en la prueba unitaria. En el método de prueba, podemos ver que el valor de la variable de nombre se establece a través del cliente ejbClient1 y se mantiene aunque el valor del nombre establecido a través de ejbClient2 sea ​​diferente. Esto demuestra que se mantiene el estado de EJB .

5. Bean de sesión sin estado o con estado

Ahora echemos un vistazo a la principal diferencia entre los dos tipos de beans de sesión.

5.1 Frijoles sin estado

  • Los beans de sesión sin estado no mantienen ningún estado con el cliente. Por esta razón, se pueden usar para crear un grupo de objetos que interactúan con múltiples clientes.
  • Dado que los beans sin estado no tienen ningún estado por cliente, tienen un mejor rendimiento
  • Pueden manejar múltiples solicitudes de múltiples clientes en paralelo y
  • Puede usarse para recuperar objetos de bases de datos

5.2 Beans con estado

  • Los beans de sesión con estado pueden mantener el estado con varios clientes y la tarea no se comparte entre los clientes
  • El estado dura por la duración de la sesión. Después de que se destruye la sesión, el estado no se conserva
  • El contenedor puede serializar y almacenar el estado como un estado obsoleto para uso futuro. Esto se hace para ahorrar recursos del servidor de aplicaciones y para soportar fallas de bean y es pasivación.
  • Puede usarse para resolver problemas de tipo productor-consumidor

6. Conclusión

Así que hemos creado dos tipos de beans de sesión y los clientes correspondientes para invocar los métodos de los beans. El proyecto demuestra el comportamiento de los dos tipos principales de beans de sesión.

Como siempre, el código fuente del artículo está disponible en GitHub.