Why use an ear instead of a war?

Question

I read this and this which are somewhat related to my question. But I came across this article that says that EJBs can be packaged in a war file. If this is the case, why is there a need for an ear? An explanation with an example will be highly appriciated.

Answer 1

Using EAR or WAR depends on the server you want to deploy it, your application, and on your personal preferences. From Java EE6 you can package your EJBs together with other servlets, jsps etc into WAR file (you end up with web application which you can deploy only on java ee 6 compatible server). If you package your app the old way with ejbs in a separate package and war separately, you can use java ee 5 server if you haven't used other features of java ee6 within your application, you can separate the deployments of your EJBs and WARs to have a clear separation of your business layer (EJB) and your view (Servlets, JSP's etc).

Answer 2

Using an EAR affords a clean separation between business (usually stateless EJB beans that provide back-end / db-related services and can in principle be used by non-web clients) and front-end (xhtml files, JSF backing beans, etc).

I usually follow the below convention, for a given project, say "foo":

• foo-ejb.jar has the EJB beans
• foo-client.jar defines the interface of the EJB beans ('client' may be a misnomer, 'foo-if.jar' or 'foo-api.jar' may be better names)
• foo-war.war has the web resources

Building foo-war.war only requires foo-client.jar

Building foo-ejb.jar only requires foo-client.jar.

The structure in the EAR is:

foo.ear
 |
 |-- foo-war.war
 |
 |-- foo-ejb.jar
 |
 \-- lib
      |---- foo-client.jar
      |
      \---- (other common jars)

There maybe a way to have a similarly clean separation when your code is deployed as a WAR but the above is what I am using and seems to work for me (I am open to suggestions of course).