adam bien's blog

Which Deployment Option Would You Use For a Mission Critical Application? 📎

You have the following deployment options in Java EE (J2EE/5/6):
  1. Deploying an EAR / WAR to a multi-project or dedicated server
  2. Cluster deployment: deployment units get spread across the nodes, you get HTTPSession and @Stateful Bean failover
  3. Cluster deployment, but no replication or failover. You get easy distribution and management (deactivating, disabling) of deployment units
  4. Dynamic environment: your application is split across loose-coupled modules, which could be managed independently

And the mission critical strategy is:
  1. Minimization of moving parts - simplicity is the key!
  2. Very simple upgrade and maintenance strategies - the system should always be in consistent state.
  3. Dead simple monitoring and deployment - operations are rarely interested in our geeky frameworks, switches and whistles.
  4. Avoidance of third party frameworks and libraries - they are faster EOL than you may think.

Although they are zillions of frameworks and options out there, we did the following:
  1. We deployed not only the application, but also the application server with already installed application AND JDK as a zip with hardcoded classpath
  2. The application consisted with as few as only possible external libraries, parts or frameworks. We started with JDK 1.6 then expanded the search to Java EE 6 (or lower versions)
  3. Although we had logical packages and components, we tried to deploy the application as a "BLOB" e.g. maven-with-dependencies does a nice job here. The fewer jars you have - the less can go wrong.
  4. We didn't used a cluster but also didn't relied on the HA-qualities of the HTTPSession and SFSB in particular.
  5. A simple load balancer, sometimes a slightly more sophisticated strategy, distributed the load across mostly independent servers (with sticky sessions were possible).

In real world you have a lot more to consider (especially the other non-functional requirements, politics and policies), than only availability and criticality.
The strategy above has an interesting side-effect: you can not only upgrade your application, but also your appserver AND the JDK, just by replacing a folder or extracting a zip. After re-routing the traffic and killing the process or virtual machine - you can consistently and atomically update not only the app, but also the whole environment.

Interestingly a "mission critical" strategy is fully compatible with building maintainable software.

[See chapter 1 in "Real World Java EE Patterns - Rethinking Best Practices" for more in depth transactions, clustering, state, optimistic concurrency discussion]