File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Newbie Question: Java EE vs Tomcat+Hibernate+Struts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Newbie Question: Java EE vs Tomcat+Hibernate+Struts" Watch "Newbie Question: Java EE vs Tomcat+Hibernate+Struts" New topic
Author

Newbie Question: Java EE vs Tomcat+Hibernate+Struts

Shane Magrath
Greenhorn

Joined: Oct 21, 2011
Posts: 4
I'm an experienced POJO programmer but recently have a requirement to build an Internet based Web application. I really haven't paid attention to all the Java based web technologies that have flowered in the last ten years. Now I'm playing catch up and I'm pretty confused! I want to develop an Internet application with the usual mix of requirements: web front-end, database backend, competent security, etc and don't want to suffer rework from picking the wrong stack. The trick is I'm not really in a competent position to judge what's important. I don't want to invest myself in orphaned or legacy technology, and want to be able to purchase a reasonable hosting service at some point.

So, is Java EE (eg GlassFish) the way to go, or is the Tomcat/Hibernate/... stack still the main game for Internet applications?

Should I commit to JSF development or is JSP still the mainstream choice de jour?

Hosting providers: there appears to be emerging support for Java EE hosting providers but they seem more expensive than Tomcat++ providers? Or have I got this wrong?

CDI is kicked around as a big issue, but I'm not sure how to think about it in terms of my requirements. I guess it's probably a distraction.

I've got to say: starting web-based Java development is a pretty humbling experience given my competence in "ordinary" Java development (aka POJO and Swing): I certainly feel I'm not in Kansas anymore...

Karthik Shiraly
Ranch Hand

Joined: Apr 04, 2009
Posts: 497
    
    5
The good thing about java web frameworks is that there are so many of them. The bad thing about java web frameworks is that...well, there are so many of them!

Which stack to use depends on the nature of the application and its requirements in each tier.
Note that the choices you've given are in fact a superset and its subset. Tomcat's focus is the web tier standards and technologies of JavaEE - namely, servlets, JSP, and JSF - and some support for web tier clustering, authentication and database access.
Struts is not a JavaEE standard API, but very much based on the servlet and typically uses JSP as the view technology.
And Hibernate is a provider of the JPA persistence standard, one of the JavaEE standards.
JBoss and Geronimo JavaEE app servers both use Tomcat as their servlet container. And even Glassfish uses a derivative of Tomcat as its servlet container.
So whatever you choose, you're always choosing a subset of JavaEE. The question is which subset does the application need? For that, review each tier...

Web (presentation) tier:
The major categories here are
1) Page oriented frameworks: like Struts 1.x / 2.x, and Spring MVC
and
2) Component oriented frameworks: like JSF, Wicket, Vaadin, GWT

I usually choose based on how I want the user experience and user interface to be.

