Dynamic Component Deployment and (Re) Configuration Using a Unified Framework

DYNAMIC COMPONENT DEPLOYMENT AND (RE)CONFIGURATION USING A UNIFIED
FRAMEWORK
Abdelmadjid Ketfi
Adele Team Bat C
LSR-IMAG , 220 rue de la chimie, D. U. BP 53
38041 Grenoble Cedex 9 France
Abdelmadjid.Ketfi@imag.fr
Noureddine Belkhatir
Adele Team Bat C
LSR-IMAG , 220 rue de la chimie, D. U. BP 53
38041 Grenoble Cedex 9 France
Noureddine.Belkhatir@imag.fr
Abstract
Permanent and uninterrupted functioning can be some-
times a requirement for some kinds of software systems.
This is especially true in the case of complex and distri-
buted systems where stopping and restarting the system
constitute a tedious and costly task, also when the system
must be highly available or when its execution environ-
ment changes frequently. Many component technologies
exist today and solve hot (dynamic) deployment and re-
configuration issues offering ad-hoc solutions. This paper
presents DYVA, a unified framework, that has been de-
signed to be suitable to hot deployment and reconfigura-
tion for most of the currently component technologies.
Components from these technologies have to satisfy com-
mon features like encapsulation, interfaces, etc.. The pro-
posed framework is based on a model-driven approach.
This approach helps in developing specific hot deploy-
ment and reconfiguration systems by the personalization
of the unified framework. The personalization is done via
plug-ins which make transformation between specific
component descriptions and more general ones.
Keywords: Dynamic deployment / reconfiguration, Com-
ponent, MDA, Metamodel, Framework.
1 INTRODUCTION
Component-based software (CBS) engineering focuses
on building large software systems by integrating existing
software components [1]. The old notion of developing a
system by writing code has been replaced by assembling
existing components. In general the deployment of a CBS
is considered in a static way: only situations where the
software is deployed from scratch are considered, and when
the update is supported a complete software stop is re-
quired.
For some critical and highly available software sys-
tems the dynamicity is considered as an important criteria
to guarantee an acceptable availability and quality of ser-
vice. In this paper, by dynamic we mean the ability to re-
deploy and to reconfigure a running system to take into
account some new conditions, sometimes unpredictable,
without completely stopping it. The development com-
plexity and cost constitute an important problem in front of
the creation of supports responsible for the dynamic dep-
loyment of software systems. The work we present in this
paper contributes in solving the problem of cost and com-
plexity of dynamic deployment supports building process.
Our proposed approach shares the same ideas with MDA
(Model Driven Architecture) [2] which is an approach to
software development using models.
This paper is organized as follows: Sections 2 and 3
discuss our motivations for this work and present some
basic hot deployment concepts. Section 4 presents some
approaches dealing with the hot deployment problem fol-
lowed by a synthesis. Before we conclude, Section 5 illu-
strates the main axes of our approach.
2 MOTIVATIONS
Dynamic deployment is strongly required for many ap-
plication types. The following scenarios illustrate some of
these applications:
♦ E-commerce and highly available applications can-
not be stopped for economical reasons. Stopping
these applications may seriously affect the quality of
service and decrease the clients confidence. Amazon
portal for example has to respond daily to many mil-
lions of requests and stopping it for maintenance
should be very negative.
♦ Distributed and large scale applications require a
considered effort to be stopped, updated, rebuilt and
correctly restarted. It is interesting to update when
necessary only specific parts of these applications
without being forced to stop the whole application.

