Update distributed applications

A comparison of auto-updating solutions for thick Java clients

Thick and thin clients each have major strengths and weaknesses when compared to each other. Often, the strength of one is the weakness of the other. In general, thick clients are functionally rich but difficult to deploy, while thin clients are less functionally rich but easy to deploy and manage. Each approach attempts to gain the other's strengths without sacrificing its own. Deployment solutions like Sun Microsystems' Java Network Launching Protocol (JNLP) are gaining ground by allowing developers to control deployment and maintenance of thick-client applications running locally on users' desktops. This thick-client approach combines the best of both worlds. This approach, however, requires a fair amount of infrastructure in the form of a deployment solution.

A deployment solution is a complete architecture for installing and maintaining an application for its entire lifecycle. This breaks down into two sections, installation and maintenance. Installation is a package that sets up an application for the first time. Typical installations distribute installation executables via the Web or a CD. Maintaining an application assumes that the application is already installed and is being updated. Maintenance includes pushing new application versions, bug fixes, and resources. Application maintenance can be accomplished by distributing update installs or patches to the previous installation. Maintenance can also be accomplished by integrating a maintenance solution into the application development and deployment process to automatically maintain the application. I will refer to this maintenance as auto-updating from now on.

General auto-deployment architecture

Ideally, developers and administrators should have access to all of their clients' machines and push upgrades of their applications directly to their desktops at will. For various reasons, this is just plain impossible, as well as impractical. As a result, the solutions discussed in this article share a similar architecture to check a server for updates, and download and execute the application locally. First, let's take a high-level look at the general architecture before we dive into any one solution.

Figure 1. A generic architectural overview of auto-updating solutions. Click on thumbnail to view full-size image.

Notice all communication between the client and server occurs between the client and server agents. Also note the application server. All these solutions deploy in application servers, although some only require a Web server with a servlet engine. There is also HTTP/S communication between the client and server agents, making secure Internet distribution possible.

Now, let's discuss each of the main components in detail.

Client agent: The client agent is a small application that resides on a user's machine and manages all communication with the server. This includes functionality for checking updates and downloading new resources. The client agent also processes all data received from the server. The level of client-agent functionality varies between solutions. For example, some solutions may have functionality to prompt the user with several download options, while others may not.

Server agent: The server agent integrates functionality for communication with the client agent and server-updating logic. This updating logic may include functionality like authentication logic to determine if a particular user is authorized to receive a particular update.

Application datastore: The application datastore contains downloadable resources as well as server-agent and client-agent configurations for each application. This can range from a full-blown database to a simple directory on a server.

Server administrator: The server administrator is an editor for the application datastore and server agent. It provides a user interface for registering and editing application resources and settings.

How to compare solutions

The first step towards comparison is to define major functional categories of deployment solutions. Let's define them as follows:

User experience: what the user sees and interacts with relating to the updating process

Client functionality: functionality on the client machine executed behind the scenes

Deployment control: interaction with the server and control over updating processes

Architecture and integration: deployment-solution server integration with other systems

Then we look in-depth at each solution, including the following information:

  • Historical overview
  • If not JNLP, relation of the solution to JNLP
  • Specific architectural overview
  • Major benefits; something about this solution that makes you think twice about using another one
  • Showstoppers; something about this solution that might keep you from using it at all

After exploring each solution, you can compare specific points between solutions with the summary tables provided later. Finally, we examine appropriate circumstances for using each solution presented in this article.

JNLP and Java Web Start

JNLP was developed by Sun (Java Specification Request (JSR) 56) with the Java Community Process (JCP) as a quick, easy way to deploy and auto-update thick clients. Auto-updating thick clients helps to overcome many of the problems with applets and thin-browser clients, including Java Runtime Environment (JRE) restrictions and other browser dependencies. JNLP deployment is intended for a wide range of scenarios from applet replacement to intranet enterprise application deployment.

Java Web Start, the Sun JNLP reference implementation, allows one-click application installation and initialization through a browser. Users start by downloading the Java Web Start client, a browser helper application. This is only necessary the first time a Java Web Start application is run. All Java Web Start applications launched later use the same Java Web Start client. When the user clicks on the URL in the browser, the server serves a JNLP file to the client. The JNLP file is an XML file specifying resources and settings for the particular application. The JNLP file also specifies the locations (URLs) of the resources on the server for downloading.

Figure 2. A simple JNLP descriptor file. Click on thumbnail to view full-size image.

Opening the JNLP file initiates the Java Web Start client, which processes the JNLP file. Java Web Start downloads the entire application if the application was not previously downloaded. If the application is currently on the client, but out of sync with the server, only new or changed resources are downloaded. After this update check, Java Web Start automatically launches the application.

