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 Development Tools >

Alternative deployment methods, Part 3: The code

Examine the code and techniques used in an alternative deployment tool

By Todd Sundsted, JavaWorld.com, 09/22/00

  • Print
  • Feedback
In the first two parts of this series, I described the shortcomings of most popular methods of deploying Java applications, and proposed a solution that tackles many of those disadvantages. This month, I turn to the nuts and bolts of implementing the solution. I also consider the snags you may encounter when designing and implementing similar applications. And in the sidebar Commercial deployment products, I add to my discussion on new products that ease the deployment process. Let's begin with a review.

Alternative deployment methods: Read the whole series!

Review

Deployment is an important part of the software-development life cycle. After all, software must reach the end user to be of value. Two traditional deployment models are the "foot-and-hand" model (someone runs around on foot and installs the software by hand) and the "self-service" model (the user installs the software himself). For large deployments, both models are time-consuming and expensive. Therefore, for many managers and software developers, the Web browser and the Java applet provide a promising alternative.

Java applets have many advantages over traditional deployment methods. Primarily, they leverage the ubiquity of the browser and the network. However, applets suffer from deficiencies that arise from their original design, from the browser's document-centric presentation model, and from implementation differences between browsers.

Last month, I proposed an alternative that implements the applet's best features and works around its weaknesses. This deployment technique offers rewards similar to those of more traditional alternatives.

General design

Figure 1 illustrates the tool's basic design:

Figure 1. The general design of the deployment tool



The repository holds deployable resources (code, source, documentation, etc.). Physically, it is part of the server-side file system. The Web server delivers resources from the repository, in addition to typical Web fare such as Webpages and images. During the first phase of the deployment process, the Web server delivers a small bootstrap applet to the browser. This applet subsequently downloads and installs the deployable resources from the repository to the user's filesystem. The deployment server, an optional component, reduces the applet's workload, therefore reducing its size and complexity.

My goal was to build a deployment tool that was simple, embodied good practice, and was component-based (modular and pluggable).

Class model

The deployment tool's class model is much too large for one diagram. To make it easier to digest, I've made three smaller diagrams of the critical classes, which I discuss in the following sections. The diagrams cover aspects of the overall model: the XML-related classes, the director classes, and the agent classes.

The XML classes

Deployment begins when the deployment instructions file, an XML document that describes the deployment, is processed. I explained the file's structure and contents last month. (See Resources for a link.)

Processing occurs in two phases; the first involves parsing the XML, validating its structure, and capturing and storing critical information. The DeploymentInstructionsParser class and the Node class and its subclasses handle this phase. Figure 2 illustrates their relationship.

Figure 2. The parsing and validation classes



The DeploymentInstructionsParser class drives the deployment. DeploymentInstructionsParser parses the XML with a SAX parser and works in tandem with Node and its subclasses to validate the document structure. Each subclass of Node handles one of the XML document's element types. For example, the NodeRule class validates and extracts information from the rule element type.

During the second phase of processing, the deployment tool builds an in-memory model of the XML document, optimized for speed and resource usage. I could have used the Document Object Model (DOM), but designed my own classes instead, for two reasons. First, DOM is general in scope and thus must be prepared to handle all valid XML. This universality hurts DOM in terms of size and performance. Second, DOM models an XML document through broad entities called nodes, rather than as business-level entities like rules or steps.

Figure 3 shows the relationship between these business-level classes.

Figure 3. The business object classes



Each class corresponds to a tag in the XML deployment instructions document. For example, the Rule class corresponds to the rule element type. An instance of the Rule class corresponds to a rule element in the XML document. It contains the information from the XML document as well as direct references to parts of a rule like requirements, sets, and steps.

The Director and Agent classes

Once an XML deployment instructions file has been parsed and converted to business-level objects, the deployment tool is activated. Two complementary sets of classes carry out the deployment process: Director orchestrates deployment and Agent completes the actual work.

Figure 4 illustrates the relationship between the Director classes and the Agent classes.

Figure 4. The Director and Agent classes



The Director interface comes in two flavors: the LocalDirector class and the RemoteDirector class. RemoteDirector is the client side of the deployment server described in Figure 1.

Think back to Part 2 of this series; the full implementation of the deployment tool, which sports an XML parser, SAX implementation, and business logic and infrastructure, easily tips the download scale at more than 1 MB. In order to reduce download time and memory requirements on the client side, I designed the tool to easily separate into two parts: a heavier server-side piece that doesn't need to be downloaded and a lighter client-side component weighing in under 50 KB. I traded overall applet size for network communication between client and server. The code, in either case, is almost identical; another win for modularity.

All Director objects implement a direct() method, which initiates the deployment. It takes one parameter -- an Agent object.

All Agent objects implement the method performAction(). A Director calls this method to instruct the Agent to perform deployment-related actions like querying the user or installing a file.

One of my design goals was to make this tool modular and pluggable, which enhances a library's usability by making it easier to extend and customize. This design doesn't dictate a particular interface style. Concrete implementations of the Agent class must plug in an interface.

The code, which can be downloaded from Resources, includes -- by popular demand -- a simple, graphical, wizard-like interface.

Operation

Let's look at the operation of the deployment tool from two perspectives. From the Director side, we see the selection of rules to execute and step implementation within those rules. From the interface side, we see the flow of control and information from Director to Agent and back.

General overview of rule execution

Figure 3 demonstrates the relationship between the deployment instructions' fundamental components. In brief, the topmost component is the ruleset, which comprises one or more rules. A rule comprises one or more steps and must satisfy certain requirements before the steps can be taken. The requirements are themselves rules.

A ruleset forms a tree-like data structure. The rules are the nodes; the requirements are the edges that join the nodes. When performing deployment, the tree is traversed, starting from its root. The steps associated with a rule are performed when all of a node's outgoing edges have been traversed successfully.

Consider the following example deployment instructions file:

<?xml version="1.0"
encoding="UTF-8"?>
  <ruleset>
    <rule name=".">
      <requires name="accept_license"/>
      <requires condition="license_choice=accept" 
name="select_path"/>
    </rule>
    <rule name="accept_license">
      <step type="license">
        <in>
  This software is Copyright (c) 2000, Todd Sundsted.
  Use of this software implies agreement with the terms
  of this license.  Yada, yada, yada...
        </in>
        <out name="license_choice"/>
      </step>
    </rule>
    <rule name="select_path">
      <step type="locate">
        <in>Locate Directory</in>
        <inout name="path"></inout>
      </step>
    </rule>
  </ruleset>


The <ruleset> in the example above contains three rules. The rule named ".", always the first to be evaluated, is the root of the tree described above. The steps in "." won't be processed until the rules "accept_license" and "select_path" are processed first. Since neither requires other rules, their steps execute immediately and in sequence. If both succeed, the steps in "." execute.

Flow of control and information between director and agent

The interface between the director and the agent is tricky because it can be either completely local (within one Java VM) or distributed (across two Java VMs), depending on whether the applet instantiates the LocalDirector class or the RemoteDirector class. Generally, a step in a rule causes the agent to perform an action. The agent is free to implement actions, as well as the mapping between step types and action, in any manner.

  • Print
  • Feedback

Resources