This appendix contains some useful reference material for this topic's contents and for practi-
It is useful for a fast lookup when in need of some practical advice for solving a deployment
problem. It is not a substitute for the topic contents; instead, it is a succinct, alternative organi-
zation of the topic material structured in a hands-on fashion.
The first section is a very short summary of what was provided in Chapter 4, “Designing for
Deployment.” The second section proposes several useful categorizations of the many exam-
ples proposed in this topic. The third section provides some details about the Unified Modeling
Language (UML) formalism for documenting deployed software artifacts. Finally, the last sec-
tion discusses some legal material involved with the redistribution and usage of third-party
software modules, a common practice for Java developers.
Deployment Design in a Nutshell
This section succinctly summarizes what was discussed in Chapter 4 and other chapters of this
topic. It assumes a previous reading of the whole topic.
To design a deployment circuit for a Java application is a complex task that involves many con-
siderations. Here, we will describe briefly the main decisions involved. For a complete discus-
sion, see the chapters of Part II, “Deployment Engineering,” especially Chapter 4.
To reduce it to the bare essentials, we can think of the deployment design activity as a three-
step sequence, in which deployment engineers have to define exactly the wanted deployment
services, how to implement them in Java, and implement the planned deployment circuit using
the chosen Java technologies.
1. Define the Required Deployment Services
The first step is to clearly determine which deployment services will be required by client
applications. Chapter 4 defines a standard list of the most common deployment services.
2. Decide on the Deployment Technology
When choosing the deployment technology, two choices are possible: choosing a standard
deployment technology (JNLP, applets, or some third-party deployment tools) or building your
own deployment means. This latter choice is much more complex and expensive than cus-
tomizing a general-purpose, ready-to-use deployment technology.