Connection to the Deployment Server is very useful for AH, so that a variety of more
sophisticated choices are possible.
For an antivirus application, for example, an extra service (performed in the AH On-The-
Run Management Phase in Figure 2.5) could check to see whether the locally installed
antivirus has been itself infected and, in this case, could offer some server-related recov-
A variety of connection-related policies are possible. For example, we could allow clients
to always make an attempt to connect to a server. Or, we could present the client with an
option only when a connection is available. Finally, we could specify when to establish
the connection (connecting at the end of a session doesn't slow down the application
startup. Updates and other changes are effective only from the next session).
• Distribution Policies his set of policies pertains to the server side of the deployment
process. An example of this group of policies could be the replication policies for
Deployment Servers organized in a network. This type of policy is actuated by the
Distributor in the DS Management Phase (refer to Figure 2.5).
• Policies Based on Different Client Properties This set of policies applies to the client
side of the deployment process and may involve, for instance, the specification of the
JRE version needed to run the application.
• Client Updates Policies The software owner could want to be sure to specify how and
when the Application Update Phase is executed. Another important attribute that is often
useful is the relation of the Update Policy to the End-User's intervention. So, updates
could be performed explicitly or in the background, without even letting the user know
what is going on.
As an example of this group of policies, we can think of scheduled updates—each
month, for instance. Another common policy is the definition of whether to ensure that a
given release is installed by a given group of users as mandatory. This gives the certainty
to Deployment Engineers (see Chapter 4) of the deployed units on client platforms.
Finally, the more common policy is to leave updates as a user's preference, specifying
whether the AH should prompt for new updates checked at every AH-DS Connection
Phase (refer to Figure 2.5), or leave it up to the user's initiative.
• End-User Policies Designed together with users' definition and related information,
these policies may regard the authorization for some classes of users to perform some
operations on AHs, or to be aware of new software releases and of which kind. Typically,
a hierarchy of accesses to given software editions is the chosen mechanism for complex
user definition scenarios. When developing software for consumers, it is often preferable
to make evaluation-type of users aware of new releases that are available only by pay-
ment. This is a case of deployment techniques being used as marketing means (refer to
Chapter 1, “Deploying Java”).