♦ Embedded applications by their nature require a re-
mote intervention while they are running. Satellite
television terminals and also recent car systems are
a good example of embedded applications remotely
deployed and reconfigured.
♦ Some applications (multimedia applications for ex-
ample) must respond to requests of heterogeneous
clients (PCs, PDA, Phones…). These applications
must be able to dynamically adapt their answers ac-
cording to the clients capabilities (memory, display,
bandwidth…).
The following section presents some basic concepts re-
lated to the hot deployment and reconfiguration of compo-
nent based applications.
3 BASIC CONCEPTS
Figure 1 presents the deployment life cycle related to
component-based applications. The main difference with
the classic deployment life cycle (of monolithic applica-
tions) resides in the nature of the applications themselves: a
component based application is made of a set of well de-
fined pieces. The deployment can be made incrementally
and the re-deployment may concern only some specific
pieces and not the whole application. In the case of hot
deployment the target application continues to be executed
and only the re-deployed components are stopped.
Figure 1. Deployment life cycle
The deployment life cycle includes many basic activities.
These activities and potential relations between them are
illustrated in Figure 1.
Configuration: a component may have many ver-
sions and many implementations for different oper-
ating systems for example. The configuration con-
sists of selecting the appropriate components ac-
cording to the target platform, packaging them with
their depending resources. According to the compo-
nent model, a package may contain one or many
components.
Install: consists of transferring the application
packages from a storage repository to the target site
or sites.
Activation: after the components are injected with-
in the target environment, they have to be loaded
and started in order to use their services.
De-activation: for different reasons, a component
or a set of components have to stopped and un-
loaded.
Update: consists of reinstalling some components
already installed, or adding new components to an
application previously installed.
Reconfiguration: means the modification of the in-
stalled application using the elements already avail-
able on the site (without need for re/installing other
components). For example disconnecting two com-
ponents or plugging a component in the place of
another, both present on the site.
De-install: consists in removing from the target site
the components no longer used.
The main difference between static and hot deployment
is related to the behavior of the application during the re-
configuration/update. Hot deployment means that only the
components concerned by the reconfiguration are de-
activated when the other components continue to be ex-
ecuted.
Many existing component technologies provide explicit
support for deployment. Such a support is generally based
on some deployment descriptors and some tools to effec-
tively deploy the applications on the target environment
with respect to the provided descriptors. These tools are
also sometimes used to instrument as later as possible the
components binary code and/or to generate objects com-
monly known as containers and responsible for the man-
agement of the deployed components.
In general a deployment descriptor gives some informa-
tion related to component types, interfaces, implementa-
tions, and to some system properties (transactions, securi-
ty…). However, there is no information in general about
the dynamic behavior of components. For example how to
know that a component can be replaced, removed or mi-
grated and how to know that a connection is required, dy-
namically modifiable, etc.
4 STATE OF THE ART
This section gives a synthetic view of research work in
the field of dynamic deployment and adaptation. It is true
that the deployment has been highlighted and have taken
importance since few years, however, dynamic applications
adaptation is a very old problematic [6].
According to the used programming model, many re-
search approaches were proposed to support the deploy-
ment and adaptation of applications at run-time.

