Solving the problem of deploying and administering client-side Java: DeployDirector Version 1.3

• By Edgar Holcomb
• May 24, 2001

As the popularity of Java continues to grow, it is fast becoming a dominant language and environment for business-critical Internet application development. Developers are looking for tools to help them deploy their Java apps to multiple sites and end users. Solutions for managing the deployment and updating of client-side Java applications and applets are in demand.

DeployDirector from Sitraka Software (formerly KL Group) is among the top deployment tools on the market today. It was a big vote getter in our annual "Java Report Writers' Choice Awards for 2000." We asked Edgar Holcomb, an independent contractor specializing in multi-tiered, distributed Java application development, to evaluate the latest release of this popular tool.

—John K. Waters
Product Review Editor
[email protected]

	Version Reviewed: DeployDirector 1.3 Current Version: DeployDirector 1.3
	CUP RATING SYSTEM: 5 Outstanding 4 Very Good 3 Acceptable 2 Has Potential 1 Poor

DeployDirector provides centralized deployment and updating of Java apps, including control over the Java Runtime Environment (JRE) on client machines. DeployDirector offers an important technology option (namely Java on the client) to app developers running up against the limits of what ultra-thin client technologies (HTML, JSP, JavaScript, etc.) can do.

The tool defines a client component, the Client Application Manager (CAM), and a server component, the Server Application Manager (SAM). The CAM retrieves application components and updates from the SAM. Essentially, the application administrator deploys the Java application components (the "Bundle," in Deploy-Director terminology) to the SAM. The SAM provides a URL for the app; using this URL, users can load the CAM, which grabs the application components or the updates to those components from the SAM.

After the first run of the app, the user incurs no application download overhead as long as there are no updates to the application. For application updates, the CAM and SAM work together to ensure that only the bundle files (e.g., application classes or components) that have changed are downloaded. DeployDirector supports MD5 data validation and security of bundle downloads.

DeployDirector v.1.3 provides a SAM that runs on Windows NT/2000, Linux, AIX, Solaris, and HP-UX. The SAM is essentially a set of servlets that have been tested in Apache/Jserv, BEA WebLogic, and IBM WebSphere. The client-side components have been tested on Solaris and Windows 95/NT/2000 using Internet Explorer 4.0+ and Netscape Navigator 4.5+. DeployDirector should work in any Java environment, because it is an all-Java product.

Installing DeployDirector for this review was relatively easy. The current distribution includes a single zip file that works on all supported platforms (which is probably any platform you'd want). Simply unzip the file, edit a single configuration text file, and you're ready to deploy. However, editing the configuration file was not as simple as I would have liked. I had to review the installation documentation a number of times to configure DeployDirector for the first time. Sitraka should provide a UI for configuring the product instead of requiring a manual edit this text file.

The Getting Started Guide includes a tutorial that demonstrates a number of application deployment scenarios. However, the guide is structured in a confusing manner, and it contains a couple of inaccuracies that made it difficult for me to follow.

Despite these annoyances, getting up and running was relatively painless. All application deployment is managed using the DDAdmin tool, a bundle (application) that is deployed using DeployDirector. You simply start the SAM, point your browser to the DDAdmin URL on the SAM, and DeployDirector installs the DDAdmin on your PC. Once installed, you use the DDAdmin to deploy bundles and bundle updates.

Figure 1. DeployDirector Admin tool window showing the JRE specification for a bundle.

To set up a bundle for deployment, you first set up a staging directory on your PC that contains all of the files for your app (i.e., the bundle of the application). Then, using DDAdmin, you simply name your bundle, specify what JRE you want to use, add all the files of your bundle from the staging directory, and click the deploy button. The DDAdmin and SAM transfer the bundle files and updates, which are ready for users to run.

Each bundle has its own URL. Users point their browsers to this URL to run the bundle. DeployDirector provides a small applet that gets the installation ball rolling. The applet downloads the bundle files and launches the bundle. The CAM then directs the installation/update process on your user's PC. If the bundle has not been updated since the last time a user ran it, the CAM simply runs the bundle as a standalone Java app.

The bundle deployer (the person deploying an application bundle) has a lot of control as to how the bundle should be installed, updated, and run. The deployer can produce a bundle that installs like a traditional installation wizard. Alternatively, you can designate your bundle to install silently. The bundle can be deployed so that it produces a desktop icon. You can also design your bundle so that it is launched only through the browser. However, this latter approach does not mean the bundle runs in the browser. The bundle always runs independently of the browser.

Bundle updates can be scheduled in a number of ways. Updates can occur every day/week/month at certain times, or they can occur immediately when users run the bundle for the first time after the updates have been deployed. For both timed and immediate updates, users can be given control over whether to accept the update at that time.

Users may run a number of bundles at the same time on their PCs. Each bundle typically runs in its own JRE instance. However, a nice feature of DeployDirector is the ability of bundles to share the JRE in which they run, thus shortening start-up time and saving PC resources.

I found it easy to update my bundle. If a file of the bundle changes—e.g., a class in a jar file changes—you simply copy the new file to the staging directory, create a new version of the bundle in the DDAdmin, and send the update to the SAM. I specified that my bundle should check for updates each time it starts on the client machine. The next time I ran my bundle, the CAM grabbed the changed file and installed it before running my bundle. This occurred quickly and smoothly.

DeployDirector also allows you to back out a bundle update easily. If you deploy a bundle version that is incorrect or problematic, you can designate a previous version to be the latest version of your bundle. If any of your users had updated to the problematic version, they will be updated back to the latest version you specify.

The ability to select the JRE for a bundle is a very powerful feature. DeployDirector comes with a number of JREs from IBM and Sun, but other JREs for your bundles can be installed. DeployDirector also efficiently manages the download and installation of JREs. It will first determine if the same JRE already exists on the user's PC before doing a download/install. DeployDirector is the first product of its kind that I've seen that offers this level of control over the target JRE.

Sitraka has designed DeployDirector to scale well. The SAM does not serve up applications like an application server would. The task of checking for an update to an application is quick. This means the SAM does not have to work as hard as an application server. Still, Sitraka has built scalability into DeployDirector by allowing you to configure a number of SAMs for load balancing. The SAM should be able to handle tens of thousands of simultaneous users.

I did find minor annoyances with the DDAdmin tool. The admin user interface is not very intuitive, and I found it easy to make mistakes setting up my bundle for deployment using the tool. For example, you must specify the name and installation directory of the vendor of your bundle, and re-enter this information for each version of your bundle. It would be easier to have a section in the DDAdmin where you define vendors, then select from the list when setting up a bundle version. I also found a few bugs, and inconsistencies and omissions in the online help. In general, I found that DDAdmin looks and acts like a beta product, not up to the usual high standards of Sitraka's other products.

The complaints I have with DeployDirector are minor compared to its value as a product. It solves the problems of deploying and administering Java client apps very well. With DeployDirector, you can confidently add "Java application" as a viable UI option for your apps.