Infrastructure for Distributed Deployment of J2EE Applications

Downloads and useful links

To ease the task of J2EE application deployment, especially in distributed environments, we have developed an infrastructure for automatic dynamic multi-host deployment of J2EE applications, which specifically addresses the following issues:

The infrastructure defines two Architecture Description Languages (ADL) for component and link description and component assembly respectively:

Infrastructure architecture
Fig. 1. Infrastructure architecture.

The usage of the infrastructure consists of the following set of steps (see Fig. 1):

  1. Initialization. The infrastructure is initialized with a description of available application server nodes.
  2. System components and application registration. The descriptions of system and application components as well as links (written in the Component Description Language) are registered with the Component Registry Service.
  3. Writing the deployment path specification. The application deployer writes a deployment path specification in the Component Assembly Language, where s/he specifies the placement of components on the server nodes and links that connect them. The deployer may choose to write the specification by hand, or to use a GUI-based path editing tool (see Fig. 2), which also serves as a user-friendly portal to the Replication Management Service.
  4. Preparing the application path. First, an application deployment specification is submitted for preparation to the Replication Management Service. This service performs initial validation and passes the deployment specification to the Replica Configuration Service, which in turn attempts resolution of application component dependencies on system components. If all component dependencies successfully resolve, the Replica Configuration Service configures each component replica, trying to match any previously deployed component replicas to replicas in the new application deployment based on their configurations. All new component deployment configurations are then persistently stored in the data storage. This last step is called committing the prepared path.
  5. Deployment of prepared path. When the application deployer requests deployment of the prepared application path, the Replica Deployment Service issues deployment requests to appropriate Infrastructure Agents, running on nodes involved in providing services for this path (step 5a). These agents, in turn, request deployable bundles of component replicas (scheduled for deployment) from a Deployment Unit Factory Service, located on a nearby node (step 5b). The Deployment Unit Factory Service locates the corresponding replica configurations in the persistent storage and generates a properly configured deployment bundles (step 5c), which are then shipped to the requesting agent. The agent deploys them in an order that respects deployment dependencies.
  6. Management of deployed paths. The infrastructure maintains a registry of prepared paths, deployed paths and current state of application and system component deployments. The application deployer may request undeployment of previously deployed paths which will result in undeployment of component replicas that are exclusively used by the undeployed path.

The GUI path editing tool
Fig. 2. A screenshot of the GUI path editing tool with a sample two-node deployment of the Java Pet Store application.

We have implemented the infrastructure as a part of the JBoss open source Java application server, utilizing its extensible micro-kernel architecture, based on the JMX specification. We have also developed a GUI tool serving as a Replication Management Service client. With this tool, infrastructure users may:

Downloads and useful links

Back   Back to the Home Page of Alexander Totok

Back   Back to the PDSG Home Page

Last update: Sunday, November 20, 2005.