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.

Mcalpine

Answer 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.

Legalize

So I can use all Java EE technologies in an application packaged in a WAR file? – Muriah

@MartinAndersson pretty much all of them indeed. Some exotic stuff still has to be deployed on its own or part of an EAR, like an application client container or (a bit less exotic) a JCA resource adaptor. But all 'normal' things, like CDI, EJB, JPA, JMS, JASPIC, etc can be packaged in a WAR file. – Legalize

you can have separation and still put ejb jar in web inf / lib correct? – Parrnell

you cant deploy ejbs in war in java ee 5 – Camerlengo

Ten years later I will say that I think people should use WAR packaging. We can achieve proper design separation using common conventions and diligence, the same as most other frameworks. JPA entities shouldn't call EJB methods, and EJB methods shouldn't call JSF beans: I don't need EAR files to enforce this. Also, I have yet to work on a project that actually reuses the business logic, and I don't think it's a good idea to complicate design in anticipation that "one day we will need it" -- usually that day never comes. – International

Answer 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.

Mcalpine

Though the spec does not require EJBs in WARs to be made remotely accessible, both JBoss7 and WebLogic12c allow you to access them from a standalone Java client. So JNDI lookup and invocation do work from a remote client. – Cambridge

Answer 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.

Phototype

That's what I wanted to know, are all the services that are available when EJBs are package in an EAR (separate in it's own EJB jar) still available when the EJBs are package in a WAR. So far I know that you cannot do JNDI lookup. – Mcalpine

Answer 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.

Pekingese

Answer 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 module 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 mentioned by others.

Also in a WAR package the changes in NamedQuery strings did not appear 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.

Appose

Actually, your problems seem to be related to JRebel. – Drumm