( AH Launch and Resolution Time +
JVM Launch Time +
Application Launch Time ) * Number-of-Runs.
Let's discuss this formula, as well.
•Now,as the number of runs increases over time, the initial installation costs get repaid.
This justifies the usage of this technology for End-Users who will use the application
quite often. In cases where the total number of runs is small, there is no incentive in
using it for End-Users. This is, again, similar to what is said in Chapter 1. It is some-
times called the “plug-in syndrome”, in which users browsing the Web are unwilling to
download a bulky plug-in requested when browsing some trendy site.
• Another common-sense piece of advice comes from thinking about the number of differ-
ent applications managed and installed by a single AH. When there are more applications
installed by the same AH (the second addendum becomes a sum itself together with the
last one) the AH installation cost also gets negligible in time, so that it could be thought
of as being paid back when compared with other technical solutions. As we will see (also
in Chapter 3), this is a strong incentive to promoting a single-AH Java deployment tech-
nology for consumer diffusion.
•In limited computational resource client environments, the AH installation time could be
negligible, given the size of resources to be distributed and installed, whereas the JVM
launch time could be zero on Java native platforms. What can become critical then are
the other costs associated with each executable run, especially in consumer applications.
An unexpected critical cost could be during the AH Check-Out Phase, represented by the
preceding AH Launch Time figure, especially for wireless and other bandwidth-critical
The preceding considerations look ideal for a limited, well-controlled environment, in which
such “heavy” initial costs could be afforded or imposed, and in which the number of times the
installed applications will be executed is predictably high. In this scenario, the adoption of a
Java-based sophisticated deployment technology could make economic sense, not only for
software producers taking advantage of Java's features, but also for software consumers. This
is the typical case of an organization producing its own software to be deployed to its own
employees through an intranet or an extranet. Then, the costs of deploying the software on the
organization's client platforms will be paid back over time.
We will see some techniques to reduce such costs depending on the situation, when dealing
with the developer's side of the Java deployment process, in Part II of this topic, “Deployment