Tuesday, August 21, 2007

Keep Deployments Thin and Lightweight

In these times, were we preach keeping the architecture stack lightweight, by using tools like spring and hibernate instead of J2EE, I would like to extend the concept a bit. You should also consider keeping your deployments lightweight. Here are some steps you can follow:
  • Deploy as a war file (as opposed to ear files)
  • Avoid dependencies on container setup (such as datasources, JMS queues, authentication, ...)
I will try and explain what I mean.

Deploy as a war file
A war file is relatively simple and easy to understand. In addition to this, it is faster to build as opposed to assembling ear files.

Keeping with war files for deployment will force you out of some technologies, like ejbs for instance, and most of the time, this is a "good thing". Most of time, there are good alternatives. This is where the lightweight stack technologies like spring and hibernate comes in.

Having a war file as the end product also opens up for a much larger container choice in deployment. Tomcat, Jetty, Resin, Weblogic, ..., whereas an earfile requires a complete J2EE container.

Avoid dependencies on container setup
This is all about avoiding "stuff that needs to be setup beforehand" in the deployment phase. Ideally, the war file should be able to be dropped right into any freshly installed container, and just work.

An example is the use of in web.xml to define a datasource dependency by name, and then look it up in the code using JNDI, to get access to connections. For this to work, you rely on the datasource to be defined and setup correctly beforehand, or else your application will fail deployment. What is the alternative? Use some of the pooling implementations out there! For instance c3p0 plugs right into hibernate.

Another example is authentication. In the web.xml file, you could use the to require basic authentication to access your applications URLs. In addition to this, you might require some specific role, to get access to the application. For this to work, you rely on configuration of some JAAS implementation in the container and correct setup of it. This is not neccesarily a simple task, and containers do it differently. What is the alternative? Use acegi and extract the authentication response from the container! Jacob shows how to do basic authentication with an acegi filter.

What is the catch then?
Of course there is a catch. Having the datasource defined external to the application deployment makes it easy to switch what database you are pointing at, without redeploying. Having the container do the authentication makes the container know your principal and roles internally, enabling things like HttpServletRequest.getUserPrincipal() to answer sane values.

But, much of the deployment descriptor requirement of mapping some "made up" name to real resources, comes from J2EEs concept of a developer role, an assembler role and a deployer role. More often than not, you, the developer, has all the roles.

Try keeping it simple for yourself!

No comments: