Directriz: Identificación de beans de sesión
Esta directriz trata la forma en que identificar y modelar beans de sesión para una aplicación J2EE.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Esta directriz se centra en identificar los beans de sesión. En la sección Directriz: beans de sesión se proporciona ayuda adicional sobre beans de sesión. En la sección Directriz: Enterprise JavaBeans (EJB) se proporciona ayuda adicional sobre EJB.

Identificación de beans de sesión

Las clases de control son a menudo buenas candidatas para beans de sesión, puesto que los beans de sesión se utilizan para proporcionar lógica de control, en particular cuando en esta lógica de control hay conversaciones con un cliente. Un bean de sesión a menudo también se identifica como una fachada para un conjunto de objetos en la capa empresarial (consulte la sección Patrón de fachada de sesión más adelante para obtener más información). Además desde J2EE 1.4, los beans de sesión sin estado se pueden utilizar para implementar servicios web.

Si está trabajando con J2EE 1.3, una práctica estándar es manejar todo el acceso de cliente remoto mediante EJB de sesión, que manipulan EJB de entidad en la misma JVM mediante interfaces de componente local.

Modelado de beans de sesión

Consulte la sección Directriz: identificación de Enterprise JavaBeans (EJB) para obtener más información.

Con estado frente a sin estado

Hay dos tipos de beans de sesión: con estado y sin estado. Un parte en la identificación de un bean es definir sus responsabilidades, una de las cuales puede ser el mantener el estado del cliente entre llamadas.

Los beans de sesión con estado mantienen información sobre la conversación entre el cliente y el contenedor EJB. Una instancia de bean de sesión con estado sólo existe mientras dura la conversación del cliente. Los beans de sesión con estado habitualmente realizan servicios con estos datos para el cliente. Los servicios que proporciona el bean de sesión con estado podrían coordinar las interacciones con otros objetos empresariales (beans de sesión y beans de entidad). Por ejemplo, un carro de la compra con objetos para comprar se podría implementar con un bean de sesión con estado, puesto que retiene la información mientras el cliente interactúa con la aplicación. Puesto que los beans de sesión con estado se asignan a un cliente específico, consumen más recursos de sistema que un bean de sesión sin estado frente a la ventaja de retener el estado del cliente. El contenedor maneja estos recursos, habitualmente colocando en un estado "pasivo" (escribiendo en disco) los beans de sesión con estado y reactivándolos cuando es necesario.

Los beans de sesión sin estado no retienen la información de estado en relación a la conversación entre el cliente y el contenedor EJB. "Sin estado" realmente significa que no hay estado de conversación del cliente. Por lo tanto, un bean de sesión sin estado puede tener otros tipos de estados, como el de una conexión con una base de datos que cualquier cliente podría utilizar. Los beans de sesión sin estado realizan servicios genéricos que no utilizan los datos de estado del cliente de llamadas de método anteriores, en todo caso, reciben todas las entradas relevantes como parámetros en la llamada de método actual, u obtienen los datos de otros orígenes durante la llamada al método (como desde beans de entidad o accediendo a bases de datos a través de JDBC). Habitualmente los beans de sesión se obtienen en una etapa Ready Pool y se entregan a medida que se necesitan para manejar las solicitudes entrantes. Puesto que todas las instancias son equivalentes, los beans de sesión sin estado no necesitan saber sobre su cliente. Esto permite incrementar el rendimiento y la escalabilidad. Los beans de sesión sin estado son más eficientes, puesto que una instancia se puede compartir entre solicitudes no contiguas, en lugar de "vincularlos" con una sesión concreta de actividad.

En general, se elige el tipo de bean de sesión que mejor se ajuste a la conversación con el cliente. Hay estrategias que permiten hacer que un bean de sesión con estado se comporte como un bean de sesión sin estado, como el que almacena el estado del cliente en el cliente y que lo reenvía en cada invocación, o bien almacenando y recuperando el estado del cliente de una base de datos en cada invocación de método. Estas estrategias, sin embargo, pueden hacer que se reduzcan las posibilidades de escalabilidad debido a sobrecarga de tráfico en la red y acceso a datos.

Si se crea el bean de sesión para implementar un servicio web, hay que utilizar un bean de sesión sin estado tal como se define en la especificación de la API JSR 1.3.

En la sección Directriz: diseño de estado para aplicaciones J2EE se cubren distintas estrategias para el diseño de estado del cliente.

Patrón de fachada de sesión

Con frecuencia, los beans de sesión se utilizan como una fachada que encapsula interacciones entre objetos en la capa empresarial. El bean de sesión sirve para abstraer esta complejidad, proporcionando una interfaz más simple a los clientes. Este patrón se describe en detalle en J2EE Patterns - Session Facade Pattern ([ALU01]).

Por ejemplo, en general es una buena práctica el quitar la lógica de bean entre entidades y colocarla en beans de sesión para minimizar el acoplamiento entre los beans de entidad. Se puede acceder a los beans de entidad mediante interfaces locales, puesto que la fachada del bean de sesión proporciona acceso a los clientes remotos. Esta aproximación es la más efectiva cuando hay varios beans de entidad estrechamente relacionados.

Punto final de servicios web

Como se ha visto con anterioridad, los beans de sesión sin estado se pueden utilizar para implementar servicios web. Este tipo de bean también se denomina un bean de implementación de servicio y debe cumplir los siguientes requisitos:

  • Debe tener un constructor público predeterminado.
  • Debe implementar todos los métodos que se declaran en la sección Interfaz de punto final de servicio y sus métodos deben ser públicos y no finales ni estáticos.
  • Debe ser sin estado.
  • La clase debe ser pública, y no final ni abstracta.

Consulte las secciones de las especificaciones EJB 2.1 y JSR 109 para obtener más información sobre los beans de sesión y la forma en que implementar los servicios web.