♦ Procedural approaches: they aim in general to dy-
namically replace one procedure by another. For ex-
ample DYMOS (Dynamic Modification System) [7]
developed in 1983 by Insup Lee, provides a com-
plete embedded environment for application (based
on StarMod language, similar to Modula) develop-
ment, execution and adaptation. At run-time the de-
veloper can modify one or many procedures and ask
the system to replace these procedures in memory.
Another similar system called PODUS (Procedure-
Oriented Dynamic Update System) [8] allows many
versions of the same procedure to be loaded and
used at run-time. The main challenge in such ap-
proaches is related to the replacement of active pro-
cedures (procedures in execution) and to the re-
placement of a procedure by another without the
same signature.
♦ Modular approaches: based on modular program-
ming languages, these approaches aim to replace at
run-time one module by another. Polylith [9] devel-
oped at Maryland University since the middle of
the Eighties is the more representative system in this
category. Based on C language Polylith has the
same concepts as today middleware systems. It pro-
poses a support for developing, running and dynam-
ically reconfiguring distributed applications.
♦ Object-based approaches: one of the main limita-
tions (related to dynamic deployment/adaptation) of
object-oriented programming languages like Java
(versions under Java 1.5) and C++, is the inability to
reload already loaded classes. Java offers the class
loader mechanism1 that can be used to unload and
reload classes however the programmer is responsi-
ble for implementing the necessary code (of class
unloading and reloading). Too much work have
been done in order to extend Java (Dynamic Java
Classes [10]) and C++ (Dynamic C++ classes [11])
runtime environment in order to transparently sup-
port these primordial two operations.
♦ Component-based approaches: these approaches
aim to provide support that allows to deploy com-
ponents at run-time [12, 13]. These components are
injected to extend the application or to replace other
components already deployed and even activated.
Unlike object-oriented applications component pro-
gramming supposes that the implementation of
components is explicitly separated of their assem-
bling (components do not contain architectural in-
formation). This separation implies that an explicit
architecture can be obtained at run-time which is
very important to be able to dynamically acting on
this architecture (plugging a component in the place
of another, reconnection…).
1 A class loader is a Java class responsible for loading other
classes.
Synthesis
After analyzing the previous approaches and in particular
those related to component-based applications, two aspects
can be noted:
• It is generally recognized that information related to
deployment has to be specified outside the compo-
nents implementation. This information is concretized
as metadata stored in descriptor files. In general a
deployment descriptor is a set of key/value pairs. Ob-
viously the set of keys recognized in a component
technology are not generally the same recognized in
another technology.
• The other important point is related to the techniques
used to modify the applications at run-time. Many
techniques can be listed however the “great” idea be-
hind these techniques is the same. This idea is based
on the ability to reify the connections between the ap-
plication elements and to act dynamically on these
connections. The reification can intervene at different
levels, and here the used approaches can be different.
o The first approach is based on the modification
of the virtual machine in order to add a support
for the dynamic adaptation. This technique has
been applied in the Dynamic Java Classes de-
scribed above. The advantage of this first tech-
nique is that all applications running on top of
the modified virtual machine benefit automati-
cally from the dynamic adaptation capabilities.
o The second approach supposes the reification
at the application level. Many techniques are
generally used to concretize this reification.
Containers2
are for example the commonly
used technique to reify connections in compo-
nent based technologies. They are particularly
inserted in order to apply some necessary sys-
tem services (security, transactions, mapping
with databases) before transferring the calls to
the wrapped components. Also AOP (Aspect
Oriented Programming) [14] is a widely used
technique based on the instrumentation of ap-
plications in order to inject additional code.
This code allows for example to catch the con-
trol flow at specific points in order to apply
some actions (tracing calls, checks…).
5 UNIFIED FRAMEWORK FOR SUPPORTING HOT
DEPLOYMENT AND RECONFIGURATION
5.1 Overview
Recently we specified and developed an ad-hoc dy-
namic reconfiguration framework for JavaBeans [15] based
2 In practice a container can be a dynamic proxy (EJB/JBoss), a
static generated interceptor (EJB/Jonas) or any other intercep-
tion object.

systems [16]. The role of this framework is to take in
charge the dynamic reconfiguration of systems developed
according to JavaBeans component model. The reconfigu-
ration is performed almost transparently and needs a mi-
nimal participation of the user. This framework allows for
example to replace a component by another one, it allows
also to change the system architecture by changing the
connections between components, by adding or removing
components.
In the context of another project, we developed a simi-
lar dynamic reconfiguration framework for OSGi [17], a
component model in which components plug insto a basic
framework and allow to create applications in an incremen-
tal fashion at runtime [18]. This dynamic reconfiguration
framework allows practically the same dynamic reconfigu-
ration operations listed above.
After these experimentations and after studying the
deployment and other dynamic aspects related to two other
component technologies (EJB and Fractal [19]), some basic
concepts seemed to be apparent and shared by both models
as for instance the dynamic deployment routines and
process. This observation was a key element that motivated
us to work on a hot deployment and reconfiguration (HDR)
framework. By HDR framework we mean the software
responsible of the dynamic deployment and reconfiguration
of a component based application.
5.2 The conceptual idea
A unified framework can be reached by introducing an
abstract component model which is endowed by capabili-
ties to support the dynamic deployment/adaptation. This
abstract model is intended to be representative of the tar-
geted component models and constitutes a basic step to-
wards a dynamic deployment/adaptation framework. By
analogy with MDA the abstract component model corres-
ponds to a PIM. The next section describes this abstract
model and shows in what way it can be used.
Figure 2. The conceptual idea of a hot deployment
framework
Figure 2 illustrates the basic idea of our approach. The
first step is to analyze the most representative component
technologies especially according to the deployment and
dynamic aspects.
The abstract component model presented in the follow-
ing section is one of the pieces resulting from the unifica-
tion process.
It is important to know that modifying an application at
run-time requires at least a precise knowledge of its archi-
tecture. In addition to this architecture it is necessary to
master the interposition technique used to wrap the compo-
nents and to transparently apply low level treatments (re-
biding for example). In our approach, it is supposed that
the framework is responsible for maintaining the applica-
tion architecture (represented according to the abstract
component model), for deploying the components binaries
(and their resources) and also for the activation of these
components. The activation is a critical task that must be
controlled by the framework in order to insert the required
containers that are responsible for managing the dynamic
deployment and reconfiguration. At run-time the adminis-
trator can use a deployment/reconfiguration interface in-
cluded in the framework to dynamically act on the applica-
tion.
5.3 Abstract component model logical view
Figure 3 shows a logical view of our abstract compo-
nent model which captures the main logical concepts that
can be found in other component models like JavaBeans
and OSGi. Some points deserve to be underlined:
- A component may require some ports and provide
some ports needed by other components.
- We make an explicit distinction between a com-
ponent (specification and implementation of a
software entity) and a component instance (the
component used in a specific system or part of a
system).
- The model is hierarchical: a Component can be a
primitive component or a CompositeComponent
that is also considered as Component and made of
a set of component instances (may be intercon-
nected).
- The model is only descriptive and is not intended
to be executable (there is not a runtime machine
associated to this component model).

