Cloud computing enables an economic model for virtual resources provisioning based on Internet protocols. For this paradigm, service oriented Architecture (SOA) is a pillar block to build applications. For service-based applications in the cloud, management becomes a challenging task since it involves an increasing number of layers and a huge number of parameters to take into account. In this paper, we propose a framework that generates self-managed and scalable micro-containers. These micro-containers are enhanced with the resiliency of cellular organisms assuring the fault, configuration, accounting, performance and security constraints (FCAPS) described for each service. The proposed intelligent managed micro-container (IMMC) has a self-monitoring service that allows it to take decisions to enhance its scalability based on migration and replication transactions. These transactions are performed using a Mobility service offered by our IMMC. The primary evaluation that we conducted using our framework are encouraging. Index Terms—Cloud Computing; Self-Management; FCAPS; Monitoring; Mobility; Service Containers;

1. Self-Managed Micro-Containers for Service-Based
Applications in the Cloud
Mohamed Mohamed, Djamel Bela¨ıd and Samir Tata
Institut Mines-Telecom, Telecom SudParis, UMR CNRS Samovar
Evry, France
Email: {Mohamed.Mohamed, Djamel.Belaid, Samir.Tata}@telecom-sudparis.eu
Abstract—Cloud computing enables an economic model for
virtual resources provisioning based on Internet protocols. For
this paradigm, service oriented Architecture (SOA) is a pillar
block to build applications. For service-based applications in the
cloud, management becomes a challenging task since it involves
an increasing number of layers and a huge number of parameters
to take into account. In this paper, we propose a framework
that generates self-managed and scalable micro-containers. These
micro-containers are enhanced with the resiliency of cellular
organisms assuring the fault, configuration, accounting, perfor-
mance and security constraints (FCAPS) described for each ser-
vice. The proposed intelligent managed micro-container (IMMC)
has a self-monitoring service that allows it to take decisions
to enhance its scalability based on migration and replication
transactions. These transactions are performed using a Mobility
service offered by our IMMC. The primary evaluation that we
conducted using our framework are encouraging.
Index Terms—Cloud Computing; Self-Management; FCAPS;
Monitoring; Mobility; Service Containers;
I. INTRODUCTION
Cloud Computing is a recent trend in information technol-
ogy, it refers to a model for enabling ubiquitous, convenient,
on demand network access to a shared pool of configurable
computing resources (e.g., networks, servers, storage, applica-
tions and services) that can be rapidly provisioned and released
with minimal effort or service provider interaction [1]. In this
paradigm, there are three well discussed layers of services
known as ”IaaS” for Infrastructure as a Service, ”PaaS” for
Platform as a Service and ”SaaS” for Software as a Service.
Other ”XaaS” terms are used nowadays to name different
resources provided as services in the cloud.
Cloud environments can be used to host service-based
applications that follow Service Oriented Architecture (SOA).
SOA is a collection of services which communicate with each
other [2]. Each service must be self-contained (i.e., it can
always provide the same functionality, independently of other
services).
Management of service-based applications in Cloud envi-
ronments is becoming a challenging task. Particularly, fault,
configuration, accounting, performance and security (FCAPS)
management can play an important role to respect the agree-
ment between the service’s consumer and its provider. In
fact, adding FCAPS management can improve the resiliency
of the container specially if we enforce it with a granular
monitoring service. A mobility service can also enhance the
management since it allows the migration of services between
virtual machines or between different platforms.
Many attempts to provide management of service-based
applications in the Cloud exist, but almost all of the proposed
approaches does not offer a self-management solution. In
contrast, they provide interfaces or APIs to configure the
behavior of the container and/or the application from outside.
That could tackle the resiliency of the application specially
if we are situated in an environment with a low bandwidth,
in this case, some decisions are critical and must be as fast
as possible. In our point of view, the fastest way is to take
decisions inside the container itself.
In this paper, we propose an Intelligent Managed Micro-
Container (IMMC) that provides FCAPS management. The
IMMC has a high resiliency since it implements the cellular
transactions (i.e. replication, reconfiguration, recombination
and repairing). We propose a framework that adds monitoring
facilities to services and encapsulates them in IMMCs with
high scalability and mobility. Using its monitoring service,
the IMMC has the ability to dynamically and transparently
face the changes in its environment by triggering migration
mechanisms or by changing any of the strategies used for the
FCAPS management.
The rest of this paper is organized as follow: Section II
presents a background for our work. Section III presents our
framework and gives a detailed description of the anatomy
of our Intelligent Managed Micro Container (IMMC). In Sec-
tion IV-A, we provide some details of the implementation of
our framework followed by some primary evaluation showing
the feasibility of our approach in Section IV-B. Finally, in
Section VI, we conclude the paper and present our future work.
II. BACKGROUND
In this section, we will present the different concepts that
inspired our approach. We will start with a description of
Distributed Intelligent Managed Element (DIME) [3] that
provide FCAPS management for distributed systems with the
resiliency of cellular organisms. Then, we will introduce the
concept of micro-containers that we use to deploy services in
the Cloud.
2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
978-0-7695-5002-2/13 $26.00 © 2013 IEEE
DOI 10.1109/WETICE.2013.59
153
2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
978-0-7695-5002-2/13 $26.00 © 2013 IEEE
DOI 10.1109/WETICE.2013.59
138
2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
978-0-7695-5002-2/13 $26.00 © 2013 IEEE
DOI 10.1109/WETICE.2013.59
140
2013 Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
978-0-7695-5002-2/13 $26.00 © 2013 IEEE
DOI 10.1109/WETICE.2013.59
140

