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

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.

DeployDirector Figure 1
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.

Daimler–Chrysler Deploys Homegrown Java Apps With DeployDirector
Automaker Daimler–Chrysler set out to rebuild the cost systems for its Chrysler group about two years ago. The Chrysler Cost Management System (CCMS) initiative involved a mixture of homegrown, thin- and thick-client, Java-based applications distributed internally on the company's intranet. CCMS manager Dave Boehme and consultant Kevin Roberts chose Sitraka Software's DeployDirector to distribute the thick-client apps developed for the three-phase project, phase three of which is still in development.

Java™ Report: Why did you need a deployment tool?

Dave Boehme: We were developing an app for multiprocess costing as part of the CCMS initiative. [The application] was a thick-client, Java app and we realized right away that we needed a scalable solution to manage the distribution of these kinds of applications to the desktop. These are homegrown apps serving Daimler–Chrysler employees and customers through our intranet.

JR: When did you start using DeployDirector?

Kevin Roberts: We started out using the Castanet product from Marimba, but we wanted to expand our licensing to be more worldwide, and also wanted a little more flexibility. We also looked at some of the Sun tools at the time, but they weren't really up to snuff. There weren't a lot of mature tools on the market when we started this three-and-a-half years ago.

JR: Why did you settle on DeployDirector?

KR: It was all about functionality. DeployDirector had the administrative features we were looking for. It had a small footprint on the desktop, and a very low intrusion factor on the client desktop. And the price was right.

DB: And the support was very good. [Sitraka] worked with us very well. We had used their JClass products to do graphical widgets. When they approached us to do some beta testing, we jumped at the chance.

KR: We're also using it to deploy what is called a balanced score card application, a measurement tool that is built internally and used for manufacturing—this will soon be used with all corporate business organizations at Daimler–Chrysler.

JR: What do you like best about the product?

DB: We really like the version control. We can roll back to an earlier version if we need to very easily. We can also keep track of who has downloaded the application, so we know who has it on their desktop.

KR: JVM independence was a big one for us. We can deploy multiple applications, each at their own JVM level, so that we're not tied into a specific JVM at the user desktop. We have some applications that are on 1.1.7, some that are on 1.2, and so on. To be locked into one is painful—reminiscent of the Windows DOL issues. That's a big one.

JR: Any problems with the product?

KR: A couple of things could be better. We'd like to see better command-line support for the application so that we can have more of our servers build update applications automatically.

DB: But basically, we're very happy with it.

 

Review in a Nutshell
Pros:
  • Powerful and flexible solution for developers looking to provide a rich Java client to their enterprise users.
  • Installation is simple across all platforms.
  • Centralized application deployment and update reduces application administration costs.
  • Only application changes are downloaded during application update, thereby minimizing download delays during application update.
  • Flexible options to schedule application updates.
  • Ability to select the JRE to use for deployed applications, thereby allowing applications to take advantage of the latest Java technologies immediately.
  • Wide, multiplatform support.
  • Advanced failover, scalability, and security options.

Cons:

  • All of the documentation needs work, including the installation guide, tutorials, and online help.
  • The admin tool is cumbersome to use and its user interface is counterintuitive.
  • More annoying bugs than should exist in production-quality software.

Bottom Line:
DeployDirector offers an important solution to the challenges of providing Java client applications to users. The ability to choose a JRE for each application and the ability to schedule application updates flexibly make this product well worth evaluating. Recommended for developers who want to provide a rich client experience to their users, but have been forced to use HTML-based solutions because of network and/or administration constraints.

System Requirements:
The vendor claims any Java 1.1+ platform, but lists the following minimum requirements:

  • 64 MB RAM
  • 30 MB hard drive space
  • Additional hard drive space for bundle construction

Supported Platforms
Server side:
All server-side components have been implemented in Java and should work on all Java-compliant platforms. The vendor has tested these components on the following platforms: IBM AIX 4.32; RedHat Linux 6.1, 6.2; Solaris 2.5.1, 2.6, 2.7 (with patches); Windows 2000; Windows NT 4.0 (SP5); HP-UX 11; Web Servers; Apache 1.3.6 with Jserv 1.1; BEA WebLogic 4.51, 5.1; IBM WebSphere 3.0.

Client side:
All client-side installation components run in any Java-enabled browser. The vendor has tested these components on the following platforms: Solaris 2.5.1, 2.6, 2.7 (with patches); Windows 2000; Windows 95 (OSR2), 98 SE; Windows NT Workstation 4.0 (SP5); Browsers; Microsoft Internet Explorer 4.0 or greater; Netscape Navigator 4.5 or greater.

Pricing and Availability:
Available through worldwide direct-sales channels. Evaluation copies are available on the Sitraka Software Web site. Can be purchased based on the number of users (starting at $2,750 for 10 users), priced per application ($25,000/application—regardless of the number of users), or priced on an OEM basis when embedding this technology in other solutions.

Most   Popular