EAR vs. RPM for shipping web applications?

When shipping a web application to production, would you consider an enterprise application archive or an RPM?

What ar开发者_如何学编程e the cons and pros of each?

With RPM you can keep track of versioning and treat configuration files properly.

Let's assume your application won't be installed on Windows boxes, so OS dependency is not an issue we are worried about.

---

Most Java web applications that I've worked with, or studied, have been typically published as Enterprise or Web archives. The case for RPMs is quite weak, except for very specific scenarios.

There are several points that go in favor of EAR/WAR files:

• Installation is often easy, even if it involves some manual process of copying/uploading EAR/WAR files to a designated directory. However, you need to know your target audience here. If you are expecting that a Linux system administrator (who has little or no knowledge of Java application servers) is performing the installation and maintenance of the application, then you might right in choosing RPMs. This is however a rare case for businesses, for it makes less sense from the point of view of support; you simply do not want to be at the mercy of a third-party application developer when installation/configuration issues are encountered in the production.

• EAR/WAR files can be published in a manner that can allow for portable installations. It is theoretically possible to support multiple containers with a single build. This is a far better alternative than requiring a RPM to be published per-container; each RPM would have to install an application-specific container and publish the EAR/WAR file to this embedded container. If you wish to have your customers retain the choice of deploying onto their own containers, a RPM-only deployment model will require them to extract the EAR/WAR file from the RPM, and then perform the deploy themselves.

• RPMs cannot be used to deploy applications in a standard manner, across commercial containers like WebLogic, WebSphere etc. It simply cannot be done, unless you expect your customers to employ a standard installation model involving directory layouts, clustering modes etc. RPMs that are created in-house to target a single customer, might not have this problem, as internal standards can be established on how the containers would be installed and configured.

Inferring from the above statements, EAR/WAR files ought to be available always to account for customer needs, with the added possibility of having RPMs for a hassle-free installation.