2. A. Distributed Intelligent Managed Element and Cellular or-
ganisms
Cellular organisms have the capability to replicate, repair,
recombine and reconfigure themselves. These capabilities give
them a high resiliency supported by DNA (Deoxyribonucleic
acid), genes and chromosomes. DNA allows a cell to build
itself, repair itself and interact with the outside. It controls the
creation of different kinds of molecule or protein using Gene,
which is a piece of DNA containing all the information needed
to ”build” specific biological structure [3].
Rao [3] concludes that the cell architecture can perform
a specific purpose using a stable sequence of patterns, it uses
parallel management to accomplish the global system purpose,
it controls the execution with a signaling mechanism and, it
allows a real-time monitoring and controlling of the execution
of genetic transactions.
Rao was inspired by the behavior of cells to define a new
class of distributed system based on Distributed Intelligent
Managed Element (DIME), different of the Von Neumann
based distributed systems [4]. The DIME (Figure 1) brings
to distributed systems the resiliency of cellular organisms. It
implements the different transactions of cellular organisms that
offer FCAPS management functionalities.
Figure 1. DIME anatomy (Figure from [5])
DIME incorporates FCAPS management using a signaling
overlay and allows the dynamic control of a set of distributed
computing elements in a network. Each DIME is a Turing
Machine modified by endowing it with self management
and signaling capabilities to collaborate with similar nodes
in a network. A DIME can execute a managed computing
process with FCAPS management. It exploits the multi-thread
capability to separate management threads and computing
threads and uses a parallel signaling network that allows the
management of a network of DIMEs. A Managed Intelligent
Computing Element (MICE) performs what is feasible within
a Turing machine. The DIME FCAPS management provides
a higher logical type of the Turing machine which describes
and controls what is feasible with the MICE. A DIME or-
chestration template, called the regulatory gene, contains all
the information required to instantiate a DIME with FCAPS
management components. It also contains the MICE and the
signaling framework to communicate with external world. The
DIME has a Local Manager (DLM) that sets up the other
DIME components. Upon a request to instantiate a DIME, the
DLM sets up three independent threads to provide Signaling
Manager (SM) in charge of signaling channel, MICE Manager
(MM) and FCAPS Manager (FM). DIME network supports the
genetic transactions of replication, repair, recombination and
rearrangement. The detailed description of the DIME can be
found in [3] and [5].
B. Service Micro Container
In [6] we introduced a scalable and platform independent
micro-container that enables services deployment and execu-
tion in the Cloud. For optimality and performance constraints,
features of our micro-container are as minimal as possible.
The basic modules of the micro-container ensure its mini-
mal main process (i.e. service hosting, interaction with other
micro-containers, etc.). A deployment framework contains a
processing module to ensure minimal micro-containers gen-
eration. Also, it contains a set of generic elements for the
submission and treatment of non functional features to be
included in the micro-container (HTTP/RMI or other generic
Communication modules, service administration tools, service
billing, etc.). The deployment framework receives the service
archive containing a deployment descriptor. This descriptor
is used to generate a corresponding micro-container within
the service to deploy. The evaluation of the micro-container
proved its efficiency and scalability. The detailed description
of the micro-container can be found in [6] and [7].
In this paper, we propose a new self-managed micro-
container, adopting a similar approach as DIME to offer
FCAPS management facilities and enhanced with the re-
siliency of cellular organisms.
III. INTELLIGENT MANAGED MICRO CONTAINER
In this section, we will describe the overall architecture
of our approach, composed of a deployment framework that
enables micro-containers generation and deployment in the
Cloud with FCAPS management, monitoring and mobility.
First, we will describe the details of the deployment framework
and its modules. Then, we will describe the anatomy of the
generated Intelligent Managed Micro-Container.
A. Overall architecture
The Deployment Framework, shown in Figure 2, is re-
sponsible of generating specific IMMCs for services. The
Processing Module receives the archive of the service and its
associated deployment and management descriptors. It applies
the needed monitoring transformations to add monitoring
facilities to the service [8]. Then, it adds FCAPS management
functionalities following the management descriptor. Besides,
it adds the mobility service and the needed communication
module. Finally, it generates an IMMC that could be deployed
and instantiated in the Cloud. The deployment framework is
modular. We can plug new modules to respond to any new
requirement.
154139141141

