• An about dialog utility JDialog subclass (Listings 13.4—5). Useful for implementing the
application about box, it provides a built-in mechanism for inspecting the currently
installed application modules. It uses the JNLP Label widget.
• The utility package in Appendix D discusses a general purpose JNLP utility library ready
to be used in JNLP-deployed applications. Such a library emulates to some extent the
JNLP runtime environment client that applications use. In this way, programs could be
launched seamlessly via JNLP or as standalone applications. It includes an extended ver-
sion of the Utilities class presented in Chapter 11, “Runtime Client Services.”
Advanced Ad-Hoc Deployment Services
For deployment engineers who cannot resort to the previous examples or standard deployment
solutions, this topic also provides examples of complete deployment solutions to be adapted to
the given situation. Such packages are inherently complex, and differ from the code described
in the preceding subsections because these are intended as complete, self-standing deployment
solutions—not episodic, circumscribed code examples. Following this line, source code is
accompanied with architecture discussions and other considerations.
The following two solutions can be adapted to practically meet any deployment needs. They
differ (apart from the scenario) in that the first example is built totally from scratch, and the
second relies upon the applet model's basic deployment services.
• The bank package (see Chapter 6) provides a full-blown deployment solution using a
custom Application Helper. It shows the widely used classloader mechanism, as well.
• The deploylet package (see Chapter 7) supplies a full-blown deployment solution that
doesn't require an Application Helper. It uses the Plug-In technology for J2SE applets.
Using UML for Deployment Documentation
In this section, we will see the Unified Modeling Language (UML) formalism for software
deployment. Like deployment itself, UML deployment diagrams are often overlooked by tech-
nical writers and developers, who prefer to concentrate their efforts on more “popular” UML
model diagrams, such as static class, use-case, and scenario diagrams. The so-called UML
“physical” diagrams are of two types:
• Deployment diagrams. They show the physical relationships among software and hard-
ware components in the installed system. They are composed of nodes , representing
some type of computational item, often a hardware unit (from a back-end server to an
embedded device). Then, we may have connections among nodes, showing the commu-
nications paths over which the application communicates with the other nodes.