Figure 3. Abstract component model
5.4 Dynamic reconfiguration framework architecture
Our framework is based on the abstract component
model presented above. It is structured in several modules
as shown in Figure 4.
Deployment/Reconfiguration manager
It is the central part of the framework. It provides and im-
plements the basic dynamic deployment and reconfigura-
tion routines. These routines operate on the system abstrac-
tion (and not directly on the base-level) which guarantee
the independence and the genericity of our unified frame-
work.
Supervisor
The role of the supervisor is to allow the auto-
reconfiguration/deployment of applications. It represents a
reasoning engine that introspects or receives events from
the system and its environment and takes decisions accord-
ing to these events and according to some reconfiguration
and deployment policies. Events are forwarded to the su-
pervisor by special objects (supervision objects) included
in the administrated system, or by some tools dedicated to
the environment supervision (bandwidth, load, security,
memory…).
Reconfiguration policies
Some policies are required to make possible the auto-
reconfiguration of applications. Auto-reconfiguration
means the ability to take consistent dynamic reconfigura-
tion decisions without the intervention of an external actor
(usually a human administrator). The current specification
of reconfiguration policies is very primitive. It considers a
very simple form of reconfiguration rules. The improve-
ment of this specification is one of our perspectives.
Figure 4. Hot deployment framework architecture
5.5 Personalization of the framework for a specific
component technology
The unified framework is not a complete deployment
and reconfiguration system ready to use. This is because
the framework is not dedicated to a specific component
technology and intended to be generic. To use the system
in practice, it is necessary to complete and to personalize it
for a specific component technology.
For each component technology it is necessary to de-
velop two specific plug ins (tools that will be plugged to
the framework): a deployment and an activation plug ins.
The connection of two components is performed with
respect to their attached properties. If a component is de-
clared as dynamically reconfigurable, the activation plug
ins inserts an interposition object between this components
and other ones. Thanks to this interposition object, the
reconfiguration system is able to perform the replacement
even at run-time. If a component is declared as migrable,
the interposition object will be based on RMI in order to
establish a remote connection with the transferred object.
Finally if a component is neither reconfigurable nor migra-