3. Figure 2. Deployment Framework Architecture
B. IMMC Anatomy
The IMMC is composed of different modules as shown
in Figure 3. The Communication Module is responsible of
the interactions with the outside (i.e. sending and receiving
messages). The Processing Module performs packing and
unpacking of the incoming and outgoing messages to the
specific message formats, it is responsible also for address-
ing the messages to the right component inside the IMMC.
Monitoring, Mobility, and FCAPS management are performed
using the appropriate Module (respectively detailed in III-C,
III-D, and III-E).
Figure 3. Intelligent Managed Micro Container Anatomy
Furthermore, the IMMC contains a composite offering
the services of the original component with new services
of monitoring. These services are offered by a dynamically
generated byte-code. This byte-code is generated by the Mon-
itoring Module of the Deployment Framework. Moreover,
that composite offers new services provided by GenericProxy
component, this latter is an implementation of a general
purpose interface GenericProxy that provides four generic
methods described in Figure 4.
public interface GenericProxy {
Property[] getProperties();
Object getPropertyValue(String propertyName);
void setPropertyValue(String propertyName,
Object propertyValue);
Object invoke(String methodName, Object[] params);
}
Figure 4. Description of the GenericProxy interface.
Each implementation of this interface is associated with a
component for which the first method getProperties() returns
the list of the properties of the component, the getProperty-
Value() returns the value of a property, the setPropertyValue()
changes the value of a property and the invoke() method
invokes a given method on the associated component and
returns the result.
C. Monitoring Service
Our deployment framework allows to add monitoring fa-
cilities to services even if they where not designed with
monitoring facilities. To do so, we have a monitoring module
that applies some predefined transformations on components
to render them monitorable. These transformations allow
adding different types of monitoring (i.e. by polling and by
subscription) by encapsulating the monitored component in
a composite with an implementation of the GenericProxy
interface (described in Figure 4) and a dynamically generated
Notification Bytecode. This composite offers the original ser-
vices of the component and new services of monitoring. The
transformation is illustrated in the Figure 5.
The Notification Service component, shown in Figure 5, is
responsible of receiving subscriptions from interested compo-
nents inside the IMMC or from clients outside the IMMC. This
component is in charge of sending notifications of the status
155140142142

