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.
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.
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.
DeployDirector offers three different ways to control the server: through a thick client, a Web client, or a command line interface. The thick client is easy to navigate and quick to use. This is beneficial since most of your management time in DeployDirector will be spent here. DeployDirector also has a server agent API that offers a large amount of control over the server agent. It includes functionality for indirection of knowledge outside the application cache (to a database or Java Naming and Directory Interface (JNDI) for authentication, for example). These customizations can also integrate back into the thick client, as the server agent API lets you build custom editors that load into the thick-client administrator. And for all you nonadventurous folks out there, DeployDirector comes standard with a number of default plug-ins for use with the server agent API. The server is a Web application that can be deployed in most major application servers.
The application cache also has a key enterprise feature: the storage of applications in what DeployDirector calls “bundles” in a format called a Deployment Archive, or DAR. DARs encapsulate all resources and settings for a particular application. This creates a portable format for moving deployed applications between servers—essential for a distributed deployment solution.
Major benefits
- The included documentation, examples, and demos are excellent. I had a relatively good grasp of DeployDirector after spending an hour and a half with the tutorial.
- Comes with built-in logic for user authentication and access to particular versions.
- Several forms of administrative control: thick client, Web, and command line.
- Serious replication capabilities allow for distributed deployment, failover, and scalability.
- The server integrates with system management platforms (i.e., Tivoli, BMC Patrol)
- Offers extensive reporting.
- DAR format provides application portability between servers.
Show stoppers
- This is a heavyweight, complex product intended to handle complex deployment scenarios. It takes some time to learn the system.
- No Mac support pre Mac OS X.
PowerUpdate
PowerUpdate is created by Zero G, the makers of the popular installation tool InstallAnywhere. InstallAnywhere and PowerUpdate are not integrated per se, but they do complement each other to create a complete deployment and updating suite. In contrast to DeployDirector, PowerUpdate is entirely proprietary—from its protocol to its client. There is no hint of JNLP. PowerUpdate also has a complete solution for all four major components.
The PowerUpdate user experience is nearly identical to DeployDirector. The application is deployed with a small Java client agent (approximately 400 KB). The user initiates the agent rather than the application directly. The agent then performs all communication with the server. The client agent also has an API for customizing the user experience as well as providing nonuser experience-based client functionality. The client agent also communicates unhandled exceptions and failed installations with the server.
The PowerUpdate server administration is simple and straightforward. PowerUpdate uses a Web deployment wizard to deploy and edit applications. The server agent also has an extensible API for custom logic. As with the other solutions, the PowerUpdate server is deployed as a Web application in most commercial application servers.
Major benefits
- Both application deployment and the PowerUpdate server are quick and easy
- Offers extensive reporting
- Supports directory synchronization and installation repair
Show stoppers
- The server can only be administered through a Web interface. No command-line or thick-client administrator is available.
- Although PowerUpdate supports authentication and access, only a single version of an application can be active at a time. Therefore, if you want to have a group of users run a different version than the rest of your users, you need to create an entirely new application in the datastore.
- The agent APIs are fairly limited.
- PowerUpdate does not support a bundled application format for moving applications between deployment servers.
Recap
The following lists some of the most important comparison points and results for each solution:
Table 1. User experience
|
Table 2. Nonuser experience client funtionality
|
Table 3. Server funtionality
|
Table 4. Overall architecture
|
Which solution should I use?
You should now have a good grasp of the different auto-deployment solutions, their structure, strengths, and weaknesses. The next step is to look hard at your application deployment requirements. Let’s consider how each solution might suit your specific needs:
JNLP: If you currently deploy applets, you should look into JNLP. JNLP is the logical next step for applets, freeing you from browser limitations while maintaining a thick-client application. If you deploy one or more applications over the Internet and don’t have to worry about complex deployment functionality like user authentication and version access, you should definitely use a simple JNLP solution. It can be built quickly with the help of an XML parser/generator like Xerces. JNLP is the only solution that integrates the secure sandbox security model, a must for Internet-distributed applications. Also, JNLP is great for application portals or groups of applications (see sidebar, “Application Portals“).
DeployDirector: If you are building an intranet-deployed enterprise application requiring complex deployment logic, you should use DeployDirector hands down. The thick-client administrator, agent APIs, portable application DAR format, multiple server capabilities, and the user group application version management combined with authentication and access put DeployDirector light years ahead of any other solution in this arena. If you want comprehensive deployment functionality, and it’s not built into DeployDirector, you will have to build it yourself one way or another.
PowerUpdate: If you are deploying an application over the Internet or intranet and you have moderately complex deployment requirements (like simple version maintenance and unhandled exception logging), you should use PowerUpdate. The Web administrator is easy to use and there is not a lot of functionality to remember between sessions. This is perfect if you don’t want a lot of application management overhead.
Once you have determined your application deployment requirements, compare the requirements to each solution’s strengths and weaknesses. Also remember that none of the solutions presented here is better than any other. They are all very well designed. The goal is to choose the most appropriate one for you.
I want to thank several people who helped with this article. The insight I received from these individuals was simply incredible. Here they are, in no particular order: Devin Poolman and Marc Wolf, Zero G; Patrick Smith and Don Wright, Sitraka; Dennis Macneil and Stanley Ho, Sun Microsystems; Brett Kotch and Felicia Knisely, Liquidnet Holdings; and Daniel Steinberg, independent consultant.
