Difference between running EJB from WAR vs. separate EJB container

Question

Are there any differences in capabilities of the EJB when defining / running it from a WAR vs. an EJB container? What are the benefits vs. drawbacks of deciding on one approach vs. other.

What capabilities do we lose when accessing it from a WAR?

In our case, the developers want to use the EJB for creating / accessing REST webservice.

One of our architects has mentioned below. And for this reason he wants to have a separate EJB that would be added ( the jar ) to EAR but also to WAR for using it as REST endpoint. i would prefer not to have it in multiple places

I’d prefer our approach to put transaction/service based code in EJBs to 
leverage Container Managed Transactions, JPA, MDB and all the good stuff EJBs 
have to offer.

From the documentation I have read on using EJB as a REST service implementation, it says

Add the EJB class to the WEB-INF/classes directory of your WAR file or to a 
JAR that is located in your WEB-INF/lib directory. When a client makes a request 
to a JAX-RS annotated enterprise bean, the JAX-RS runtime environment looks up 
and uses an EJB instance of the class to invoke the resource method.

So, I want to know, if we put the EJB in the WAR - as in creating the source in the WAR's source so that the class will be added to WEB-INF/classes when the WAR is built, instead of having to put the same ejb jar in two different places based on what it is used for - as a REST webservice endpoint vs. other capabilities, will it satisfy all the requirements or I will have to put the jar in two places?

I am using Websphere 8.5 with EJB 3.1, if that makes a difference in the answer.

Answer 1

There are two primary differences highlighted in section 15.4 of the EJB 3.1 specification:

1. All EJBs in a WAR share the component namespace (java:comp) with the WAR and all other EJBs in the WAR. Normally, each EJB has its own component namespace. This makes it easier to share reference names and bindings (though this can be done explicitly in EE 6 with java:module or java:app), but it increases the chance of conflict in a large WAR.
2. EJB classes are loaded by the WAR class loader. In practice, this doesn't matter much, it's just something to be aware of if you encounter class loading problems.

If you want to use an EJB as a REST service, you must package the EJB in the WAR. If you're concerned about "duplicating" EJB logic inside the WAR and for an EJB module, you could declare a base class in the EJB module, and then declare subclasses in the WAR and EJB modules that extend the base class and are annotated @Stateless or @Singleton.

Answer 2

Regarding EJB capabilities there is no difference between packaging an EJB in a WAR or in an EJB module.

There are situations where you have to package EJBs in WARs e.g. if you have a REST endpoint which is at the same time an EJB.

Most often WARs encapsulate frontend functionality. In these situations it is just from a design perspective not advisable to put the EJBs into WARs.