Its architecture is composed by an AH to be installed on the client platform. It consists of a
server-side application that implements the Deployment Server together with a repository facil-
ity for the resources to be deployed.
The whole system is Web-centric in that the Deployment Server is implemented though
servlets operating with standard Web and application servers such as IBM Websphere, Apache
(Tomcat and JServ), and Bea WebLogic. On the client side, the AH works together with an
applet, and the Web browser is fully integrated.
The DeployDirector software architecture is built around four main components:
•Client Application Manager. The AH being installed on the client platform. JNLP clients
are also supported, Web Start included.
• Server Application Manager. The server-side software tool for managing the Deployment
• The Vault. The repository for resources to be installed on client platforms. It resides at
• The Remote Administration Tool. The GUI console is used to set deployment policies,
prepare resource descriptions, and manage the other services available to this deployment
To the server side, DeployDirector lists many interesting features, including the following:
• Deployment Servers' reliability tuning through server redundancy and replication, using
the concept of clusters of Deployment Servers.
• Deployment Server-Application Helper connection optimized through a fine-grained,
byte-level differencing mechanism.
• Security. The Deployment Server-Application Helper connection could be secured using
SSL. Resources are accessible through a two-step process of authentication and autho-
•A user-friendly GUI that centralizes the management of all deployment policies, soft-
ware publications, and management data for the administrator (on Deployment Servers).
•A high level of customization, provided to developers by means of a pluggable class
• On-The-Run-Management services such as an extensive logging service of client opera-
tions on Deployment Servers.
On the client side, other remarkable features are as follows:
• Multiple JRE management. This allows the central organization of JREs, locally man-
aged by the AH.