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 Standard Edition >

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

Add a new trick to your Java application-deployment toolbox

By Todd Sundsted, JavaWorld.com, 07/14/00

  • Print
  • Feedback
.

Page 2 of 3

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.

Figure 2. The all-in-one 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.

Figure 3. The client/server approach

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.

  • Print
  • Feedback

Resources