Do application server vendors really understand deployment?

| November 13, 2009 | 6 Comments

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.


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 XL Deploy, 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.

About the Author ()

Vincent Partington is the CTO and Co-founder of XebiaLabs. He is a technology entrepreneur and Internet industry veteran with 20 years of experience.

  • What really baking my noodle is the problem of migrations of running systems. What’s XL Deploy got to offer in that area?

  • I really like seeing that comparison of deployment capabilities between the major J2EE appserver vendors. I’ve done automated deploys in WebSphere for longer than I care to admit, but it’s good to see that apparently WebSphere is more evolved than the others.

  • I’ve also been thinking about this sort of stuff lately, this is definitely a problem that needs to be solved soon.
    I can’t seem to find a place to download XL Deploy, maybe I’m a bit optimistic.
    Is there any plans to support glassfish in future?

  • @Dave Jones: To be honest, I was surprised by my own conclusion as well. Having spent way too much time spelunking in the depths of wsadmin, coming up for air and finding WLST and twiddle in my way made me appreciate WebSphere just that bit more. 😉

    I just wish wsadmin was a lot faster. You could say that is the price for a reliable transaction based management interface, but still…

  • @Marius: We are working on providing a downloadable version by the end of Q1 2010. It will provide support for WebSphere, WebLogic and JBoss application servers, but it will have a plugin API you use to add Glassfish functionality. In the meantime you can attend one of the webinars we host every two weeks or so. We always announce them on our website, And of course, you can always mail me if you have any questions. 🙂

  • @Iwein Fuld: XL Deploy can automate deployments to the three application servers mentioned in the blog in a standard manner. That means that the way people deploy won’t need to chance when migrating a system from, say, WebSphere to WebLogic. They can continue to use XL Deploy and then point each application to the new environment when it has been tested to work on the new appserver. Things that remain to be done are the setup of the new middleware environment and port/test your code for the new appservers. BTW, another way XL Deploy helps here is the overview it provides: you can see what applications have been deployed to what environment so you can see how your migration is progressing.