What is an Enterprise Java Bean really?

Question

On the Tomcat FAQ it says: \"Tomcat is not an EJB server. Tomcat is not a full J2EE server.\"

But if I:

• use Spring to supply an application context
<

Answer 1

But if I add (...) then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?

No, you don't have a Java EE application server, a full-fledged Java EE application server is more than Tomcat + Spring + a standalone Transaction Manager. And even if you add a JMS provider and an EJB container, you still won't have a Java EE server. The glue between all parts is IMO important and is part of the added value of a Java EE container.

Regarding EJBs, the EJB specification is much more than JPA and specifices also Session Beans and Message Driven Beans (actually, I don't really consider JPA Entities as EJBs even if JPA is part of the EJB 3.0 specification in Java EE 5 for historical reasons - which is not true anymore in Java EE 6, JPA 2.0 and EJB 3.1 are separate specifications). I should also mention that a Spring bean annotated with @Transactional is not equivalent to a Session Bean. A Java EE container can do more things with Session Beans (see below). You may not need them though but still, they are not strictly equivalent.

Last thing, Java EE containers implement a standard, the Spring container does not, it is proprietary.

What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?

As I said, I think that the "glue" is a part of the added value and highly contributes to the robustness of the whole. Then, ewernli's answer underlined very well what is difficult to achieve. I'd just add:

• Clustering and Fail-over (to achieve fault-tolerance)
• Administration facilities

Yes, a good Java EE server will do pretty neat things to improve fault tolerance (clustering of connection pools, JNDI tree, JMS destinations, automatic retry with idempotent beans, smart EJB clients, transaction recovery, migration of services, etc). For "mission critical" applications - the vast majority are not - this is important. And in such cases, libraries on top of the Servlet API are IMO not a replacement.