4. Figure 5. Monitoring Transformation
of monitored properties, for the interested clients, periodically
if the monitoring mode is on interval or whenever a change
occurred if the monitoring mode is on change. The monitoring
on change contains different types of monitoring:
∙ Property Changed Monitoring (PCM): the notification
service has to send notifications to interested subscribers
whenever a monitored property changed.
∙ Method Call Monitoring (MCM): the notification service
has to send notifications to interested subscribers when-
ever one of the service’s methods is invoked.
∙ Execution Time Monitoring (ETM): the notification ser-
vice has to send notifications to interested subscribers
about the execution time whenever a service invocation
occurred.
The different details of the monitoring module and trans-
formations can be found in [8].
D. Mobility
In [9], we proposed an extension for our micro-container
that enhances it with mobility. To do that, we added a new
module of Mobility, and we needed to add a Receiver in each
virtual machine (VM) responsible of receiving and running
migrating micro-containers. The mobility module receives
orders to migrate from a VM to another from an administration
part. At the reception of migration order, this module serializes
the micro-container and establishes a connection with the
Receiver in the virtual machine in which it will migrate. The
Receiver receives the serialized micro-container, deserializes
it and restarts it in the new environment. In this paper, we
propose that the Mobility module can receive migration or
replication orders from the outside or from modules inside
the IMMC. In this stage of our work, we supposed that the
choice of the VM, that the IMMC will migrate to, is out of
our scope.
E. FCAPS Management
The FCAPS management is performed using a collection
of threads. Each thread has a specific task. The Fault, Con-
figuration, Accounting, Performance and Security functional-
ities are encapsulated in the IMMC. Following the descrip-
tion contained in the Management Descriptor some of these
functionalities can be turned on or off. During runtime, the
IMMC can receive orders to turn on or off any one of these
functionalities. Each FCAPS thread communicates with the
outside to receive new orders (e.g. to change its behavior),
with the inside to manage itself and its contained compo-
nent. The communication inside the IMMC is performed by
polling the encapsulated component via the GenericProxy or
by receiving notifications from the Notification service. Based
on the retrieved information (by polling or by subscription),
FCAPS manager can take decisions using the rules that where
described in the management descriptor.
1) Fault: The Fault module is used to ensure the continuity
of the service in a local view or in a global view (i.e. when
used in a composition of services). Our framework uses a
dynamically generated and added Adapter [10] to invoke the
service of the contained component. This Adapter handles
the clients queries and retransmits them to the service. If
the service is not responding within a timeout, this Adapter
informs the Fault module that the service needs to be repaired.
The Fault module runs a new instance of the service and the
Adapter can invoke the service and send back the response. In
the case of a composition, each IMMC can detect that another
IMMC is not reachable, it can send a request to maintain
the composition by replacing the unreachable IMMC by a
new one. More details of the Adapter service that we used
to enforce fault tolerance can be found in [10].
2) Configuration: The configuration can be made in two
ways. The first one, is to configure a property by changing
its value and the second way is to change the implemen-
tation of the component completely. The configuration of a
property can be made by calling its setter method. However,
the Configuration module does not know a priori the type
of the component. To complete the configuration of any
component from only the name and type of a property, the
Configuration module uses the method setPropertyValue() of
the GenericProxy to change the value of the property. To
configure an IMMC by changing the implementation of the
component completely, the configuration module receives the
new component implementation and loads it instead of the
existing one.
3) Accounting: This module applies a specific strategy
of accounting. Accounting strategies could be based on re-
sources consumption or the time of a transaction or even the
number of invocations of services. This information could
be retrieved from the Notification module. To this end, the
Accounting module can subscribe to the Notification module
to receive PCM (Property Changed Monitoring) notifications if
the accounting strategy is based on resources consumption, or
MCM (Method Call Monitoring) notifications if it is based on
invocation number or even ETM (Execution Time Monitoring)
notifications if it is based on time usage of the resources.
4) Performance: The Performance module is needed to
ensure that the IMMC keeps a good QoS during its life-
cycle. This module subscribes to the Notification service, to
receive ETM notifications. It compares the execution time of
an encapsulated service against predefined thresholds, it can
use its internal rules to decide whether it is needed to replicate
the IMMC or to migrate it. If it is the case, this module sends
can send a migration order to the Mobility module. It can also
perform self-replication by sending a replication order with the
156141143143

