Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Update distributed applications

A comparison of auto-updating solutions for thick Java clients

By Jonathan Simon, JavaWorld.com, 11/22/02

  • Print
  • Feedback
.

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.

  • Print
  • Feedback

Resources