email article printer friendly get the code more resources

Make Applications Update-Aware
Employ the Java Web Start technology to place JAR files on a Web server to facilitate error-free updates
by Mark Nadelson

June 2003 Issue

I have multiple Java-based applications running throughout the company wide network. Some applications are running in various locations in the United States, some are running in London, and others are running in Singapore. These applications include both stand-alone daemon applications with the requirement to run 24-7, and others are GUI-based client applications executed by users at their desktops. My initial setup was to create the required Java Archive (JAR) files and locate them on a host to which all locations have access. I then set up executable batch files that can launch the given applications.

This setup worked great! Then I received my first phone call. London and Singapore were getting horrible performance because they had to load the JAR files from across oceans and continents. No problem. Being the clever guy that I am, I got our system administrators to copy the needed JARs to a host local to each location and created location-specific executable batch files (with the CLASSPATH set up to point to the local JARs).

This setup worked great! Then I made my first code update. I updated the JAR files located on the original host machine. Two very bad things happened. The first was that all programs using the updated JARs started getting strange errors. I realized this problem occurred because I updated the JAR files without taking down and restarting all applications using it. This unfortunate oversight caused corruption within currently executing applications. The other very bad thing that occurred was the result of forgetting about London and Singapore. I never updated their local JARs, and no one could understand why they were getting results that differed from my local users' results.

What a mess! Now every time I needed to do a release I had to take down all applications associated with the JAR being updated as well as notifying the system administrators to copy the JARs to their location-specific hosts. I also had to keep track of which applications used which JARs because they would all have to be taken down before an update could occur. I learned this lesson the hard way when I forgot that some of the applications shared a base JAR file and did not terminate all of them before doing my update.

Got to Be a Better Way
Luckily there is a better approach. Java Web Start was the answer to my deployment and code synchronization problems. The Java Web Start technology allows the developer to place all JARs on a Web server (see Resources). Included with the JARs is a configuration XML file with a JNLP extension. Java Web Start uses this configuration file for determining the JARs (and other resources) needed for the application as well as how to execute the application. The execution specification includes the version of the Java Runtime Environment to run, the command to run, its arguments, and any system properties that need to be set.

Once the application has been placed on the Web server (and assuming Java Web Start is installed on the local host), users can execute the application simply by pointing their Web browser to the URL address of the JNLP file. This application activates Java Web Start and the magic begins. Java Web Start checks to see if the resources required are cached on the user's host machine. If not, Java Web Start downloads all required resources and executes the application once the resources are downloaded. The next time the same application is started, Java Web Start compares the resources stored on the local cache to the resources stored on the Web server. If the resources on the Web server have been updated, Java Web Start downloads all updates before launching the application.