Besides EAR and EJB, what do I get from a J2EE app server that I don't get in a servlet container like Tomcat?

We use Tomcat to host our WAR based applications. We are servlet container compliant J2EE applications with the exception of org.apache.catalina.authenticator.SingleSignOn.

We are being asked to move to a commercial J2EE application server.

1. The first downside to changing that I see is the cost. No matter what the charges for the application server, Tomcat is free.
2. Second is the complexity. We don't use either EJB nor EAR features (of course not, we can't), and have not missed them.

What then are the benefits I'm not seeing?

What are the drawbacks that I haven't mentioned?

---

Mentioned were...

1. JTA - Java Transaction API - We control transaction via database stored procedures.
2. JPA - Java Persistence API - We use JDBC and again stored procedures to persist.
3. JMS - Java Message Service - We use XML over HTTP for messaging.

This is good, please more!

From stackoverflow

• Hi,

  Cost isn't necessarily a downside as there a few free J2EE servers, e.g. JBoss and Glassfish.

  Your question assumes that (J2EE = Servlet + EJB + EAR) and therefore, there's no point in using anything more than a Servlet container if you're not using EJB or EAR. This is simply not the case, J2EE includes a lot more than this. Examples include:

  • JTA - Java transaction API
  • JPA - Java persistence API
  • JMS - Java messaging specification
  • JSF - technology for constructing user interfaces out of components

  Cheers, Donal

  dacracot : We use JSF without a J2EE container.

  dacracot : I haven't mentioned the specific J2EE app server so that it wouldn't be the subject of flaming, but it does come with a price tag.

  Don : I'm not saying that you need to use a J2EE app server to use any of these technologies, just making the point that there's more to J2EE than EJB, Servlets and EAR.

• Unless you want EJB proper, you don't need a full stack J2EE server (commercial or not).

  You can have most J2EE features (such as JTA, JPA, JMS, JSF) with no full stack J2EE server. The only benefit of a full stack j2ee is that the container will manage all these on your behalf declaratively. With the advent of EJB3, if you need container managed services, using one is a good thing.

  You can also have no cost full stack server such as Glasfish, Geronimo or JBoss.

  You can also run embedded j2ee container managed services with embedded Glasfish for example, right inside Tomcat.

  You may want an EJB container if you want to use session beans, message beans, timer beans nicely managed for you, even with clustering and fail over.

  I would suggest to the management to consider upgrades based on feature need. Some of these EJB containers might just well use embedded Tomcat as their webserver so what gives!

  Some managers just like to pay for things. Ask them to consider a city shelter donation or just go for BEA.

  Don : JBoss uses Tomcat as the embedded servlet container

• If you are being asked to move to a commercial J2EE server, the reasons may have nothing to do with the J2EE stack but with non-technical considerations.

  One thing that you do get with a commercial J2EE offering that you don't get with Tomcat is technical support.

  This may not be a consideration for you, depending on the service levels your web applications are supposed to meet. Can your applications be down while you try and figure out a problem with Tomcat, or will that be a major problem?

• In truth, with the vast array of packages and libraries available, there's little an EJB container provides that can't be added to a modern servlet container (ala Tomcat). So, if you ever wanted any of those features, you can get them "ala carte" so to speak with the cost being the process of integrating that feature in to your app.

  If you're not "missing" any of these features now, then from a practical standpoint, you probably don't need them.

  That all said, the modern EJB containers are really nice, and come with all of those services pre-integrated, making them, somewhat, easier to use should you ever want them. Sometimes having the feature nearby and handy is enough to make someone explore it for its potential in their application, versus seeing the integration process of a feature as a hurdle to adoption.

  With the quality of the free EJB containers, it's really hard to imagine how buying one can be at all useful, especially given that you have no real demand for one at the moment.

  However, I do encourage you to actually get one and play around with it and explore the platform. Glassfish is very easy to get started with and very good, and should easily take your WARs as is (or with very minor tweaks).

  As a rule when it comes between running Tomcat vs an EJB container the question is really why NOT use one? Speaking specifically for Glassfish, I find it easier to use than Tomcat, and It's primary difference is that it can have a moderately larger memory footprint (particularly for a small application) than Tomcat, but on a large application you won't even notice that. For me, the memory hit isn't a big deal, for others it may be an issue.

  And it gives me a single source of all this nice functionality without having to crawl the net for a 3rd party option.

  Thorbjørn Ravn Andersen : A distinct advantage of deploying an EAR is that all the wiring can be specified inside, instead of having to set up Tomcat explicitly for providing several additional services. The more that can be automated the better.

  Jonik : Great answer, and by far the clearest one here. What you say mostly matches my understanding of the matter: if using Tomcat, no real need to switch as you can add almost any JEE feature anyway, but if starting afresh, it's probably easier to go with a good, free app server like JBoss or Glassfish.