ble, it is directly connected to other components without
using interposition objects.
The creation of interposition objects depends of the
target component technology. Three situations can be con-
sidered:
The target component technology does not support
containers: for example in the case of JavaBeans and
OSGi. This is the easiest situation because the activa-
tion plug ins has to create a new interposition object
from scratch.
The target component technology supports extensible
containers: for example in the case of Fractal, con-
tainers can be implemented as controllers. These con-
trollers are extensible and needed dynamic reconfigu-
ration aspects can be added. In the case of Frac-
tal/Julia implementation for example, the provided
controllers support binding mechanisms needed for
the dynamic reconfiguration and deployment.
The target component technology supports non-
extensible containers: for example EJB/Jonas and
EJB/JBoss. In this case it is necessary to modify the
system responsible for the generation of the contain-
ers in order to add the required mechanisms that al-
low to re-deploy and to reconfigure components dy-
namically.
6 CONCLUSION AND PERSPECTIVES
This paper describes DYVA, a unified framework for
the hot deployment of component-based applications. This
framework is targeted to existing component models. It
takes in charge all complex tasks related to dynamic recon-
figuration and allows developers to focus on the business
logic of their systems. As proof of concepts, the versions
we implemented for JavaBeans and OSGI models confirm
the validity of our approach that seems to be very promis-
ing.
The meta-modeling has proved a real importance espe-
cially with the appearance of many standards and metho-
dologies like MDA, the recent OMG initiative. The ap-
proach we presented in this paper lies within the same
scope, it is based on a meta-model that provides an abstract
view of concrete application and allows to build a unified
hot deployment framework.
The next immediate step is to continue our experi-
ments with others component models. The objective is to
gather all common features of software components that are
necessary for the unified framework. Other near future
work includes the integration of the D&C model of the
OMG for configuration and deployment as a basis of the
unified model as well as continuation of the case study and
application of our work to other real world systems repre-
senting other domains, such as those related to autono-
mous computing.
7 REFERENCES
[1] George T. Heineman , William T. Councill, Component-based
software engineering: putting the pieces together, Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, 2001.
[2] John D. Poole, Model-Driven Architecture: Vision, Stan-
dards, And Emerging Technologies: Position Paper Submit-
ted to ECOOP 2001, Workshop on Metamodeling and Adap-
tive Object Models.
[3] S. Ambler, T. Jewel. "EJB fondamental". Eyrolles, May
2002.
[4] JBoss Open Source Application Server, http://www.jboss.org
[5] JOnAS: Java (TM) Open Application Server,
http://jonas.objectweb.org
[6] R.S. Fabry, “How to design a system in which modules can
be changed on the fly”, Proc. 2nd lnt. Conf. on Soft. Eng.,
pp. 470-476 (1976).
[7] Insup Lee, "DYMOS: A Dynamic Modification System",
Department of Computer Science, University of Wisconsin,
Madison, April 1983.
[8] M. E. Segal , O. Frieder. "On-he-Fly Program Modification:
Systems for Dynamic Updating". IEEE Software, v.10 n.2,
pp.53-65, March 1993.
[9] J. M. Purtilo. "The POLYLITH Software Bus". ACM
TOPLAS, vol. 16 (N.1), pp. 151-174. January 1994.
[10] S. Malabarba , R. Pandey , J. Gragg , E. Barr , J. F. Barnes.
"Runtime Support for Type-Safe Dynamic Java Classes".
Proceedings of the 14th European Conference on Object-
Oriented Programming, p.337-361, June 12-16, 2000.
[11] G. Hjálmtýsson, R. Gray. "Dynamic C++ classes - A
Lightweight mechanism to update code in a running pro-
gram". In proceedings of the USENIX Annual Technical
Conference, pp. 65-76, June 1998.
[12] J. Dowling, V. Cahill. "Dynamic Software Evolution and
The K-Component Model". Technical report, Trinity College
Dublin, TCD-CS-2001-51. December 2001. Presented in the
Workshop on Software Evolution, OOPSLA 2001.
[13] F. Plasil, D. Balek, R. Janecek. "DCUP: Dynamic Compo-
nent Updating in Java/CORBA Environment". Tech. Report
No. 97/10, Dep. of SW Engineering, Charles University,
Prague, 1997.
[14] T. Elrad, O. Aldawud, A. Bader. "Aspect-Oriented Modeling:
Bridging the Gap between Implementation and Design". Ge-
nerative Programming and Component Engineering, ACM
SIGPLAN/SIGSOFT Conference, GPCE, Pittsburgh, USA,
October 2002.
[15] JavaBeans Architecture, Sun Microsystems.
http://java.sun.com/docs/books/tutorial/javabeans/
[16] A. Ketfi, N. Belkhatir and P.Y. Cunin, "Dynamic updating of
component-based applications: SERP'02", June 2002, Las
Vegas, Nevada, USA.
[17] Open Services Gateway Initiative (OSGi),
http://www.osgi.org
[18] A. Ketfi, H. Cervantes, R. Hall, D. Donsez, "Composants
adaptables au dessus d'OSGi", Journées Systèmes à Compo-
sants Adaptables et extensibles Octobre 2002, Grenoble,
France.
[19] The Fractal Project http://fractal.objectweb.org/

Dynamic Component Deployment and (Re) Configuration Using a Unified Framework

More Related Content

What's hot

Viewers also liked

Similar to Dynamic Component Deployment and (Re) Configuration Using a Unified Framework

More from Madjid KETFI

Recently uploaded

Dynamic Component Deployment and (Re) Configuration Using a Unified Framework