EARs, WARs And Size Matters
An Enterprise Archive (EAR) is effectively a ZIP archive with predefined structure. An EAR contains one or more WARs and one or more EJB-JARs. However: most of the EARs contain exactly one EJB-JAR and a single WAR.
Starting with Java EE 6 you could use WARs instead of EARs for the mainstream Use Cases. However, requirements like deployment of an embedded JCA connector, shared libraries or bundling multiple WARs per application, still require EARs.
According to EAR's nature you will have to create a ZIP three times to deploy your application; the EJB-JAR, WAR and the EAR itself. It takes almost three times as long to build an EAR, than a WAR. The application server will have to extract the archives to deploy the application as well. EAR requires to deal with more projects in the IDE: EJB, WAR, EAR and usually an assembly project which holds everything together.
An EAR increases complexity of development, by increasing the number of artifacts the developer has to deal with. You could equally well start with a WAR and create EAR later on demand.
WARs are sufficient, but even their size matters. A Java EE project is going to be deployed several times locally, and on each commit on a Continuous Integration server. The smaller the WAR the faster the deployment and feedback from CI. Minimizing external dependencies makes the WAR smaller and development faster.
If you already committed to use a Java EE server--use it. The more Java EE functionality is used in production, the less dependencies you need. Especially "just for fun" dependencies should be eliminated. External dependencies should be treated as marketing emails; http://en.wikipedia.org/wiki/Opt-in_email and not Opt-out; think twice before you add a new dependency to the project.
WAR sizes are directly related to deployment speed and so productivity. Also optimizing the performance of a CI environment is an Obvious Way To Save Money. Stay fast, stay lean!
See you at Java EE Workshops at MUC Airport (with tiny deployment units and no EARs :-))!
Hi Adam,
There is only one little thing that you can't do with a war only deployment.
Specifying the context root. This is only available in the application.xml of an ear:
<context-root>proshop</context-root>
Greetings from Switzerland
Simon
Posted by Simon Martinelli on July 12, 2013 at 01:51 PM CEST #
Are you sure that the size of a WAR is that important for deployment speed? I would assume that compressing and uncompressing the content is what makes it slow. Therefore it might be better to use an exploded WAR for deployment in a test environment. What do you think?
Posted by Eberhard Wolff on July 12, 2013 at 03:15 PM CEST #
@Simon,
this is the reason why I always set <final-name> in pom.xml. The name of the WAR becomes the context uri. But you are right. This is really lacking.
thanks for your comment!,
adam
Posted by Adam Bien on July 12, 2013 at 11:26 PM CEST #
@Eberhard,
exploded WARs are working well at deployment time.
I usually rely on Jenkins / deployment scripts. In this case in the first step
(job) a WAR is created and then reused for subsequent jobs. Exploded deployments do not work well on CI.
Sometimes we use Jenkins slaves, then the size matters even more (because of IO / latency).
Also important for performance are @NamedQueries. Each @NamedQuery needs to be parsed. Removal of superfluous (often generated) @NamedQueries also speeds up deployment.
thanks for your comment!,
adam
Posted by Adam Bien on July 12, 2013 at 11:35 PM CEST #
A little bit off topic, but about @NamedQueries:
With the property "hibernate.query.startup_check" you can disable the time consuming checking during start-up for Hibernate.
However I agree, superfluous, generated queries should be deleted.
Thanks for the blog
Kai
Posted by Kai Prünte on July 17, 2013 at 07:02 PM CEST #