Packaging EJB in JavaEE 6 WAR vs EAR

Question

Starting a new project and would like to know the pros and cons of packaging EJB in a WAR vs EAR.

Will JNDI still works when EJBs are in the WAR? efficiency? etc.?

Thanks.

Solution 1

An important motivation for having EJB beans in a separate JAR is for the age old separation of business logic and view logic.

Since EJBs are supposed to concentrate solely on business logic, it makes sense to put them into a separate module.

This is exactly what the traditional Java Enterprise Archive facilitates. The EJB beans go into a JAR file which represents the EJB module, while the web related artifacts (Facelets, backing beans, utility code) go into a Web Archive (WAR) file which represents the Web module. Note that a WAR doesn't actually have to be a file. In the so-called exploded format they are merely directories.

A key aspect of this separation is that those two modules are isolated via a class loader hierarchy. The Web module has access to resources (typically beans) from the EJB module, and the EJB module can reference resources (typically libraries) defined in the overall EAR umbrella. The other direction is not possible. Specifically, the EJB module cannot access any resources defined in the Web module.

This enforcement is deliberate.

Business logic should be completely independent of any view technology. Enforcing this isolation prevents developers from accidentally or when under pressure mixing those concerns anyway. The benefits of this separation is that business logic can trivially be used by among others Java SE clients, Web module clients, JAX-RS clients, etc. If the business logic accidentally had JSF or Servlet dependencies, it would be very hard to use it from Java SE clients.

Compare this with Facelets not allowing scriptlets to be used. This keeps the Facelets clean and let them focus on component layout and markup exclusively. Another analogy is with coding to interfaces, which separates the contract from the implementation.

So having a separate EJB module is actually a best practice. However...

For smaller projects it might be unnecessary to have this separation and for beginning programmers it might be difficult to wrap their heads around the structure of what needs to go where. Removing the mandatory separation thus makes it easier for inexperienced developers to start with Java EE. It gives them a gentle introduction into Java EE and later once they get the idea of layering, they can then opt to introduce an EJB module anyway.

Solution 2

So far this is what I got.

EJB in WAR

pros:

1. Simpler to develop and deploy

2. You can expose Session Bean methods as REST service with @Path annotation. See here

cons:

1. JNDI lookup is not supported, so I believe you cannot do RMI from another application client

2. As arjan pointed out it lacks modularity in design.

Solution 3

i think that what you need to keep in mind is that EJB inside a WAR is part of EJB Lite, which is a nice effort to make an application running with the minimum services provided by an EJB container. Because you don't always need all the services provided by an EJB container.

So, if you wonder about the pros and cons of packaging EJB in a WAR or in a EAR, then you should think about how much services do you need.

HTH.

Solution 4

I'm currently studying some guide for EJB 3.1 certification and have to test every feature of it. And all are available when using a war.

It's very different EJB Lite from WAR packaging.

You can have some of logical modularity using ejb jars that you can include in your web project. But all the modules share the same environment (jndi) so some name collisions could happen. In a EAR project each module has it's own namespace.

Solution 5

I did some experiment on this topic and really surprised on the result. My conclusion was never use EJB in WAR. Let's leave the job for the EJB container so if anybody want to get the best and error free development use EAR instead.

When I worked EJB in WAR using NetBeans 7.1.3, Glassfish 3.1.2.2 and JRebel for faster development I have realized that JRebel only works perfect with reloading changes made in EJB modul if it was deployed in an EAR package. If I made simple WAR package the classloader behaved absolutely strange way during development phase and caused a lot of random bugs.

Anyhow the war package in normal deployment worked perfect as mentiod by others.

Also in a WAR package the changes in NamedQuery strings did not apear after save and compile. If I packaged into EAR the development was smooth and fast. Of course this could be a bug also in JRebel.

View more solutions