![](bg2.png)
is seen as the post development activities that make
the software usable. It covers the description of the
application to deploy, the description of the physical
infrastructure, the description of the deployment
strategies, the planning activities, the execution plan
and the re-planning activities. The deployment
activity can be initiated by either the software
producer or the client. In the Push model, the
producer decides to send the application to the
clients. Hence, the producer will either send a
notification of the deployment activity, giving the
choice to the client to accept or to reject the activity
or he will inform the client in advance to avoid
asking the client’s permission during the
deployment. In the Pull model, the client (executing
platform) decides to download a specific application.
This model ensures the client a greater independence
and a greater security for the applications to install.
The arrival of distributed component-based
systems has highlighted the problems of deploying
large-scale software composed by multiple
components and to be distributed to multiple sites.
This type of deployment is hardly possible without
automated support.
The deployment issue deals with aspects as
diverse as satisfying software and hardware
constraints of the components with regard to the
resources of the machines that support them, the
resolution of inter-component dependency, the
installation and “instantiation” of components via
the middleware and the container, the
interconnection of components, their activation and
the management of dynamic updates.
For all these reasons, we think that it is necessary
to have a generic deployment framework which has
to distribute correctly application based-components,
whaterver their implementation might be. Thus the
challenge is to develop a generic framework
encompassing a specific approach and supporting
the whole deployment process.
In this paper (Dibo and Belkhatir, 2010), we
presents this approach based on models and model
transformations. The following paper is a
continuation of previous work. This paper is focused
on the modelling of deployment strategies and
organized as follow: part 2 reviews related works;
our conceptual framework is described briefly in
part 3; part 4 presents strategy modelling. Part 5
describes the engine core of UDeploy Framework
(creation, personalization and execution of the
deployment plan) and; finally in part 6, we present
the perspective and conclusion of this work.
2 ANALYSIS OF STATE OF ART
We identified three types of deployment systems:
1) Those developed by the industry in an ad hoc
manner and integrated into middleware
environment;
2) Those projected by the OMG (industry) based on
more generic models and;
3) The more formal systems projected by the
academy.
Next, we will illustrate these systems.
2.1 Deployment in Middleware
The pros of deployment in application based-
component like EJB (Dochez, 2009), CCM (OMG,
2006a) and .Net (Troelsen, 2008a, Troelsen, 2008b)
relay in the fact that the technologies are effective
thus answers specific needs. The cons are that the
abstraction level is very low therefore it is necessary
to make each activity manually. In such contexts and
with these facts, it is easy to deduce that there is a
real need to standardize the deployment of
distributed applications. The middleware does not
support the description of the domain. They contain
less semantics to describe applications; for example,
the needs of an application may be a specific version
of software, and a memory size greater than 10 GB.
Since none of these constraints will be checked
during installation, this corresponds to a single copy
component assembly. The deployment descriptor
expresses the same mechanism for each middleware
but described them in different ways.
2.2 OMG
The industry felt the necessity to join their efforts.
They anticipated an approach which capitalizes on
their experiences in deployment (OMG’s approach).
This specification has inspired many academics.
OMG’s Deployment and Configuration (D&C)
(OMG, 2006b) specification is based on the use of
models, metamodels and their transformation. This
specification standardizes many aspects of
deployment for component-based distributed
systems, including component assembly, component
packaging, package configuration, and target domain
resource management. These aspects are handled via
a data model and a runtime model. The data model
can be used to define/generate XML schemas for
storing and interchanging metadata that describes
component assemblies and their configuration and
deployment characteristics. The runtime model
MODEL-DRIVEN DEPLOYMENT OF DISTRIBUTED COMPONENTS-BASED SOFTWARE
103