Usando un Stateful Session Bean para rastrear la sesión de un usuario

Question

es mi primera pregunta aquí y espero que lo esté haciendo bien.

Necesito trabajar en un proyecto Java EE, entonces, antes de comenzar, intento hacer algo simple y ver si puedo hacer eso.

Estoy atrapado con Stateful Session Beans.

Aquí está la pregunta: ¿Cómo puedo usar un SFSB para hacer un seguimiento de la sesión de un usuario? Todos los ejemplos que vi terminaron en "poner" SFSB en un atributo HttpSession. ¡Pero no entiendo por qué! Quiero decir, si el frijol es ESTATAL, ¿por qué tengo que usar el HttpSession para mantenerlo?

¿La tarea del contenedor EJB no es devolver el derecho SFSB al cliente?

Lo he intentado con un simple contador de frijoles. Sin usar la sesión, dos navegadores diferentes tienen el mismo contador de beans (al hacer clic en "incrementar" se cambia el valor para ambos). Al usar la sesión, tengo dos valores diferentes, cada uno para cada navegador (haciendo clic en "incrementar" en Firefox, agregué uno solo al bean de Firefox).

Pero mi maestro dijo que un SFSB mantiene el "estado de conversación con un cliente", así que por qué no solo trabaja sin utilizar un HttpSession?

Si he entendido bien, no está usando HttpSession con un SFSB el mismo de hacerlo con un SLSB en su lugar?

Espero que mi (s) pregunta (s) sea (n) clara (s) y que mi inglés no sea tan pobre.

EDIT: Estoy trabajando en un sistema de inicio de sesión. Todo va bien y después de completar el inicio de sesión me lleva a una página de perfil que muestra los datos del usuario. ¡Pero volver a cargar la página hace que mis datos desaparezcan! He intentado agregar HttpSession durante el inicio de sesión pero al hacerlo de esta manera, los datos se mantienen incluso después del cierre de sesión.

Answer 1

Un Stateful Session Bean (SFSB) tiene que combinarse con la sesión HTTP en un entorno web, ya que es un negocio puro que no sabe nada acerca de la capa web.

Tradicionalmente los EJB incluso obligatorios vivían dentro de su propio módulo (el módulo EJB), que ni siquiera podían acceder a los artefactos web si querían. Este es un aspecto de los sistemas estratificados. Consulte Packaging EJB in JavaEE 6 WAR vs EAR para obtener más información al respecto.

Los clientes originales para Stateful Session Beans fueron, entre otras, las aplicaciones de escritorio Swing, que se comunicaban con el servidor EJB remoto a través de un protocolo binario. Una aplicación Swing obtendría una conexión a un bean de sesión Stateful remoto a través de un objeto proxy/stub. Incluido en este proxy hay una identificación de algún tipo que el servidor puede asociar con un SFSB específico.Al aferrarse a este objeto proxy, el cliente Swing puede realizarle llamadas repetidas y éstas irán a la misma instancia de bean. Esto creará una sesión entre el cliente y el servidor.

En el caso de una aplicación web, cuando un navegador realiza una solicitud inicial a una aplicación web Java EE obtiene un JSESSIONID que el servidor puede asociar con una instancia específica HTTPSession. Al aferrarse a este JSESSIONID, el navegador puede proporcionarle con cada solicitud de seguimiento y esto activará la misma sesión del servidor http.

Por lo tanto, esos conceptos son muy similares, pero no se mapean automáticamente entre sí.

El navegador solo obtiene el JSESSIONID y no tiene conocimiento de ninguna ID de SFSB. A diferencia de la aplicación Swing, el navegador se comunica con páginas web, no directamente con beans Java.

Para asignar la solicitud del cliente a un bean de sesión con estado específico, el contenedor EJB solo se preocupa por la ID proporcionada a través del proxy SFSB. No puede ver si la llamada se originó a partir de un código en el módulo web y no puede/no debería realmente acceder a ningún contexto HTTP.

La capa web que es el código de cliente que accede al SFSB debe 'retenerse' a una referencia de proxy específica. Aferrarse a algo en la capa web normalmente significa almacenarlo en la sesión HTTP.

Sin embargo, existe una tecnología de puente llamada CDI que puede hacer esta conexión automática. Si anota su SFSB con CDI @SessionScoped y obtiene una referencia a SFSB a través de CDI (por ejemplo, usando @Inject), no tiene que colocar manualmente su SFSB en la sesión http. Sin embargo, detrás de escena CDI hará exactamente eso de todos modos.

Answer 2

es necesario definir el grano con @SessionScoped en lugar de @RequestScoped (si es que busca HttpSession solución equivalente)

algo así como

@SessionScoped 
public class SessionInfo implements Serializable{ 
    private String name; 
    public String getName() { 
     return name; 
    } 
    public void setName(String name) { 
     this.name = name; 
    } 
} 

un vistazo a continuación (que se explica en detalle)

http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html