If I want something of a rich desktop-like experience with lots of in-page UI manipulation using ajax, I go for component oriented frameworks. They provide rich UI widgets, are cross-browser tested and have the class scaffolding necessary for getting data, handle pagination, etc. JSF is even event driven, giving it a Swing feel to it.
All this is possible even with the page oriented frameworks, but then you have to code all the javascript from scratch and you have to do the hard work of combining dumb HTML elements and their related javascript / ajax manipulation into cohesive UI "components". Even when using tested javascript frameworks like jQuery and jQuery UI, this can be time consuming (or atleast I've found it to be so...YMMV). So, I use page oriented frameworks only if the UI does not involve complex widgets and lot of in-page UI manipulation. When it doesn't, using page oriented frameworks is much much more pleasant compared to component oriented ones.
That said, if you're *learning* these, then learn both JSF and Struts/SpringMVC+JSP. You're sure to use one or both sometime or other.


Application / Business tier:
- Does your application logic require convenient horizontal scaling (which usually implies distributed application logic)? Do you anticipate so many users that you want to provision new nodes in a cluster quickly and conveniently?
- Does your application involve business logic workflows and business logic transactions (I don't mean just DB transactions...should the results of some business logic itself be rolled back?)?
- Does it require asynchronous batch processing or staged processing, using a messaging service?
- Does it require finegrained authorizations per use case, or is an entry level authentication enough?
- Does it involve multiple distributed databases or distributed database transactions?

If answer to one or more of these is a yes (especially the first one), then a full fledged, tested and tuned, battle ready JavaEE app server like Jboss or Glassfish is preferred.
It is possible to integrate one or more of these with Tomcat, and it may even work functionally, but then you can't be sure whether it'll fulfil all performance and security requirements till you have thoroughly tested it yourself.
If horizontal scalability is a must, then you probably should choose some "cloud" solution, because provisioning new nodes is easy and automated on demand, unlike regular hosting accounts where provisioning has to be done by your provider.

If your application logic is somewhat complex ("somewhat" is a subjective opinion here), then JavaEE6 has a reduced profile called the "Web profile". In web profile, you get all the web tier technologies, plus you also get a lightweight EJB standard, transactions and JPA - but not JMS, authorizations, etc. Both JBoss and Glassfish provide a Web Profile version.

If these are not necessary now, but you anticipate some of them, then Tomcat should be ok but ensure that the hosting account provides the freedom to install new components (that means prefer a VPS or dedicated server, and not a shared JVM).
You can deploy the business logic as simple POJOs in Tomcat itself.

In all these configurations, you have the option of using Spring framework. Now, Spring provides both *design* scaffolding, and it also provides *implementation* conveniences. So using Spring as a default glue makes sense to me, to keep the design flexible, as well as help write less code using its convenience helpers.

As for CDI, I confess I haven't found a good use for it. It's a convenience to reduce lines of code and keep design flexible, but when already using Spring, I have no idea how it helps. I think it's mainly used when you're not using Spring at all.

Data tier:
The JavaEE6 app servers provide JPA already (JBoss uses Hibernate, but Glassfish uses Toplink - that should not matter as long as only JPA interfaces and annotations are used).
If using Tomcat, you can deploy Hibernate as a JPA provider, but stick to the JPA interfaces, so that migration is easy in future.
Shane Magrath
Greenhorn

Joined: Oct 21, 2011
Posts: 4
Thanks - that was a great cut-through-cruft response. I think I'm stepping towards the whole Java EE thing... looks like some heavy reading coming up!
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Great write-up Karthik!

Just to add one thing:
Karthik wrote:As for CDI, I confess I haven't found a good use for it. It's a convenience to reduce lines of code and keep design flexible, but when already using Spring, I have no idea how it helps. I think it's mainly used when you're not using Spring at all.

The CDI is the response for the need of standardised flexible context-aware Dependency Injection for Java EE environement. Just as using Java EE application server with Spring doesn't make much sense, using CDI with Spring also doesn't. In the matter of fact, Spring brings their own implementation of CDI-based annotations like @Inject - they've just got their own mechanism for doing things the CDI does.

Also remember that there is a new player in the Java EE 6 world - TomEE which is a tomcat with required modules to become a Java EE 6 Web profile certified server.

Cheers!


OCP Java SE 6 Programmer, OCM Java SE 6 Developer, OCE Java EE 6 JSPSD, OCE Java EE 6 EJBD, OCE Java EE 6 JPAD, Spring 3.0 Core Professional.
Shane Magrath
Greenhorn

Joined: Oct 21, 2011
Posts: 4
This is what confuses me: why are there so many choices?

Some level of choice is good, but too much is not helpful. Why choose TomEE when Glassfish is already a viable OpenSource choice? Maybe it's a licensing thing, but ...

I'm not really competent enough yet to pick the important differences but my feeling is to back the Glassfish platform and get my hands dirty. Maybe then I'll be able to appreciate the differences of Spring vs JavaEE vs ... at this stage, I just don't want to pulled into the machinery and crushed by all the moving parts!
Karthik Shiraly
Ranch Hand

Joined: Apr 04, 2009
Posts: 497
    
    5
TomEE is rather new, still in beta and certified only recently. As we all know, software takes time to mature and stabilize. At this stage, I wouldn't consider using TomEE in production.
Glassfish and JBoss are good choices. Both are modular and allow unnecessary services to be deactivated. So it's possible to take Glassfish and JBoss, and strip them down to enable only required services.
Starting with one of them as an experimentation platform and evaluating them against your requirements is a necessary step.

As for why so many choices, I think it's because a strong "Not Invented Here" syndrome prevails in all the big open source backer companies, coupled with engineers' motivation to create. Creating is tough, whereas reusing is meh.
Often, a framework does most things well, but is weak in some aspects due to core design decisions. Improving it may not be feasible. In such cases, there is no alternative but to come up with a new implementation from scratch with different concepts to overcome those weaknesses.
Haven't we all re-implemented some things even when we knew they are already implemented, just for the thrill of it?
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Shane Magrath wrote:This is what confuses me: why are there so many choices?

Some level of choice is good, but too much is not helpful. Why choose TomEE when Glassfish is already a viable OpenSource choice? Maybe it's a licensing thing, but ...

I'm not really competent enough yet to pick the important differences but my feeling is to back the Glassfish platform and get my hands dirty. Maybe then I'll be able to appreciate the differences of Spring vs JavaEE vs ... at this stage, I just don't want to pulled into the machinery and crushed by all the moving parts!


The point is - talking about Java EE - you should just develop your application by obeying to the specification - this is your job. The platform in which you run your application should not be your concern (theoretically speaking). The way you develop your application depends on the Java EE specification - not the server specification. In this way different vendors can compete to give you the fastest, most scalable, easies to maintain, robust environment for your application.

The Glassfish 3.1 and JBoss AS 7 are really lightweight and fast. Glassfish 3.1 is Java EE Full Profile certified and JBoss AS 7 is Web Profile certified (altought it adds some of the Java EE Full Profile features). TomEE is just Web Profile.
Shane Magrath
Greenhorn

Joined: Oct 21, 2011
Posts: 4
All good comments, thanks.

Anyway, will push on and "slay the dragon"...

:-)
 
 
subject: Newbie Question: Java EE vs Tomcat+Hibernate+Struts