Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A Stateful Session Bean (SFSB) has to be combined with the HTTP session in a web environment, since it's a pure business bean that itself knows nothing about the web layer.</p> <p>Traditionally EJBs even mandatory lived inside their own module (the EJB module), that couldn't even access web artifacts if they wanted to. This is an aspect of layered systems. See <a href="https://stackoverflow.com/questions/4441237/packaging-ejb-in-javaee-6-war-vs-ear/4539419#4539419">Packaging EJB in JavaEE 6 WAR vs EAR</a> for more information about that.</p> <p>The original clients for Stateful Session Beans were among others Swing desktop applications, that communicated with the remote EJB server via a binary protocol. A Swing application would obtain a connection to a remote Stateful Session Bean via a proxy/stub object. Embedded in this proxy is an ID of some kind that the server can associate with a specific SFSB. By holding on to this proxy object, the Swing client can make repeated calls to it and those will go to the same bean instance. This will thus create a session between the client and the server.</p> <p>In the case of a web application, when a browser makes an initial request to a Java EE web application it gets a <code>JSESSIONID</code> that the server can associate with a specific <code>HTTPSession</code> instance. By holding on to this <code>JSESSIONID</code>, the browser can provide it with each followup request and this will activate the same http session server-side.</p> <p>So, those concepts are very similar, but they do not automatically map to each other.</p> <p>The browser only gets the <code>JSESSIONID</code> and has no knowledge about any SFSB ID. Unlike the Swing application, the browser communicates with web pages, not directly with Java beans.</p> <p>For mapping the client's request to a specific stateful session bean, the EJB container only cares about the ID provided via the SFSB proxy. It can't see if the call happened to originate from code in the web module and can't/shouldn't really access any HTTP contexts.</p> <p>The web layer being the client code that accesses the SFSB must 'hold on' to a specific proxy reference. Holding on to something in the web layer typically means storing it in the HTTP session.</p> <p>There is however a bridge technology called <code>CDI</code> that can make this automatic connection. If you annotate your SFSB with CDI's <code>@SessionScoped</code> and obtain a reference to the SFSB via CDI (e.g. using <code>@Inject</code>), you don't have to manually put your SFSB into the http session. However, behind the scenes CDI will do exactly that anyway.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload