Alternative deployment methods, Part 1: Beyond applets
Examine the software deployment problem and the requirements that a good deployment solution must satisfy
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!
- Part 1 — Beyond applets
- Part 2 — The best of both worlds
- Part 3 — The code
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.
I lived through both of these deployment methods and experienced the process from both sides. Believe me, if you don’t believe it already, both models are tedious and prone to errors — even for small deployments!
The situation seemed to improve somewhat with the introduction of the Web browser. Browser-based applications present no new deployment model. In essence, we return to centralized computing. Instead of the hardware-oriented dumb terminal, we use the browser-based thin client. From the point of view of deployment, the two are the same: server-side computing at its finest. Because of the browser’s ubiquity and general adherence to standards, Web-based applications are easy to deploy — users simply load up one application UI in their browser window. This uncomplicated deployment explains the sometimes perplexing and single-minded devotion many IT managers have for browser-based solutions.
Unfortunately, purely browser-based applications are limited in a number of ways, primarily because a browser is a document-oriented tool with a poor user-interface toolkit. I don’t want to write off the browser completely, but the most successful browser-based applications that I see all remain true to the browser’s origins as a document presentation tool.
So where does Java fit in?
Java reverses the server-centered trend that purely browser-based solutions introduced. Java allows us to build full-fledged, fully functional applications on the client. From a functional standpoint, this is a positive improvement. From a deployment standpoint, on the other hand, Java falls short. But deployment is still not as tedious as it once was, because Java provides the applet method.
In the applet method, we take advantage of the ubiquity of the browser and its support for Java to provide both a distribution method and an application platform. As a result, we get the benefits of the browser and the power of a real client platform, right? Well, kind of.
Applet-based solutions also feature their fair share of issues and problems. Security considerations, download times, browser incompatibilities, and the general mismatch between the browser’s document-oriented model and the user-interface requirements of many applications all limit the applet’s utility as a one-size-fits-all deployment method.
For some of you, this statement may be old news, but the streets today crowd with developers and managers whose exposure to Java is only beginning. Many books, articles, and training courses still fail to really address the darker side of applet-based development. Ultimately, many overlook the question of whether the browser — a tool designed for viewing hypertext documents — is the right tool to deploy an application. In many cases, were the question ever asked, the answer would be “No.”
Luckily, it turns out, even more alternatives exist.
Requirements
In my next column, we’ll begin to design and build one such alternative. In order to guide its development, and (perhaps more importantly) to help you select a commercial deployment solution should you need to use one, I’ve put together the following list of requirements that a deployment solution should satisfy.
Incremental updates
Application deployment is never a one-shot affair. As we all know, vendors release new versions of applications to correct defects and introduce new features. If the application is large (and even if it’s not), the solution should allow us to replace only those components that change.
Versioning
Applications are often built on top of existing libraries and frameworks that have a life cycle independent of the life cycle of the application. Furthermore, two installed applications may require different versions of the same library. The solution should manage a library’s multiple versions in a transparent fashion.
Automatic installation and configuration
The solution should require as little manual installation and configuration as possible — preferably none.
Centralized inventory
Even though application installation is distributed, it’s often useful to maintain a centralized inventory detailing the types and locations of software installed, and the version of each component. The solution should support this functionality.
Security
The issue of security can be broken up into two distinct but related concerns. First, only authorized users should be able to install an application. Second, the end user must feel confident that the application he or she installs is the application he or she intends to install (i.e., it hasn’t been tampered with during transit or at some other point).
Scalability
The solution must not run out of steam just because the application doubles in size, or the user population grows larger.
Support for heterogeneous environments
Thanks to Sun’s firm grip on Java, the language and associated libraries constitute a largely homogeneous platform. The environment in which Java exists, however, is not nearly as homogeneous. Any deployment solution must recognize and deal with the differences that do exist from environment to environment. Consider the question of where configuration information is stored. I can think of nothing more irritating than installing a Java application on a Unix box that insists on installing itself as if it were running on NT.
Live updates
Strictly speaking, live updates aren’t a firm requirement, but still remain useful in some situations, typically when the client requires business logic that must be updated. Live updates may include the update of Java code as well as auxiliary resources.
Licensing
In the real world, applications consist of licensed code or contain components governed by license. The solution must, at the very least, include provisions to monitor the installation of licensed components.
Conclusion
I hope I’ve shed light on the topic of deployment and the attraction that applet-based deployment strategies hold. I also hope that I’ve presented a strong case for the importance of looking beyond applets, towards solutions and strategies that overcome applets’ difficulties and limitations. Next month, we’ll look at designs that meet subsets of the requirements mentioned above.
