Is it correct to use full Java EE in this approach and not just across the Web and resiliency layer?
I want to create a website for managing sports statistics. Let's say football statistics. I want to pusblish the front end of the site with a good presentation to the public, no login required.
I am creating a second site for the football league offices. On these sites, football leagues will register their playlist so that each player's statistics will be calculated from that game. This is where the league will register instructors, categories (age range) and players.
I am using full Java Java architecture. Develop an EJB project common to both front-end and back-office web applications, as well as Front End and Back Office as I mentioned. I plan to use gates for both sites. But I am planning to publish a 1GB RAM VPS with Glassfish 3.
Another option is to create a shared project (eclipse) and make 2 webapps using this shared project. This shared project is a JPA project and has some common dependencies (Apache commons lang) that I will use across all projects. So deploy to tomcat and go through.
So, I am confused and ask some specific questions:
- Should I use static methods (I can deploy to tomcat, less than I use RAM) o stateless Beans session (needs an EE app server) for these services?
- Should I use wickets for the Front End since Wicket is low-key and I'm going to be stateless here? where can i find a tutorial on stateless wicket?
I feel like I'm sorry as I don't understand when a bean is used. Should I go for full EE or just use the Web and Persistence layer.
----- Update ------ I'm actually the only developer and I only have experience with gates for the web level.
I'm not sure about using a front gate as the statefull and front end will just show the information to everyone.
The separation of web tier and front end is due to the fact that I have different website designs / templates, one more beautiful (FE) mlb.com style and another admin (beautiful forms and components). I bought two website templates.
Its a project that I want to develop and learn. Its commercial and I foresee expanding this application to support other sports like tennis, basketball, etc.
Each developer will have their own preferences and guidelines.
From my personal development experience, EJBs have become much less "heavy / cumbersome" when moving from the EJB 2.1 specification to EJB 3.0.
At this point, EJB 3.0 is only annotated POJOs. However, I would not recommend using a stateless EJB without considering that you need the functionality provided by the EJB container (such as container-managed transaction / rollback).
if you need a large full stack that can run on Tomcat
without the need for a Java EE Container, I would recommend Grails . It will include your web tier (in the form of GSP and Taglib) and will also provide you with a persistence level (GORM) so you can grow very quickly.
Now, to be completely honest, 1GB of RAM shines a bit for Grails. I believe this will work, but I would like at least 2GB of RAM if I was running the Grails stack.
You can also consider Spring Web MVC for your web tier and Spring beans for your service layer and plug in JPA / Hibernate for your persistence layer.
I personally am not familiar with Wicket in detail (I know about this, but I have no practical experience). However, some quick searches showed articles on integrating with Spring.
source to share
If it was me, I would look at using the Spring framework. I would create a persistence layer using JPA, 2 client applications communicating with this persistence layer using Spring MVC and whatever presentation technology you would like (simplify it with Velocity, Freemarker, JSP. Deploy via Tomcat. To use EE - from what you described, you only need the servlet container, nothing else that the Java EE server will bring.
source to share