According to Stanley Ho, staff engineer at Sun, "In Java Web Start 1.2, we have a new auto-install feature (on Windows only), which allows the launching of a Java application from the Internet/intranet using just a few clicks from the browser. Upon clicking the JNLP file link on the browser, Java Web Start will download/install if needed and launch the Java application automatically. This is another benefit of using Java Web Start—to deploy client-side applications easily."

Now that you know how JNLP works, let's step back and analyze the architecture. The Java Web Start client is the client agent, albeit a very simple one, as it allows only rudimentary user interaction during the update process. There are no server agents, server application caches, or server administrator components defined in the JNLP specification.

By now you're probably wondering why JNLP is described as a deployment solution. A little insight into Sun's intentions with JNLP will help clarify this. JNLP was intended to be a starting point in thick-client deployment. It's a protocol, a foundation, but not a complete deployment solution. Sun intends for IT departments and product vendors to build solutions on top of JNLP and extend it as necessary. In the context of this article, I will compare the possibilities of JNLP implementations to other off-the-shelf solutions.

Major benefits

  • It's free!
  • Straightforward architecture. May only require a Web server (without a servlet container) for simple applications.
  • Solutions can be small and lightweight (and therefore easier to deploy and maintain) since they may not require full databases, client administrators, and server agents.
  • The solution Web application and the application resources can easily be packaged into one war file, keeping transportation between machines simple.
  • You can build dynamic Web applications to search for applications at runtime rather than explicitly registering them with a database (see sidebar, "Application Portals").
  • JNLP is an open specification. Therefore, you can switch between JNLP-compliant clients at will, or write your own for unsupported platforms.
  • Since JNLP files are XML files, generating and editing JNLP files is simple with the help of a Java XML parser/generator like Xerces.
  • The JNLP specification integrates the secure sandbox security model. This is absolutely essential for public Internet distribution.

Show stoppers

  • As mentioned, the JNLP specification integrates the secure sandbox security model. Therefore, security restrictions include server download and access restrictions and signed resources requirements. The inability to disable security is a major minus for enterprise applications, as it involves serious coding and distribution considerations.
  • Client-agent support is minimal. The user cannot interact with the client agent in any way during the update process. An example of where this might be a problem is an application that is required to prompt the user to decide whether or not to update the application once a new version is detected.
  • All resources must distribute in jar files. This also means that your application code needs to change to load resources from jar files, rather than from just in the CLASSPATH.
  • JNLP does specify JVM management, but there are a number of problems with it. First, all VM installations are system wide. Second, the JRE you point to must be compliant with the JRE Download Protocol. This is fine if you use a Sun JRE, but difficult, say, with an IBM JRE version. Third, the user is still presented with the JRE license agreement. In a perfect world, users wouldn't even know what a JRE is, let alone agree to what version goes on their machines.
  • JNLP specifies minimal OS-specific support. For example, JNLP allows specification of shortcut names, icons, and start menu entries, but does not allow registry entries or arbitrary file placement.
  • Building your own solution on top of JNLP can take much effort to develop and maintain, increasing your applications' time to market.

DeployDirector

DeployDirector is a complete deployment solution developed by Sitraka (recently acquired by Quest Software). DeployDirector is built on a proprietary extension of JNLP to support more advanced functionality. Although the extension is proprietary, JNLP is still at its core. In fact, DeployDirector was introduced before JNLP, and Sitraka migrated to the new open standard. Sitraka is now an enterprise contributor for JSR 124, the Client Provisioning Specification, and plans to migrate DeployDirector to that as well. One thing to note is that although DeployDirector is JNLP compliant, applications deployed with DeployDirector must use the proprietary DeployDirector client to function properly. DeployDirector applications will not work with other JNLP-compliant clients like Java Web Start and OpenJNLP.

DeployDirector comes out of the box with a complete integration of the four major components: the client agent, server agent, application cache, and server administrator. DeployDirector is an auto-update management solution, not a replacement for initial deployment. In fact, the DeployDirector thick-client server administrator is deployed with InstallAnywhere, produced by Zero G, the same company that makes PowerUpdate (one of DeployDirector's competitors discussed below). It is also possible with DeployDirector to run an installation directly from the Web, but that is not the main focus.

DeployDirector applications are deployed with the proprietary client agent (a small Java application, approximately 600 KB). The user does not initiate the application directly; rather, the user initiates the client agent, which checks the server for updates, processes the updates accordingly, and then starts the application. DeployDirector comes with a client agent API that allows plug-ins to invoke during this process, providing key functionality (for example, authenticating the user for access to updates). The updating process can also invoke programmatically after startup, through a menu option, for example, and the client agent handles all system-dependent resource locking, updating, and restarting. The client agent is also used continuously during startup and at runtime to communicate events to the server, including unhandled exceptions and installation errors.

1 2 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more