When is Spring + Tomcat not powerful enough?

Question

I've been reading/learning more about Spring lately, and how one would use Spring in combination with other open-source tools like Tomcat and Hibernate. I'm evaluating whether or not Spring MVC could be a possible replacement technology for the project I work on, which uses WebLogic and a LOT of custom-rolled J2EE code. The thing is, I've always suspected that our solution is over-engineered and WAY more complex than it needs to be. Amazingly, it's 2009, and yet, we're writing our own transaction-handling and thread-pooling classes. And it's not like we're Amazon, eBay, or Google, if you know what I mean. Thus, I'm investigating a "simpler is better" option.

So here's my question: I'd like to hear opinions on how you make the decision that a full-blown J2EE application server is necessary, or not. How do you "measure" the size/load/demand on a J2EE app? Number of concurrent users? Total daily transactions? How "heavy" does an app need to get before you throw up your hands in surrender and say, "OK, Tomcat just isn't cutting it, we need JBoss/WebLogic/WebSphere"?

Answer 1

Google open sources a lot of their code. If you're writing low-level things yourself, instead of implementing code that's already written, you're often overthinking the problem.

Back to the actual question, Walmart.com, etrade.com, The Weather Channel and quite a few others just use Tomcat. Marketing and sales guys from IBM would have you believe different, perhaps, but there's no upper limit on Tomcat.

Except for EJB, I'm not sure what Tomcat is missing, and I'm not a fan of EJB.

Answer 2

I don't think that the decision to use a full-fledged J2EE server or not should be based on number of users or transactions. Rather it should be based on whether you need the functionality.

In my current project we're actually moving away from JBoss to vanilla Tomcat because we realized we weren't using any of the J2EE functionality beyond basic servlets anyway. We are, however, using Spring. Between Spring's basic object management, transaction handling and JDBC capabilities, we aren't seeing a compelling need for EJB. We currently use Struts 2 rather than Spring's MVC, but I've heard great things about that. At any rate, Spring integrates well with a number of Java web frameworks.

Answer 3

Spring does not attempt to replace certain advanced parts of the JavaEE spec, such as JMS and JTA. Instead, it builds on those, making them consistent with the "Spring way", and generally making them easier to use.

If your application requires the power of the likes of JMS and JTA, then you can easily use them via Spring. Not a problem with that.

Answer 4

What tomcat does not offer apart from the more exotic elements of JEE is session beans (aka EJB's). Session beans allow you to isolate your processing efficiently. So you could have one box for the front end, another for the session beans (business logic) and another for the database.

You would want to do this for at least 2 reasons:

1. Performance; You're finding that one box to handle everything is loading the box too much. Separating the different layers onto different boxes would allow you to scale out. Session beans are also able to load balance at a more fine grained level. Tomcat and other web services of that ilk don't have clustering out of the box.
2. Flexibility; Now that you've moved your business logic into its own environment you could develop an alternate front end which used the same layer, but say, was a thick client front end for example. Or maybe other contexts would like to make use of the session beans.

Though I should probably point out that if you use web services to communicate with that middle tier, it could also be on tomcat!

Answer 5

Maybe this can be of interest:

http://onjava.com/onjava/2006/02/08/j2ee-without-application-server.html

HTH