Note that Tomcat is an Application Server. That said, in October we released Apache TomEE which is Tomcat with the missing JavaEE parts added, then Java EE 6 certified using the official TCK from Oracle.

The stack evolved from what used to be simply called "OpenEJB/Tomcat", which was a useful stack with a bad name :) Commonly overlooked because of the "EJB" part, meanwhile it also delivered Transactions, JMS, WebServices and more to Tomcat. The new name is far better and now it s officially certified like JBoss or GlassFish. We re pretty excited about its future.

If I understand well, you want to use EJB3/JPA within a servlet container.

There are not only stand-alone implementations of JPA, but also embeddable EJB3 container, such as OpenEJB or Glassfish embeddable container. So nothing prevents you from starting such an embeddable container from the Servlet container to use EJB3.

(Note: I don t know all the details about transactions. In a full-blown app. server, you have JTA and a distributed transaction manager. You don t have that in a Servlet container such as Tomcat. JPA works with JTA and plain JDBC, but I don t know exactly how an embeddable container work without JTA. Still, I guess that would work given that such embeddable containers are also meant for unit-testing where I guess there is no JTA distributed transaction manager.)

Another approach would be to use Spring. Spring and EJB3 have indeed become very similar. You can start the Spring DI container within the Servlet container and benefit more or less from the same facilities as EJB3 (declarative transactions, etc.). See this post about Spring vs. EJB3.

All these technologies have become pretty modular, especially with Java EE profiles. You can use Sevlets, EJB3, JMS, JPA, even JTA somehow independently of one other. You can also create an environment where you cherry pick the ones you would like, either with Spring or with Java EE. The question is when does it stop to make sense and rather use an app. server with everything available and easily manageable. I think Servlet/EJB3/JPA is the limit, if more is needed go for an app. server.

You will generally require some kind of container, even if that container doesn t provide Java EE-related services. After all, you do need a long-lived JVM process to host the code that you re executing. Tomcat and Jetty will do the job nicely, and in addition to basic servlet services, provide a few useful extras that will be relevant, like connection pooling.

J2EE without application server was introduced years ago by me (Guy Pardon, from Atomikos), with this seminal article: http://www.onjava.com/pub/a/onjava/2006/02/08/j2ee-without-application-server.html - focused on JMS and JDBC at the time.

In general it s easy to setup thanks to Spring and Hibernate. Actually, I got inspired to do this after doing a Java EE project and being confronted with the XML hell associated with app servers and EJBs. Without application server things suddenly became a lot simpler and more testable.

If you need a Tomcat installation then can be a bit more of a hassle to configure, but recently Atomikos has introduced out-of-the-box Tomcat integration as part of its commercial offering at http://www.atomikos.com.

HTH