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

Answer 2

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 3

The Java EE platform uses a distributed multitiered application model for enterprise applications. Application logic is divided into components according to function, and the application components that make up a Java EE application are installed on various machines, depending on the tier in the multitiered Java EE environment to which the application component belongs.

The image down bellow shows two multitiered Java EE applications divided into the tiers described in the following list. The Java EE application parts shown in this image are presented in Java EE Components.

• Client-tier components run on the client machine.

• Web-tier components run on the Java EE server.

• Business-tier components run on the Java EE server.

• Enterprise information system (EIS)-tier software runs on the EIS
  server.

Although a Java EE application can consist of all tiers shown in Figure 1-1, Java EE multitiered applications are generally considered to be three-tiered applications because they are distributed over three locations: client machines, the Java EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client-and-server model by placing a multithreaded application server between the client application and back-end storage.

So usually we want to have 2 or 3 separated layers:

-EAR (Enterprise Application ARchive)

-EJB (Enterprise JavaBeans)

-WAR (Web ARchive)

and sometimes JPA (Java Persistance API)

I hope you find this useful, Thanks.