5. VM address as destination parameter to the Mobility module.
In this case the mobility module detects that the order is a
replication order, so it re-instantiate a new IMMC with the
same component and running services as the replicated one
without shutting down the original IMMC.
5) Security: In this paper, we suppose that the security
module is in an early stage. It is represented as an Adapter
that handles clients queries and verifies whether the received
orders from the outside are authenticated or not [10]. When
this module is activated, all communication of the IMMC with
the outside passes through this Adapter. This module can be
improved in future work.
To prove the feasibility of our work and its efficiency,
in the next section, we will detail some aspects of our
implementation of the different modules of the deployment
framework and the IMMC, and we will describe some primary
results of the experimentation.
IV. IMPLEMENTATION AND EXPERIMENTATION
In this section we will describe some aspects of our imple-
mentation, then we will give some results of our evaluation
proving its feasibility and efficiency.
A. Implementation
The implementation process took place in different phases.
We have first developed a minimal Java deployment frame-
work, which allows developers to deploy a Java service on
a hard-coded micro-container that could be deployed in the
cloud. To enhance the performance of the platform and facil-
itates updates and future changes, the deployment framework
is made modular to allow us to plug or unplug modules.
The generation process is based primarily on the parsing of
deployment and management descriptors.
The next phase was implementing a prototype of the mon-
itoring framework as services that offer the transformation
mechanisms to the components.
The Notification byte-code is generated dynamically. For
this required byte-code level manipulation we used the Java
reflection API [11] and the open source software JAVA
programming ASSISTant (Javassist) library [12]. The Java
reflection API provides classes and interfaces for obtaining
reflective information about classes and objects. Reflection
allows programmatic access to information about the fields,
methods and constructors of loaded classes, and the use of
reflected fields, methods, and constructors to operate on their
underlying counterparts on objects. Javassist is a class library
for editing Java byte-codes; it enables Java programs to define
a new class and to modify a class file when the Java Virtual
Machine (JVM) loads it.
For the Mobility service, we used the Java Serializable API
for serialization and deserialization of IMMCs. The Receiver
module is a Java based module that uses HTTP to download
the serialized IMMC and to restart it in the destination VM.
Finally, we implemented Java classes for the FCAPS man-
agement. Each class is a thread that uses a list of rules
extracted from the management descriptor to ensure a specific
task. The Fault, Accounting and Performance tasks are clients
of the monitoring service. They have the ability to consume
notifications to take specific decisions.
B. Experimentation
To test the efficiency of our approach, we started to evaluate
its different modules. The evaluation environment is a Cloud
Platform that contains 380 cores Intel Xeon Nehalem, 1.17 TB
of RAM and 100 TB as shared storage. All these resources are
managed using OpenNebula IaaS manager [13]. The tests se-
ries were done separately to test the overhead of the concerned
module in the memory consumption of the IMMC and to test
the execution time (notification latency for monitoring and
response time for mobility). The first evaluation was described
in [7] and proves the scalability of our container compared
with classical containers. The results proved that our approach
reduces the memory consumption and allows us to be in-line
with the scalability of the Cloud. Further, we evaluated the
monitoring module to see its overhead on the IMMC and its
notification latency time, more scenarios are described with
details in [14]. The results are encouraging and show that the
Monitoring module does not present a big overhead on the
memory consumption of the overall IMMC. Results proved
also the flexibility of the monitoring solution in architectural
point of view.
Finally, we tested the overhead of the Mobility module and
its response time. The results are well detailed in [9]. These
results show that the overhead of the Mobility module are
acceptable, and that the response time of our mobile IMMC are
interesting compared with other approaches. At this time, we
are working on pushing farther our experimentation to cover
the evaluation of all the platform and its different modules.
Particularly, we are experimenting the FCAPS module and
improving its integration in the overall architecture.
V. RELATED WORK
In this section, we present some containers of service-based
applications in the Cloud, explaining the advantage of our
approach compared to them.
Containers are defined by J. Doudoux [15] as mechanisms
for managing the life cycle of components that run in them.
The container hosts and provides services to support the
applications during their execution. To deploy an application
in a container, one must mainly provide all its components and
a deployment descriptor that specifies the container configu-
rations to host the application. We studied many containers
used in Cloud environments to explore their point of view on
management. Tomcat [16], CXF [17] and Axis[18] which are
open sources projects from Apache, offer management for the
applications but they do not address self-management. In these
cases, the manageability is determined from the configuration
of the container, but this latter can not manage itself by making
decisions.
In [19], authors proposed a similar approach to our micro-
container which is the Elastic Application Container (EAC)
that represents a virtual resource unit for application hosting.
157142144144

