Customizable Deployment, Composition, and Hosting of Distributed Java Applications

Abstract

Abstract. Deploying and running Java applications on a single host is covered by standard approaches. However, when applications are dynamically deployed on distributed hosts, the situation is quite different. In this context, applications are likely to be composed of classes, located in remote repositories and possibly related to identical class names. Hence, the typical class loader approach is no longer feasible to resolve the right byte code. Moreover, the native Java Runtime Environment (JRE) has originally not been designed to host more than one application concurrently within a single Java Virtual Machine (JVM). Thus, there are also unresolved issues concerning hosting distributed applications. In this paper, we present a new approach for a customizable Java application middleware with respect to the topics of application deployment, composition and hosting. Finally, the application of the approach within a distributed middleware platform is presented, wherein applications are customizably deployed, dynamically composed and concurrently hosted.

Separating the Concerns of Distributed Deployment and Dynamic Composition in Internet Application Systems

“…Finally, the developer uses a helper tool mddeploy to upload the JAR files, the collection and module configuration files to a participating module repository. As a result, the configuration files can be used to inspect the module as well as the constraints of the underlying JAR files without actually downloading them from the repository, as described in section 3.3 and in [26]. In case a module represents a new application to be published on netzspannung.org, it must be registered with its module id in the application list of the site configuration by the administrator.…”

“…Thus, in order to support the composition of modules in different variants within the same JVM, we have to use and manage several class loaders. This problem has been also addressed by our previous work introducing so called class spaces [26]. They enable developers and administrators of Internet application systems to configure exactly which Java classes and class collections are shared across or shielded from other concurrently loaded applications.…”

“…Finally, the module approach has been implemented in Java in conjunction with class collections and class spaces [26]. It offers developers of components, configurators of applications and administrators of Internet platforms a unique way to separately define physical deployment, logical composition and configuration of Java components.…”

Project centralization based on graph coloring

“…Next, function EquationSolver (see Alg. 2) is called to solve the constraint equations iteratively for the ordered nodes until reaching the least fixed point (lines [18][19][20][21]. The last step colors the constraint graph of each node and performs normal renaming substitution (lines [22][23][24][25].…”

“…However, it does not share common code either. To share common code, Paal et al [20] propose a customizable hierarchical class loader approach to separate the component-based application space so that two applications that share the same system class loader share all the code loaded by the system class loader. However, this approach requires manually configuring the hierarchy of class loaders.…”