Do application server vendors really understand deployment?

At XebiaLabs we know a thing or two about the automated deployment of Java EE applications 😉 . One thing that strikes me as odd is the fact that the people you would expect to know most about application deployment, the application server vendors, don’t seem to understand the problem at all.

On one of our previous blogs, you can read up on what we see as the full scope of a Java EE application deployment. The short version is this:

• It’s more than just deploying an EAR file or a WAR file. For starters, it can involve more than one of these.
• Most applications also need other kinds of artifacts to be deployed, such as static content for the webserver or static configuration files to be read by the Java code on startup.
• You’ll also need to configure Java EE resources such as data sources, JMS providers, etc.
• In most cases you need to configure the middleware itself too. Think about creating and configuring application server clusters, or setting up Apache virtual host configurations.
• All this needs to happen in the right order to minimize (or prevent) downtime of the application during deployment and improve speed of the deployment.

So what do the application server vendors make of this?

Oracle WebLogic Server

Well, Oracle WebLogic Server has a concept called a Deployment; it is the thing you create when you deploy an EAR, WAR or EJB JAR. You can customize its behaviour by supplying or editing a Deployment Plan. But there is no way to bundle multiple Java EE artifacts in one deployment or include the creation of Java EE resources such as data sources.

In WebLogic there is also something called a Subdeployment but, strangely enough, that concept is unrelated to that of a deployment. It is a mechanism that is used to target parts of a JMS System Module to specific JMS servers or WebLogic server instances. The JMS System Module abstraction itself seems to meant to group together JMS resources that belong together. Maybe one of the developers had originally called this thing the Deployment and was then reminded of the other Deployment already in WebLogic. This is all speculation of course, but it would nicely explain why a Subdeployment is called that. 😉

WebLogic offers a number of different deployment APIs. There is the weblogic.Deployer command line tool, the wldeploy Ant task and the Python-based WebLogic Scripting Tool (WLST for short). Of these I think the WLST is the most feature complete. The file system abstraction layered on top of the MBean hierarchy works pretty well so usually it doesn’t take too long to figure out how to get something done.

JBoss Application Server

Deployment in JBoss is handled by the Virtual Deployment Framework. This is a very flexible MBean based framework that allows many different kinds of artifacts (EARs, WARs, EJB JARs, RARs, SARs, etc.) and resources (data sources, JMS settings, etc.) to be deployed onto JBoss. All these are handled by their own standard deployer.

However, most people will not manually invoke these deployers, or even twiddle them. Instead most people will drop their artifacts in the deploy directory of the JBoss application server and wait for it to be picked up by the Deployment Scanner. And then they tail the logfiles to see when the deployment has finished.

The big problem with this is that deployment is not an atomic action. When you automate your deployment you only want to restart your web server until after the deployment of your new WAR file has succeeded. But writing code to tail log files and wait for a certain string to appear is just, well, ugly. An alternative would be to set the property ScanEnabled of the DeploymentScanner to false and invoke the specific deployer manually. Not only will this make your code more complex, you will still need to copy your files into the deploy directory for JBoss to pick them up after a restart.

So it turns out that JBoss Application Server makes it hard to integrate deployments to its servers into a bigger deployment scenario. This is something they definitely need to fix to be really ready for the enterprise.

IBM WebSphere Application Server

So how about that big blue’s big Java EE beast? It offers a very versatile, transactional way to deploy applications and resources. Basically, the wsadmin scripting interface allows you to control all aspects of WebSphere and it is very clear when certain things have been activated. You can explicitly synchronize nodes and the Jython (or JACL if you are so inclined) method you invoke to deploy an application only returns when it is done. On the downside it is a lot slower than WebLogic’s similar WLST tool (it seems to be copying a lot of XML files back and forth over SOAP. Argh!) and the API offered is pretty complex (who here knows the difference between a containment path, a configuration id and an object name?).

While WAS does not make it possible to group together the artifacts and resources that are related to one deployment, its transactional nature allow you to commit related changes to the configuration in one go. It can even manage some of the configuration of installed IBM HTTP Server or Apache HTTP Server instances.

So even though it is down on deployment speed, nothing beats WebSphere as far as deployment reliability is concerned.

Summary

The application servers each provide a different level of support for the complexity of real-life enterprise-level deploymens. Of course they can all deploy the basic Java EE artifacts, but none can group multiple artifacts into one deployment or link the Java EE resources that go with those artifacts. WebLogic is the only application server that tries tries to group together related resources (the JMS System Module and the Subdeployment), these abstractions cover so little of the full scope of Java EE deployment that they are actually in the way when implementing automation deployment.

Repeatability and predictability are very important for a successful deployment strategy, which might explain WebSphere’s prevalence in the enterprise market. And finally, good API support is necessary to allow you to automate your deployment process and both WebSphere and WebLogic offer that. JBoss is seriourly lacking this area, twiddle just doesn’t cut it!

My colleagues at XebiaLabs and myself have, in our previous jobs, written countless scripts to automate deployments and had to work around these issues again and again. We have now developed Deployit, a Java EE deployment automation product, because we believe deployment automation is of the utmost importance to keep on top of the growing number of deployments in today’s enterprise environments.