Alternative deployment methods, Part 2: The best of both worlds

In my previous column, I examined the most widely used method of deploying Java client-side applications in enterprise environments — the applet — and presented several reasons for its popularity: the ubiquity of browsers, ease of distribution and maintenance, and so on. I also described its limitations, which include lengthy download times, the browser’s document-centric presentation model, and nonuniform support across browsers.

Despite these shortcomings, applets should not be abandoned completely. They are clearly useful in some situations – for example, as realtime information on an otherwise static Webpage. Problems arise, though, when developers use applets inappropriately. Unfortunately, too many training classes and books still put a disproportionate amount of emphasis on applets, and many newcomers look solely to applets when deploying Java applications in a Web-based enterprise environment.

In Part 2 of this series on deployment methods, I present an alternative technique that uses applets in an unconventional manner. This method melds some of applets’ best features with those of traditional deployment techniques and creates a foundation upon which powerful deployment tools can be built.

The time is ripe to adopt a new deployment model. In recent months, I’ve talked with developers who have independently created similar techniques. Vendors are also stepping up to the plate — during JavaOne, a handful of companies announced products that fit the model I describe in this article. See Commercial deployment products for a discussion of off-the-shelf products.

Applets play a new role

The greatest boon to the applet deployment method is the ubiquity of the browser — since browsers are everywhere, applets can run everywhere. Unfortunately, applets suffer from deficiencies in their original design (a simplistic lifecycle and the need for network connectivity), the browser’s document-centric presentation model, and implementation differences between browsers (although Sun’s Java Plug-In has helped quite a bit).

The method I describe here uses an applet as the delivery vehicle, thereby employing the browser’s ubiquity, but avoids implementing an applet as the execution platform, thus skirting the problems described above.

Figure 1 illustrates the general design:

The system consists of three core components (the repository, Web server, and browser) and one optional component (the deployment server). The repository holds deployable resources, the deployment-instructions file, and a small boot-strap applet. The Web server delivers resources from the repository, in addition to typical Web fare like Webpages and images. The browser provides the user interface and the initial installation platform. I’ll explain the function of the optional deployment server below.

How it works

You (the deployer) begin by packaging the application as one or more deployable resources. You then create a deployment-instructions file that defines the steps necessary to deploy the application, and you place everything in the repository. Finally, you create a Webpage containing instructions and the boot-strap applet, and either publish the Webpage or mail it to the users. (The latter option requires that the user have a Java-enabled mail client.)

The user accesses the Webpage from a browser, which fetches and starts the boot-strap applet. With a simple wizard-like interface, the applet leads the user through the installation setup. When setup is complete, the applet obtains the necessary filesystem permissions and begins to acquire and install the required resources; application code, application data, and the Java Runtime Environment if not already present. Once the user has installed the application and supporting components, the applet’s work is done.

The user can return to the page later to check for updates, or the deployment engine, which can be embedded in the application itself, can automate updates.

Below, Figure 2 illustrates the functional composition of the boot-strap applet.

The applet is the centerpiece of the entire operation. It must include the logic necessary to direct the installation process as well as the machinery necessary to execute the installation process. You’ll notice a potential problem when you start adding on the necessary components: the applet quickly grows so large that its own deployment becomes problematic.

Below, Figure 3 illustrates an alternative architecture.

You can, in fact, separate the logic that directs the installation process from the code that executes the installation process on the user’s machine. The logic and associated infrastructure that compose the bulk of the applet can run as a separate server. This server controls the applet’s behavior via RMI or some similar technology. Thus, the applet can become much thinner at the expense of running another server process.

The deployment instructions

Whether you run the deployment machinery as an all-in-one applet or in the client/server configuration, you must define the steps required to deploy your application. Those steps compose the XML deployment-instructions file, which contains deployment instructions formatted as XML and patterned after rules used in tools like make. Each rule consists of a target, a variable amount of preconditions (which may well be zero), and a body containing executable steps. An engine in either the applet or the deployment server interprets the XML instructions and directs the execution code to carry out specific operations.

See Resources to download a format for conforming XML deployment-instructions documents and a simple deployment-instructions document.

The order of the deployment rules is insignificant. The engine builds an internal model of the information in the deployment-instructions document before directing the installation.

Security considerations

The boot-strap applet requires access to a user’s filesystem to install deployment resources on said user’s machine. Java wisely prevents this, since giving out untrusted code access to your filesystem is risky. Thus, applets are forced to remain “inside the sandbox.”

Both of the major browsers (Netscape Navigator and Microsoft Internet Explorer) provide proprietary APIs that free applets from the sandbox. Also, Java 2 allows digitally signed code to perform specific restricted operations with the user’s permission. Unfortunately, without the Java Plug-In, Java 2 is not yet supported by the major browsers. Since the plug-in is not an option on some platforms and in some environments, the applet must potentially support all three security models.

Coverage of these three security models would require an article apiece — rather than explore this interesting but peripheral topic, I’ve provided numerous links (see Resources) for those who wish to learn more.

Conclusion

The technique outlined above looks good in theory and works well in practice. I’ve included the code (see Resources) so you can put the technique to work immediately. If you’re interested in an introduction to the technique’s inner workings, I suggest you return for Part 3, where I’ll take you on a tour of the code and provide some examples to get you going.

Source: www.infoworld.com