6. An EAC needs an elastic application server (EAS) to host
it. The EAS controls the life cycle of an EAC. A Cloud
Controller take decisions on scaling the application according
to its resource usage. This approach provides monitoring and
migration functionalities. Management is performed basically
by the EAS which is responsible of managing the EACs. The
advantage of our approach is that the IMMC is able of taking
its own decisions of management. Moreover, in our approach
we propose to add monitoring facilities to services even if they
where not designed to be monitored.
Authors of [20] presented Web Service Container Reference
Architecture (WSCRA) as a proposal to respond to the need
for standardized management and monitoring functions in web
service containers. It supports different factors to determine the
efficiency of a web service. In this proposal, the management
does not include mobility aspects. Moreover, it does not allow
the monitoring of natively not monitorable component. This
architecture allows the management of application but does
not allow the self-management of the container itself.
In [21], authors proposed a self-management approach
for service developers of PaaS. This approach is based on
self-management workflow. It contains basically an uploader
module that helps developers to upload their services. An
analyzer is responsible of analyzing the services to recognize
the needed configurations and dependencies. Moreover, there
is a deployer module responsible of selecting and configuring
the needed nodes from the platform. The framework contains
also a Service Manager that offers management functionalities
including monitoring and control. The Service Manager pro-
vides an interface for developers to adjust running instances
of their services.
Almost all of the presented approaches does not offer self-
management that covers the container itself and the contained
application. In our approach, using IMMCs we have the ability
to monitor the service-based application and the container
itself, and based on this monitoring mechanism, IMMCs
are able to trigger self-management actions. The solution
that we propose covers different aspects providing FCAPS
management enhanced with mobility and monitoring capa-
bilities. Moreover, IMMC implements the cellular organism
transaction to improve its resiliency.
VI. CONCLUSIONS AND FUTURE WORK
For service-based applications in the cloud, management
is a challenging task. It involves an increasing number of
layers and parameters to take into account. In this paper, we
proposed a framework that generates self-managed and scal-
able micro-containers. These micro-containers are enhanced
with the resiliency of cellular organisms and assuring the
Fault, Configuration, Accounting, Performance and Security
constraints (FCAPS) described for each service. The proposed
Intelligent Managed Micro Container has a self-monitoring
service that allows the FCAPS manager to take decisions in
order to enhance its QoS (e.g. scale-up, scale-down, migration,
replication, etc.). We explained some aspects of the implemen-
tation of our proposal and we performed some preliminary
evaluations. The results that we got are encouraging to chain
up with future work. We aim to improve the implementation
of the different modules of the FCAPS management providing
different strategies for each module. To this aim, we will
study the existing standards used in each service (i.e. FCAPS
services). Furthermore, we will add a new module that take
decisions to optimize the mobility system choosing the best
VM that fits IMMCs requirements. This module needs to take
into account different strategies to consume monitoring data.
REFERENCES
[1] NIST, “Final Version of NIST Cloud Computing Definition Published.”
http://www.nist.gov/itl/csd/cloud-102511.cfm, 2011.
[2] D. V. Thanh and I. Jorstad, “A service-oriented architecture framework
for mobile services.” in proceeding of Telecommunication 2005, july
2005, pp. 65–70.
[3] R. Mikkilineni, “Designing a New Class of Distributed Systems,”
Springer, 2011.
[4] J. V. Neumann, “Theory of Self-Reproducing Automata,” Edited and
compiled by A. W. Burks, 1966.
[5] G. Morana and R. Mikkilineni, “Scaling and Self-repair of Linux
Based Services Using a Novel Distributed Computing Model Exploiting
Parallelism,” in Proceedings of WETICE, 2011, pp. 98–103.
[6] S. Yangui, M. Mohamed, S. Tata, and S. Moalla, “Scalable Service
Containers.” in Proceedings of the third IEEE International Conference
on Cloud Computing Technology and Science, CloudCom, 2011, pp.
348–356.
[7] M. Mohamed, S. Yangui, S. Moalla, and S. Tata, “Web Service Micro-
Container for Service-based Applications in Cloud Environments,” in
Proceedings of WETICE, 2011, pp. 61–66.
[8] M. Mohamed, D. Bela¨ıd, and S. Tata, “How to Provide Monitoring
Facilities to Services When They Are Deployed in the Cloud?” in
Proceedings of the International Conference on Cloud Computing and
Services Science, CLOSER, 2012, pp. 258–263.
[9] A. Omezzine, S. Yangui, N. Bellamine, and S. Tata, “Mobile Service
Micro-containers for Cloud Environments,” in Proceedings of WETICE,
2012, pp. 154–160.
[10] I. B. Lahmar, D. Bela¨ıd, and H. Mukhtar, “A Pattern-based Adaptation
for Abstract Applications in Pervasive Environments,” in International
Journal on Advances in Software, vol. 4, no. 3 & 4, pp. 367–377, 2011.
[11] “Java 2 Platform API Specification,” http://download-
llnw.oracle.com/javase/1.4.2/docs/api/java/lang/reflect/package-
summary.html., 2010.
[12] “JAVA programming Assistant.” http://www.csg.is.titech.ac.jp/ chiba/jav
assist, 2010.
[13] “OpenNebula.” http://opennebula.org, 2013.
[14] M. Mohamed, D. Bela¨ıd, and S. Tata, “Adding Monitoring and Recon-
figuration Facilities for Service-based Applications in the Cloud,” will
appear in the IEEE International Conference on Advanced Information
Networking and Applications (AINA), 2013.
[15] J. Doudoux, “J2EE / Java EE,” http://www.jmdoudoux.fr/java/dej/chap-
j2ee-javaee.htm, 2012.
[16] “Apache Tomcat Architecture.” http://tomcat.apache.org/tomcat-6.0-
doc/architecture/overview.html, November 2011.
[17] N. Balani and R. Hathi, “Apache CXF Web Service Development,” 2009.
[18] S. Perera, C. Herath, J. Ekanayake, E. Chinthaka, A. Ranabahu, D. Jayas-
inghe, S. Weerawarana, and G. Daniels, “Axis2, Middleware for Next
Generation Web Services.” in Proceedings of the IEEE International
Conference on Web Services, ICWS ’06, sept. 2006, pp. 833–840.
[19] S. He, L. Guo, Y. Guo, C. Wu, M. Ghanem, and R. Han, “Elastic
Application Container: A Lightweight Approach for Cloud Resource
Provisioning,” in Proceeding of the IEEE International Conference
on Advanced Information Networking and Applications (AINA), march
2012, pp. 15–22.
[20] A. Dhesiaseelan and A. Ragunathan, “Web services container reference
architecture (WSCRA).” in Proceedings of the IEEE International
Conference on Web Services, ICWS ’04, july 2004, pp. 806–807.
[21] H. Wei, J. Shao, B. Liu, H. Liu, Q. Wang, and H. Mei, “A self-
management approach for service developers of PaaS,” in IEEE Inter-
national Symposium on Service Oriented System Engineering (SOSE),
dec. 2011, pp. 85–92.
158143145145