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 1: Beyond applets

Examine the software deployment problem and the requirements that a good deployment solution must satisfy

By Todd Sundsted, JavaWorld.com, 05/12/00

  • Print
  • Feedback
.
You designed your client's next big Java-based application, and now you must plan for its deployment. The end-user population consists primarily of several hundred nontechnical administrative personnel in offices that span four time zones. When the project is complete, you and five other developers will make up the deployment team. Painfully aware that "a project that's not delivered is a project that's failed," you start to consider your options.

Alternative deployment methods: Read the whole series!

This month, I begin a series of columns on Java application deployment. As the scenario above indicates, deployment is an important part of the complete software life cycle. As such, it deserves careful study. In this first article of the series, I'll provide an overview of application deployment and present the requirements that good solutions must satisfy.

Deployment through the ages

Let's begin with a bit of history.

Deployment wasn't as large an issue when all applications ran on the mainframe down the hall and all the end users had dumb terminals on their desks. Only after desktop personal computers and client/server computing arrived on the scene did deployment become a concern. The combination of a powerful computing device (the personal computer) with a powerful computing model (client/server) sparked a revolution in software development. It also introduced some new problems.

Client/server applications come in two parts: client-side and server-side. During development and testing, both parts live in a highly centralized, homogeneous environment. When development and testing are finished, however, the client part of the application must circulate to the users.

The problem, then, lies in shifting the client from the controlled, homogeneous environment in which it was developed to the realm of the application users, and then configuring the client so that the end users can actually use it. Suddenly, deployment becomes synonymous with pain. Let me explain why.

The traditional deployment models introduced during this early era were the foot-and-hand model (in which you run around on foot and install the software by hand) and the self-service model (in which end users install the software themselves).

Self-service deployment is a viable option for simple applications. Almost everyone (the key phrase being "almost everyone" -- remember the target audience) knows how to install an application on his or her machine, right? Unfortunately, as the complexity of the installation and configuration process increases, so does the support time, and this alternative begins to resemble the foot-and-hand installation.

Foot-and-hand deployment works well because someone else completes all the work for you. However, as this method is labor intensive, foot-and-hand installation costs companies too much time and money.

Self-service doesn't work for complex installations, and foot-and-hand doesn't scale well. To perform more installations, you either need more people or more time, virtually in direct proportion.

  • Print
  • Feedback

Resources