Java Reference
In-Depth Information
cutable to be installed first, thus requiring endusers to download from 5 to 8 MB of potentially
useless data on their computers (see Figure 1.3). As we will see in Part III, solutions like the
JNLP protocol can be used to simplify installer utilities as well.
1
A problem with installer software is that the resolution phase is performed after the installer
download locally on the client machine. As we will see, the resolution phase is when the client
or the server, or both —depending on the particular software design— has realized what
resources need to be installed on that machine. Knowing this before the download can save
bandwidth, but places the burden of the resolution phase on possibly over-busy servers.
Furthermore, some installers comprise management data useful only to the installer utility
itself that eats up bandwidth. Examples of this are messages for a dozen or so supported lan-
guages. Bandwidth problems aren't to be overlooked by optimistic scenarios, because bottle-
necks arise from contingent causes as well. When installing software at the office, for example,
the particular hour of the day can hinder the swift download of the required software, if not
block it completely.
Another observation on installer utilities is that they don't cover the stages in the application
lifecycle such as the update. These stages are left to other helper utilities or to the whim of the
developer.
When examining the impact this kind of deployment software has on organizations, it is
important to note that installer utilities per se don't completely exclude the role of the deploy-
ment system administrator. This is in contrast to the applet case and partially the Plug-in solu-
tion (in this case, the Plug-in installation could be performed by specialized workforce as
well).
Application Management Tools
We have discussed all the main deployment techniques available for Java developers. Now it is
time for something quite unpopular to the Java platform. Traditionally, deployment was a ser-
vice that was part of the system administrator's responsibility. It is now natural to see software
application management solutions providing deployment services and vice versa.
Multiplatform application management solutions implemented in Java are something we will
not see in the near future for several reasons. Java is such a general platform that it has not yet
developed some centralized administration facilities, at least restricted to some platform edi-
tions. On the other hand, it is worth mentioning them to better grasp the weak points of Java in
this area. First, given the very nature of the Java platform, it is difficult to reach the nuts and
bolts of operating systems to the level of detail needed by application management solutions.
Because Java is a somewhat anarchic platform on the client side, lacking of centralized support
for basic services such as a persistent registry or standard equivalents, administrative features
such as the remote management of client installations is quite difficult to achieve. Appendix C,
“Other Deployment Technologies” provides material on this class of management tools.
