Java Reference
In-Depth Information
In this chapter, we will define an abstract model for Java software deployment. We don't have
the space for detailing everything, because the scene is quite vast. From handhelds to back-end
servers, from smart cards to home PCs, never before has a single technology promised so
much to software deployment, and, conversely, posed so many challenges. Are Java developers
ready for such a challenge?
An Introduction to the Model
In the last chapter, we saw a general definition of software deployment from a network-aware,
service-minded perspective. Now, it is time to bring Java into the scene, getting into the details
of the software deployment lifecycle. Our approach will be desktop and application-oriented,
but it will be useful for all other Java contexts as well.
The Application Helper
Another useful concept is the
Application Helper (AH)
,a program running locally on client
platforms that support the download, physical installation, and subsequent runtime of the appli-
cations to be deployed. Java programmers are familiar with the idea of an
Application
Container (AC)
, namely another process that takes care of our Java program by possibly pro-
viding extra services such as special APIs, system resources access, and so on.
C
AUTION
The Application Helper concept is more general than that of the Application
Container. For example, the Helper could merely launch the application and then ter-
minate. An AC instead is responsible for providing services to the application while it
is running. For example, the Sun Plug-In mechanism described in Chapter 1,
“Deploying Java,” could be thought of as an AH case. Conversely, the applet model
and the JNLP launcher are cases of Application Containers.
We will focus an important part of our model around the AH. As we saw in Chapter 1, for rea-
sons inherent in the nature of the Java technology, the AH-based solution is the most obvious
one. On platforms in which Java code is not the native code (the overwhelming majority of
devices on the market so far, even on Web-enabled desktops) an extra JVM is needed.
Therefore, why don't we add more features to it, given the fact that they come relatively inex-
pensively (we saw in Figure 1.3 in Chapter 1 that the current download size of a JRE is at
least around 5MB) compared to the possible advantages?
