I never used stateful EJBs. I understand that a stateful EJB can be useful with a java client.
But i wonder: in which case to use them on a web application? And how? Should we put these stateful beans in Session (because of stateless http)?
Is it a good practice? (without debating too much about stateful vs stateless)
A stateful session bean is a type of enterprise bean, which preserve the conversational state with client. A stateful session bean as per its name keeps associated client state in its instance variables. EJB Container creates a separate stateful session bean to process client's each request.
An instance of a stateful session bean has a unique identity that is assigned by the container at create time. Stateless: A stateless session bean does not maintain conversational state. Instances of a stateless session bean have no conversational state.
Session beans typically have the following characteristics: Represent a conversation between client and server. Execute on behalf of single client. They cannot be shared by more than one client at the same time.
EJB is a server-side software element that summarizes business logic of an application. Enterprise Java Beans web repository yields a runtime domain for web related software elements including computer reliability, Java Servlet Lifecycle (JSL) management, transaction procedure and other web services.
Funny enough, it's a 2nd question on SFSB and web app for the day, while this topic is usually not that common.
in which case to use them on a web application?
The traditional example of SFSB and web app is the shopping cart. But at the same time, you can do the same with the HttpSession
.
Ideally, if the state relates to the business logic and not the presentation logic, it should go in a SFSB. But in practice, people usually advocates against SFSB (because of the complexity it introduces) unless they provide something you can not do easily with the HttpSession
. Most of the time, you can tweak the design to store the information in the HttpSession
or the database and pass it around, without the need to have SFSB. But it's ultimately a question of design purity.
And how? Should we put these stateful beans in Session (because of stateless http)?
The EJB model is a richer model than the HttpSession
, because EJB are transactional components, and there are explicit callbacks for the passivation and activation of SFSB. This comes with an increased complexity about how to use SFSB correctly, notably (1) exception handling and (2) concurrency and (2) removal and time-out of SFSB. See my answers here for more details:
If you want to use them, you will need first to look up the SFSB to get a reference to one fresh remote instance. Then you will need to store this reference somewhere in a way to reuse it across requests. This somewhere is usually the HttpSession
, which means that even if you use SFSB, you can't get rid of it completely.
With EJB2, the remote reference -- called a handle -- could be serialized to be reused later. It was then possible to store if for instance in database, even though I've never seen that. I don't know if it's still possible with EJB3.
Is it a good practice?
As I said already, people usually advice against it unless you know exactly why you would use them rather than the HttpSession
and only if you have a good command of the EJB model. (SFSB could be justified for instance if the business service is accessible through a web front-end and a desktop client) Lots of other frameworks don't have something similar as SFSB and people still manage to create great apps with them.
PS: I've used SFSB in a web app, and it can indeed be a trickier to use than the HttpSession
, but it ultimately worked.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With