Apache Tomcat EJB Integration FAQ

As a growing number of organizations abandon heavy, bloated Java EE stacks for lightweight Apache Tomcat-based infrastructure, "life after EJBs" is becoming a popular topic.

In this FAQ, we'll answer common questions about using Apache Tomcat with EJBs, from embedded containers to code migration.


Q: What is an EJB?


A: EJB, which stands for Enterprise Java Bean, is a Java EE technology created in an attempt to standardize all elements of business logic code under a single interface. Enterprise JavaBeans use container-based management to provide features such as persistence, events and messaging, RPCs, security, concurrency, and transaction processing. The EJB standard, which was first introduced in 1997, has experienced a rocky adoption history. EJB 1.0 and 2.0 were considered confusing and bloated by many members of the Java community, as the technology took a limiting "all or nothing" approach to implementation.

Problems with EJB were a major impetus toward the development of lightweight alternatives to EJB-like functions, such as Spring, Hibernate, Google Guice, and more. In response to the general failure of the first two standards, EJB 3.0 featured a completely overhauled API, mirroring many features of the lightweight frameworks that had replaced it. As these frameworks still work very well and are widely used, the overall value and adoption of the new EJB model remains to be seen.

Q: Is Apache Tomcat an "EJB Container"? Can Tomcat use EJBs?


A: The simple answer to this question is no. EJB is part of the larger Java EE platform. As Tomcat only implements the Servlet specification, EJBs cannot be natively hosted within Tomcat.

Q: Is there any way to add EJB support to Apache Tomcat?

A: Yes. With the help of a few additional components, Tomcat is more than capable of handling EJBs. The most common way to add EJB support to Apache Tomcat is to embed the Apache OpenEJB container within the Tomcat server.

Using OpenEJB with Tomcat provides servlets with full EJB 3 capabilities, and even supports the older EJB 2 and 1 models. This includes features such as JMS, JTA, JPA, JavaMail, and EJB Annotations. OpenEJB also allows EJB/JPA components to be contained within standard WAR files through the use of additional class annotations.

OpenEJB use with Tomcat is very common and reliable, and the OpenEJB project provides a simple guide to embedding OpenEJB in Tomcat here, complete with example applications.

Q: I want EJB-like features (transaction support, persistence, etc.), but I don't want to use EJBs. Is there any way that I can get Java EE functionality without using a heavyweight Java EE server?

A: Yes. While EJBs are useful tools, and EJB 3.0 has done much to fix common complaints levied against earlier versions of the technology, they are not the only option for enterprise Java applications. Many enterprise applications are actually much simpler to write as POJOs, or do not require the complexity of the entire Java EE platform or a Java EE application server, where using EJBs might be more warranted.

Lightweight frameworks such as Spring, Google Guice, or even tiny PicoContainer use dependency injection models to provide Java EE-like features via a more modular, application-centric programming model, and are a viable alternative to EJBs.

Q: Is it possible to migrate an EJB application to Tomcat? How much work is involved?

A: Yes, it's possible. How much work it will take depends on the application. While an inpdividual application may not use many EJB-reliant components, it is common for enterprise applications to rely on multiple layers of service, security, persistence, and transaction management code, which is often implemented using Enterprise JavaBeans. Thus, for larger applications with multiple layers, full migration to Tomcat can be an extended process, as services are rebuilt around alternative, modular technologies.

The realities of migration should not dissuade an organization from launching a migration project - re-factoring code away from EJBs can often result in a much more modular, stable, lightweight infrastructure, with components that can be easily re-used in both future migration projects and new applications. Another benefit of separating the functions of an infrastructure out of the EJB framework is the ability to quickly implement new developments in infrastructure, as each layer is more abstracted and self contained.

Q: What about management? Does Tomcat have any administrative tooling, like some Java EE servers?

A: Out of the box, Tomcat does not include most of the administrative features an enterprise user might expect, such as deployment to multiple instances, diagnostics, application provisioning, centralized configuration management, and so on. This is not necessarily a bad thing - steady resistance to non-core features in favor of lightweight power is a key reason why Tomcat has been the most widely used application server in the industry for so many years.

However, the lack of these features can be a major barrier to migration for many users. The majority of organizations that migrate from Java EE to Tomcat invest some time in implementing some sort of administrative functionality on top of Tomcat.

MuleSoft's Tcat Server is one of the most popular solutions for enterprise Tomcat administration. Built on 100% Apache Tomcat, with zero modifications to core binaries, Tcat Server's centralized management console provides intuitive enterprise administrative features, such as configuration management, diagnostics and monitoring, application provisioning, group deployment, and reliable restarts to enterprise Tomcat users.

One reason why Tcat Server is so popular is the openness of its pricing model - the full version of Tcat Server is complete free to development teams through the pre-production stage of development. To try Tcat Server today, or test-drive an online demo version of the product, click here.