The best way to learn a technology is building a project. This is why we will make a Solution Design as an example of multiple possible usage of EJB3.
Here we will describe the game experience of the quizz, a light solution design (every components would be used excelusively in a given tutorial and not all of them at once).
In the 1st page, the player has a form to fill name to start the game and information about how many quizzes have been played. In real life, the number of the played quizzes (by others) increases everyday, and must be persisted in in a database, but for tutorial purposes, this number is bound to deployment memory and initialized to 0. Once we shutdown the Application Server the number of played quizzes is lost.
So to start the quiz the player must click on “Start!” :
Then automatically an addition formula is generated that the player must answer :
The number of the played quizzes increases. This number is not bound to this same player, but increases every time some one play the quiz.
If the player gives a good answer, his score increases, otherwise the quiz ends and the game is redirected to another page showing greeting him by name and showing him his score and giving him a to play again :
If the player wants to play again he is asked to fill his name again as in the first IHM.
An EJB3 Solution Design
In this diagram, I tried to contextualize the clients and the EJBs :
- Application Server 1 : WildFly instance 1 which will deploy our Session Beans and expose them via the Business Interfaces. This same instance can deploy a Session Bean client. From the point of view of Container, we can consider this client as local since it is deployed in the same EJBs Container.
Important (!) : We will discover later that the client being in the same Container does not guarantee @Local view usage for invoking a Session Bean.
- Application Server 2 : WildFly instance 2 which will deploy our second client. This time it is about a remote client, which means client and the Session Beans are deployed in different EJBs Containers. In this case, for sure we need a @Remote view to be exposed.
- Standalone Client : No Application Server deploying the client. Instead, we will have a JNDI Lookup within a static main method.
Technical Big Lines
During this serie of tutorials we will create 10 projects each one with a purpose :
- Business Interfaces Project.
- Session Beans Implementation Project.
- Session Beans Implementation Wrapper Project (uncoupling purposes).
- The Session Beans implementation and Client packaged in the same WAR.
- Client packaged in a WAR and aimed to be deployed in the same Container as the Session Beans WAR.
- Client packaged in a WAR and aimed to be added to an EAR together with ejb3-server-war. It’s the EAR which will be deployed.
- The EAR which will package the EJB Client WAR and the EJB Server WAR.
- JNDI Lookup Utilities.
- Remote Client WAR project that will be deployed in a different Container (Application Server 2).
- Standalone Client Project (Main class for invoking EJBs).