What are the major differences between EJB 2 and EJB 3?
What are the different Session Beans types?
EJB Session Beans;
EJB 2 vs EJB 3
- Simpler lookup process in EJB 3 than in EJB 2. In EJB 2, the developer used to have to define beans which implemented interfaces (home/local/remote/business/…) which extended EJB interfaces (EJBHome/EJBLocalHome/EJBObject/EJBLocalObject)…, and that implied to manage technical EJB exceptions, to define lifecycle methods, to provide callbacks implementation to help the EJB container to trigger the beans lifecycle events properly. In brief, that really used to make the devoloper’s focus away from the business to implement and to drawn in the technical sides of the technology. In EJB 3, a bean is a POJO and has to implement at most one local/remote interface which is a POJO too. Who does still want to learn EJB 2? I don’t! At all. At all.
- Introduction of annotations in EJB 3 which makes life easier for the developer. And we are no longer obliged to define our beans in the XML file ejb-jar.xml.
- EJB 3 has killed Entity Beans for Data Access which were boilerplate by implementing the interface javax.ejb.EntityBean and enforcing the developer to provide implementation for many methods : ejbLoad, ejbStore, ejbActivate, and ejbPassivate… and has brought to life the JPA specification. JPA specification is not tied to EJB 3. But it’s just so easy to inject a JPA Entity Manager in an EJB container.
- EJB 3 has better performance than EJB 2 as the container doesn’t have to execute callbacks such as ejbActive, ejbStore,…
So what is typical about Session Beans?
Session Beans are Server-Side components which expose a view for the client to invoke upon, which means that a Session Bean won’t take an action unless the client send a request.
A Session Bean is not accessed directly, but it has instances deployed in the EJB Container (WildFly in our case). So, the client request is sent to a kind of a proxy (the view) which by its turn delegates processing the client request to the EJB Container, and it’s up to the EJB Container to choose the right SB instance to make the job.
There are 3 Session Beans types :
- Stateless Session Beans
- Stateful Session Beans
- Singleton Beans
Stateless Session Beans (SLSB)
Imagine you have a box that has a dozen of blue pens, of endless ink *genius*.
Whenever you need to write down a word, you close your eyes then you pick up any blue pen from the box. You use the pen to write down the word then you put it back to the box.
Being of endless ink, you theoretically didn’t change the state of any blue pen. And regarding the purpose of a blue pen that is producing a blue hand script, any pen can do the same business!
And so it’s the same for a stateless bean. An EJB container would have a pool of Stateles SB. And according to the internal selection algorithm to the container, the client can get any instance of the Stateless SB.
Annotation : @Stateless
My recommended way to get a SLSB : Injection.
Stateful Session Beans (SFSB)
I gave you a cookie. You ate from the cookie.
Trust me. You have changed the state of the cookie since the cookie’s volume has reduced. And so, no pooling is allowed.
Moreover, we really cannot eat the same cookie at the same time, in case you like sharing. And if I accept your offer, I will have to wait for you to stop eating the cookie! Many people can request to eat the same cookie, but we cannot eat it all together the same time.
What would be interesting, is to give each one of us a cookie. Then each cookie information will be bound to the consumer : cookie.eatenVolume, cookie.eatingSpentTime, cookie.tasteRate, cookie.textureRate,…
Technically talking, Stateful Session Beans maintain conversational state and are dedicated to one client. But only one client at a time can use the Stateful Session Bean as the SFSBs are not multi-threaded. A SFSB can process concurrent requests. However these calls do not actually access the bean concurrently.
We typically choose a Stateful Session Bean, when we really need to bind an object state to a client. However, what you should keep in mind is that a SFSB is not contextualized. Imagine that you get a SFSB within an HTTP Session. Don’t expect the container to free the SFSB once the HTTP Session expires. You are responsible on your SFSB and you have got to destroy it programmatically. So you can put a listener on your session, then destroy the SFBS when your session expires.
Annotation : @Stateful
My recommended way to get a SFSB : JNDI lookup.
Instead of implementing the Singleton Design Pattern, you can create a Singleton Bean in a nutshell.
Whenever you have the constraint of creating one single instance, you can declare it as a singleton. So, even in case you had a distributed application, every module will access to the same instance.
A singleton is multi-threaded. So a concurrent access is possible. A Singleton can maintain state too, and so we can modify an instance’s attributes. To avoid concurrency issues, care to manage it, for example by using synchronized keyword.
A Singleton initialization can be eager as it can be lazy.
Lazy initialization : The singleton will be initialized when called for the first time.
Eager initialization : The singleton will be initialized on deployment using the annotation : @Startup
Annotation : @Singleton
My recommended way to get a SFSB : Injection