Journal of Cloud Computing

Advances, Systems and Applications

Journal of Cloud Computing Cover Image
Open Access

Experiences in building a mOSAIC of clouds

  • Dana Petcu1Email author,
  • Beniamino Di Martino2,
  • Salvatore Venticinque2,
  • Massimiliano Rak2,
  • Tamás Máhr3,
  • Gorka Esnal Lopez4,
  • Fabrice Brito5,
  • Roberto Cossu6,
  • Miha Stopar7,
  • Svatopluk Šperka8 and
  • Vlado Stankovski9
Journal of Cloud Computing: Advances, Systems and ApplicationsAdvances, Systems and Applications20132:12

DOI: 10.1186/2192-113X-2-12

Received: 12 January 2013

Accepted: 7 May 2013

Published: 24 May 2013


The diversity of Cloud computing services is challenging the application developers as various and non-standard interfaces are provided for these services. Few middleware solutions were developed until now to support the design, deployment and execution of service-independent applications as well as the management of resources from multiple Clouds. This paper focuses on one of these advanced middleware solutions, called mOSAIC. Written after the completion of its development, this paper presents an integrated overview of the mOSAIC approach and the use of its various software prototypes in a Cloud application development process. We are starting from the design concepts and arrive to various applications, as well as to the position versus similar initiatives.


The story of mOSAIC (Open-source API and Platform for Multiple Clouds) starts in Spring 2009 when its idea emerged. The main challenges for Cloud Computing identified to that moment, as shown in [1, 2], were application and data interoperability and portability, governance and management, metering and monitoring, as well as security. In the meanwhile some partial solutions addressing these challenges have proposed, however, according to a recent report [3], these challenges still exist. The key goal of mOSAIC is to offer a solution for application portability and interoperability across multiple Clouds. However, the complete mOSAIC’ solution addresses partially also the other challenges, management, governance, and security, as will be revealed in what follows.

The mOSAIC’ solution is a result of a multi-national team effort as part of a grant agreement with the European Commission in the frame of FP7-ICT programme [4] (details on the project web site [5]). The implementation has started in September 2010 and the final software was released in March 2013. The promises made in the early stage of development were described in the position paper ’Building a mOSAIC of Clouds’ [6]:
  1. 1.

    Design a language- and vendor-agnostic application programming interface for using multi-Cloud resources and Cloud usage patterns.

  2. 2.

    Design a generic agent skeleton for representing various stakeholders, e.g. Cloud vendors and their resources, Cloud users of various types, and a collection of modules that can be used to adapt agent skeleton to support needed functionalities.

  3. 3.

    Design user-centric service level agreements, a Cloud ontology, and mechanisms for dynamic negotiation of resources based on multi-agent technologies and semantic data processing.

  4. 4.

    Build an open-source and portable platform for using Cloud services based on the proposed API and Cloud usage patterns.

  5. 5.

    Build proof-of-concept applications with a special emphasis on data intensive applications.


These scientific and technical goals were related with the time’s lack of (a) common programming model for Cloud-oriented applications, (b) of tools for easy deployment of scalable applications and (multi)-Cloud-based services, (c) of standard representation for Cloud resources, (d) of adequate service level agreements and their dynamic negotiation, (e) of application portability due to different APIs for Cloud services from different providers.

A variety of reports on mOSAIC’s particular software solutions have been presented at recent scientific conferences and in journal papers. The current paper intends to provide an overview of the full and integrated solution with exhaustive references to literature where details can be found. Therefore the main contribution of this paper consists in the high-level description of the mOSAIC’s approach and the answers to the current challenges in the Cloud computing domain by the mOSAIC’s technical solutions.

The paper is organized as follows. The first part is a description of the overall mOSAIC’s approach for solving the current problems of using multiple Clouds. The second part concerns the mOSAIC’s positioning in the landscape of Cloud computing services. The third part is dedicated to a discussion of the possible future developments and improvements.

The mOSAIC’s approach

This section explains in details how the mOSAIC solution matches the key scientific and technical goals that were outlined in the introduction.

APIs and patterns

Several open API are already available (like jclouds, libcloud, OpenStack, most of them develop in parallel with mOSAIC) offering a management layer for the resources of same type from multiple Clouds (based on a common denominator of their APIs). However the services are restricted to a specific language (like Java), a specific architectural style (like REST oriented) or specific type of resources (like virtual machines).

Component-based programming

The component model provides a natural abstraction for programming and execution of Cloud applications, since is lightweight and flexible in terms of APIs, according [7]. However, component frameworks that are expected to provide design-time and run-time infrastructures in Clouds are few. A short preliminary analysis of the existing solutions was done for mOSAIC positioning purpose and is reported in [8]. This analysis revealed that a proof-of-concept implementation of a component framework for Clouds only for Java [9] was developed in parallel with mOSAIC.

The mOSAIC’s API offers a simple way to develop components which run on the top of its platform. The programming model of mOSAIC is based on using loosely coupled components. A mOSAIC component represents an entity controlled by the user: the entity is configurable, exhibits a well defined behavior, implements application dependent functionalities and exposes them to other components. When an instance of a mOSAIC component runs in a Cloud environment, it consumes hardware or software resources, e.g. state-full resources hosted by Cloud service provider and accessible through dedicated APIs. The communication among moSAIC components takes place through message queues, e.g. using the AMQP [10] protocol or the Amazon’s SQS [11].

The mOSAIC’s basic component is the Cloudlet (first introduced in [12]). A Cloudlet is an event-driven and stateless component whose functionalities do not depend on the number of its instances at run-time (has a degree of autonomy). The Cloudlets can get automatic support for their life-cycle from the mOSAIC’s platform including initialization, configuration and bindings to the needed hardware and software resources. Moreover, Cloudlets should be able to run in a Cloud environment independently from other components. Furthermore, Cloudlets are started, stopped, replaced, or multiplied at run-time for the application performance improvement. Multiple instances of the same Cloudlet are therefore expected to be supported by an application. Consequently, the elasticity concept, specific for Cloud computing, is applied at the level of application in the mOSAIC approach.

The Cloudlets are able to access Cloud services through Connectors. The concept of Connector is introduced to ensure the independence from the Cloud service interfaces. A Connector is a concrete class that abstract the access to Cloud resources and defines the set of events to which the Cloudlet should react; its behavior is similar to a remote procedure call, and it offers the functionality of the common denominator of a certain type of Cloud service. For example, in the mOSAIC library for Java there is only one Connector for key-value stores.

The Connectors access Cloud services using Drivers. The Drivers are implementing the Cloud services interfaces. They can be interpreted as wrappers of native resource APIs or uniform APIs, like OpenStack. These wrappers are able to send and receive messages from the mOSAIC’s message queues.

The components of a mOSAIC application can be written in several different languages (Java, Python, Erlang, Node.js) and are able to communicate with each other using a component bus (similar to CORBA’s one) and asynchronous communications (as being loosely coupled). In particular, Connectors and Drivers can be written in different languages. However, the Cloudlets that are expressing the behavior of the applications are calling the Connectors – therefore the Connectors are expected to be written in the same language as the Cloudlets (further details are provided in [13]).

A simple example

We assume that a software developer intends to built an application which is able to receive requests from the Web (e.g. an XML file) to perform an analysis of the document (e.g. XML parsing) and to store the results in a Cloud storage.

Such an application will be built easily using a predefined mOSAIC component which manages the HTTP protocol and offers the REST interfaces (the HTTP gateway, HTTPgw, in mOSAIC terms), and a Cloudlet that receives the XML files from the gateway, process them, and store the results in the Cloud storage using a key-value store Connector.

Once the application is developed it is possible to deploy it it and use a Cloud storage service offered by a Cloud Provider (e.g. Amazon S3) or a platform’s internal component (like Riak-based service). The decision which one should be use can be taken at application deploy time (not during the development) and can be even dynamically changed at runtime. Moreover if the application needs to scale-up due to the high number of requests, the developer can just add at runtime new Cloudlet or other component instances to manage the newly incoming requests.

Event-driven programming

mOSAIC’s API was designed to be event-driven. There are few implementations of event-driven approaches in Cloud computing, but the most known are Amazon’s SNS, Microsoft’s Azure, and the open-source Node.js.

The main reasons for such an approach are [14]: avoidance of expensive pooling on Cloud resources; opportunity to deal with an unlimited number of messages; adaptability that is naturally event-driven; rare changes in the state of long-running Cloud applications; integration with Internet of Things.

The event-driven approach has also drawbacks. The application developer needs to write the callbacks and the data cannot be provided with these callbacks due to the access rights. The states of a resource should be well defined to trigger a call to the API by the resource provider. Therefore, a dependence on the provider can be created for the callback. To overcome these problems, mOSAIC has proposed an abstraction layer (Cloudlets and Connectors) that allows the application developer to follow the concepts of event-driven architecture, while the low level components of the platform (Drivers) are treating the cases of demand-driven approach in the connection with the specific Cloud services. An interoperability component of the platform (between the Connectors and Drivers) acts as a proxy between the instances following the two different models of interactions (further details can be found in [15]).


Currently, four pattern categories are used in mOSAIC: (1) programming patterns; (2) platform patterns; (3) service usage patterns; (4) application patterns.

The programming patterns are related to ’component-based’ and ’event-driven’ approaches. The patterns that are supported by the mOSAIC’s platform are ’just-in-time-scalability’ and ’event-based execution’.

The classical Cloud service usage patterns, as introduced in [16], are: end user to Cloud, enterprise to Cloud, Private Cloud, changing of Cloud vendors, Hybrid Cloud and so on. mOSAIC is mainly supporting the ’changing of Cloud vendors’, and partially the ’Hybrid Cloud’.

Basic application patterns that can be used for quick application prototyping in mOSAIC were presented in an early paper [17]. Web, databases or application servers are supported. The proof-of-concept applications developed in the frame of mOSAIC project showed the approach usefulness for scientific applications. Therefore, Cloud related patterns for scientific applications were analyzed in details and are reported in [18].

Cloud agency


The mOSAIC’s Cloud Agency is a service for the deployment and execution of mOSAIC application. It is in charge for provisioning, from different providers, a collection of Cloud resources, which fulfill at best the user’s requirements, to be consumed by mOSAIC applications.

The selection of the Cloud resources to be consumed is nowadays a challenging task for the developer or user of Cloud applications due to different business models associated with resource consumptions as well as due to the variety of features that the Cloud providers are offering. The IaaS commercial provider is interested in proposing a technological solution that is differentiating it from the others providers. This differences have the drawback of locking the customers as no alternative are provided. Also open source technologies for setting up Private Clouds are not compliant with each other. In this context, the Cloud Agency addresses the interoperability problem by proposing an uniform interface for accessing multiple IaaSs.

In the Cloud computing service market there are thousands of options which are different in terms of characteristics of the service, general terms and conditions and service levels that providers ensure. Their current Service Level Agreements (SLAs) use proprietary metrics that make difficult to evaluate properly each offer and to compare different offers among them. Moreover, the customer must trust twice its provider: because the agreed SLA, and because the provider’s proprietary monitoring service. That is why the Cloud Agency aims at advancing the state of art of using the Clouds by providing a decision making support to the user for discovery and decision about the best Cloud solution that satisfies his requirements.

The Cloud customers need to detect under-utilization and overload conditions, and also to take decisions about load balancing and resource reconfiguration. In both the cases it is necessary to dimension the Cloud resource to avoid useless expenses and to not fail to satisfy the service requirements when workloads change dynamically. The Cloud Agency aims at providing a monitoring service that run on IaaS under the control of the customer.

Autonomic optimization of Cloud is widely investigated at provider side, but is not perceived by the customer as its own benefit, because it aims at maximize the provider’s utility in terms of utilization of physical resource business improvement. That is why the Cloud Agency approach is based on autonomic agents, which enforce well defined policies to provide the perceived utility to their owners. The user is able to delegate to the Cloud Agency the necessary checks of SLA fulfillment, the monitoring of resource utilization, and, eventually, necessary re-negotiations.

The preliminary concept of the Cloud Agency architecture is detailed in [19], while the implementation layers to support Cloud applications were presented in [20]. The Cloud Agency is a step forward towards the implementation of the recent vision of Autonomic Cloud (as discussed in [21]).


Implemented as a multi-agent system, the Cloud Agency is based on asynchronous messaging as other mOSAIC software prototypes. The message-passing architecture was exposed in [22].

The Cloud Agency can act as a standalone and independent component or as an integrated platform component. In the first case it can be used to book Cloud resources and eventually monitor and reconfigure them (scale up, scale out, change providers), without the need of other mOSAIC components. Several user-friendly and programmatic interfaces can be used for interaction (a list and their descriptions can be found in [23]). In the second case, the Cloud Agency offers services to the core components of the platform (e.g. in the case of reconfiguration at application level). A RESTful interface can be used for the interaction [24]. It is compliant with OCCI.

While multi-agent based Cloud management architectures or frameworks were proposed before mOSAIC (like in the proposal exposed in [25]), we consider that mOSAIC’s Cloud Agency is the most complete implementation of the concepts that has been tested in the context of complex scientific and commercial applications.

Resource management: provisioning and monitoring

The Cloud Agency provisions resources which should be consumed by the applications. Through its interfaces, detailed in [26], the Agency Client can start a Call-for-Proposal, based on a component description of the application and the policy specifications (a HTTP POST message embedding an SLA is sent to the Agency). The availability of a result triggers an event (using a HTTP POST message), after which the Cloud Agency Client is able to accept or reject the proposal.

The brokering of the best collection of Cloud resources has been modeled as a multi-criteria optimization problem, with hard and soft constraints that can be included by the user in the Call-for-Proposals, as it is described in [27]. With regards to a computing service, such constraints can be required for service properties, like CPU architecture, minimum amount of memory, CPU speed, I/O speed or number of cores. The level of the service availability can be set over a threshold. Multiple objectives can be defined by the user to choose the cheaper proposal and/or to optimize the performance of I/O-bound or memory-bound application.

Beyond the provisioning role, the Cloud Agency has also other resource management functionalities, like monitoring, that is related to the parameters specified in SLAs (monitorinf the quality of service). Details about this role implementation can be found in [28, 29].

Vendor modules

A Cloud provider offer is represented in a brokering or negotiation process by a Vendor Module; details about the module architecture and interaction with the Cloud Agency were exposed in [30]. A simple template was designed to offer a mechanism for new Cloud providers to connected their services to the Cloud Agency; the template was first documented in [31].

Until now mOSAIC’ software repository includes Vendor Modules for more than ten Public Clouds. Among these mOSAIC supports well known providers like Amazon, Rackspace [32], and GoGrid [33], as well as European Cloud providers including Flexiant [34] (UK), CloudSigma [35] (Switzerland), NIIFI [36] (Hungary), Arctur [37] and Hostko [38] (Slovenia), latest two using VMware’s vCloud [39], respectively OnApp [40]. Moreover, Private Clouds built by using open-source technologies, like Eucalyptus [41], OpenNebula [42], CloudStack [43], or OpenStack [44], can be also represented in the brokering process by their corresponding Vendor Modules and managed by the Cloud Agency’s uniform interface.

User-centric SLA management and dynamic negotiation

SLA management

Service Level Agreements (SLAs) are the basics of a common language for agreements between the Cloud clients and the Cloud service providers. Due to the self-service approach, typical for Cloud computing, a SLA for a Cloud service has from user perspective a relevant role in defining what the service effectively grants. mOSAIC supports SLA both at brokering level and at API level. In the first case, SLAs are used for the brokering mechanisms through the Cloud Agency and through a SLA client with respect to provider’s offer. In this second case, mOSAIC acts as an SLA provider: the offered services are enriched with SLAs.

The API offers to the application developer a framework which helps in building custom SLA, as well as in seamless integration of their management in service provisioning. At state of art few frameworks exists that offers such kind of functionalities: the one produced by SLA@SOI [4547], which proposed a solution for building SLA managers to be integrated in service oriented architectures, or WSAG4j [48] which is a Java library compliant with the WS-Agreement standard (that defines protocol and format for SLA representation and management). Such frameworks are complex and expected to be integrated by Cloud providers: SLA are defined by the provider and the users can access only a set of predefined templates.

The SLA management in mOSAIC is considered to be different from such predecessors in its concept: the main goal of mOSAIC’ SLA framework is to enable a developer to easily integrate a single application with an SLA life cycle, so instead of offering a single and static general purpose solution for SLA management for any application, a set of micro-functionalities is offered to be integrated with the application in order to build up a dedicated solution for the application developer problem. Due to the component-based approach of the API, it is possible to build up applications enriched with user-oriented SLA management, from the very early development stages. Example of such microfunctionalities are the SLAgw which offers a REST-based interface to submit and sign SLAs, the SLAstore which maintain the SLA life cycle or the SLApolicy which is adopted to automate the enforcement of SLA policies.

Following such approach SLAs can be defined both by the developers (offering SLA templates like with other solutions) or defined by the users (following the standard WS-Agreement format); in such latter case it is up to the application to parse and eventually accept or refuse the submitted SLA. mOSAIC’ SLA framework offers the tools to access the submitted request and templates for building custom decision components, which have the role of making decisions on the basis of the SLA submitted. Such user-centric service level management is further discussed in details in [49].

Note that the SLA parameters to be supported in such solution are strictly dependent on the application and their management is delegated to the application developer. The SLA framework was applied further for the management of security-based SLA (in [5053]) and has been integrated in simulation engines able to predict the evolution of the developed application [54, 55].

SLA-based brokering and negotiations

The mOSAIC’s brokering mechanism is an intermediary between the resource consumers and the resource providers. The best SLA from the point of view of consumer is identified [56]. The policies that can be used are presented in [57], the basic one being the ’lowest cost’. SLA-based brokering mechanisms for ’lowest cost’ strategy were detailed in [58].

Exploiting the event-driven architecture, a SLA condition violation triggers an event that can lead to a reconfiguration. A reconfiguration mechanism was therefore conceived, and it is based on rules and a reasoner [59].

Assuming that the Cloud providers are willing to negotiate the costs of the resources, a more complex mechanism with stages for negotiations can be conceived, as the one presented in [60].

Semantic processing and ontology

Semantic engine

The Semantic Engine is a mOSAIC component helping the user in selecting APIs components and functionalities needed for building new Cloud applications as well as in identifying the proper Cloud resources to be consumed. It introduces a new level of abstraction over the Cloud APIs, by providing semantic based representation (in the OWL language of the Semantic Web) of functionalities and resources, related by properties and constraints. The detailed architecture of the solution is presented in [61].

Using the Semantic Engine the developer of Cloud applications can semantically describe and annotate the developed components, specify application domain related concepts and application patterns, potentially using application domain ontologies, as explained in details in [62].

The Semantic Engine overcomes the syntactical differences between Cloud services, resources or their programming models. Automatic analysis of Cloud Vendor APIs is therefore possible, as demonstrated in [63]. Moreover, the semantic representation of Cloud APIs combined with automated algorithmic concept recognition in object-oriented code, augmented with structural based matchmaking techniques, can be a strong basis for porting existing applications towards Clouds [64].

The semantic techniques are used for describing application requirements. The Semantic Engine infers the infrastructural requirements from the application description and from other information, and produces a vendor agnostic SLA template [65].

Cloud ontology

While several Cloud ontologies were developed before mOSAIC (like the one proposed in [66]), the mOSAIC’s one is built upon existing standards and proposals analysis through annotation of documents, as described in depth in [67]. It is used in the mOSAIC’s semantic processing.

The mOSAIC’s Cloud ontology has been developed in OWL. It has been populated with instances of Cloud provider APIs. The knowledge base can be extended with new Cloud provider APIs in the future. The initially proposed ontology was first exposed in [68]. Later on it was augmented with services specific terms – a list of enhancements is presented in [69].

Integration platform

For the purpose of this paper, the collection of individual components that represent mOSAIC’s proof-of-concept prototype solutions are depicted in Figure 1. Individual components, like API implementations, application developing tools, vendor modules and so on are part of the integration platform (named here the mOSAIC’s PaaS).
Figure 1

Component view of the integration platform.

Core components of the software platform

Core components are aiming to enable the run-time and deployment functionalities offered by the platform. These include: mOS, Deployer, Container, Components-of-the-Shelf (COTS) and Drivers. They are responsible for the platform control, scheduling, scaling, monitoring, application deploying and so on.

mOS is a customized Linux kernel running in virtual machines. It is used to host and control the platform and the application components. The Deployer is a core component which deploys software modules on mOS: the packaged component is retrieved by the Deployer from the named location and installed into an appropriate execution environment inside the instantiated Virtual Machines. A Container is a component which hosts Cloudlets, and is responsible for meeting the requirements of elasticity and fault tolerance. The Drivers access specific API of external Cloud services, and are built, for example, for message queue mechanisms like RabbitMQ [70], for key-value stores provided by Amazon S3 [71] or Riak [72], or for distributed file system HDFS [73].

The functionality of the core components was described for the first time in [74]. Aspects like reliability or fault-tolerance support are treated in later papers like [75].

Commercial off-the-shelf components

A number of software components were adapted, so that they can interoperate with the mOSAIC platform and facilitate seamless application development and deployment. Examples of components off-the-shelf (COTS) that are currently available are: RabbitMQ Server, Riak Server, CouchDB server [76], Jetty web application server [77], MySQL server.

In mOSAIC, COTS are viewed as Cloud software resources, based on open source technologies and re-usable. These components are deployed as any other component and can be managed, monitored, and accessed via specific Drivers.

Application development and deployment tools

Several tools are offered to enable the seamless development of new applications or the deployment of the existing applications. Eclipse plug-ins, for example, allow the development, deployment, debugging and control of the components written in Java. A Web interface and a command line interface are available to monitor the status of the deployed components (including analysis of the logs) and to control the life-cycle of the running applications. Configuration tools and editors are provided so that, for example, it is possible to build Call-for-Proposals, which may be directly submitted to the Cloud Agency.

The Portable Testbed Cluster (PTC) is a specific component that allows for application testing on the developer’s desktop computer. The PTC simulates a Cloud environment using VirtualBox [78]. Its also uses a simple resource allocator, a credential service (which stores the credentials for a specific user for a specific Cloud provider), and the storage of the application components in a Web accessible location. Through its graphical interface the PTC allows the seamless movement of the locally developed application into a Public or Private Cloud.

Open-source and portability of the integrated platform

A large part of the integrated platform is offered as open-source in the mOSAIC’s Bitbucket collection [79]. Tables 1 and 2 map the components to the corresponding repositories. The open source part makes it possible to design and execute a variety of Cloud applications.
Table 1

Open-source codes in Bitbucket repository (Part I)





API implementations


Java API

Provides the developer with an asynchronous API formanaging a customized Component and allowing the access to various data sources and backends


Python API

Similar with Java API, but for Python



Tools for Erlang



NodeJS implementation


DFS Java Connector

Java Connector for distributed file systems


Realtime feeds

Allows interested users to receive live updates of various ATOM feeds, via a Web interface



Application tools



A set of functionalities implemented inside the EclipseRCP that permits to have a fully functional Eclipse workbench to work with the mOSAIC platform



Allow the user to interact with the actual tool implementations (the backends) via various interfaces like CLI (Command Line Interface) or graphical UI’s


Eclipse plugins - Editors

Provides the end user a way to edit the configuration files in a completely visual way


CA Connector

Cloud Agency Connector


Portable Testbed Cluster

Local virtual cluster environment that simulates a IaaS


Application service components



SLA REST interface



SLA storage management component



SLA Policy Component



Java benchmarks



Vendor modules (in mosaic-vendormodule-*)



Amazon vendor module



CloudSigma vendor module



Eucalyptus vendor module



Flexiscale vendor module



GoGrid vendor module



Vendor module for Hungarian IaaS



OpenNebula vendor module



OpenStack vendor module



Module for mOSAIC’s PTC



VMware ’s vCloud vendor module


Table 2

Open-source codes in Bitbucket repository (Part II)





Platform’s core components



Allows the developer to observe and control the running components (either Cloudlets, Drivers, Resources, etc.)


Component hub

Intermediates communication between the components, and other various needed services (eg. logs)


Resource allocator

Resource provisioner based on existing credentials

Included in PTC

Execution engine

Container: Component responsible for instantiating linux containers (LXC) from mosaic bundles (containing all required data for running an application)



Agent: Running inside the Containers providing application setup, startup and monitoring


Naming service

Allows the registration of new components and their discovery by other components



A Python RPC implementation based on JSON-RPC2, providing introspection, Unix socket based protocol, standard Http protocol support and a simple CLI application implementing the protocol



Packaging utilities and repositories


Scheduler & Scaler

Scheduling and scaling components


Credentials service

Provides secure access to various credentials or secret tokens needed by various libraries or components to access external resources



mOSAIC operating system: the system includes the platform’s core services



Deployable COTS and Drivers


RabbitMQ component

Customized variant of RabbitMQ which makes it behave like a managed component


Riak component

Customized variant of Riak which makes it behave like a managed component


CouchDB component

Customized variant of CouchDB which makes it behave like a managed component


HTTP Gateway component

Intermediates HTTP requests between clients on the Internet and components handling those requests. Provides routing and load balancing


mHTTP Gateway component

Routes HTTP messages on queue and enable access to a key value store. Renders HTML pages


AMQP driver component

Message Queue driver for the AMQP protocol


Riak driver component

Key value driver for the Riak component


HDFS driver component

Distributed File System driver for Hadoop


MySQL component

A component for handling (starting/stopping) a MySQL database engine


The platform is theoretically deployable on any Linux-based virtual machine. mOS needs to be first installed to make available the core components. For several providers (e.g. Amazon, Flexiant), virtual machine images, with mOS already installed on top, are publicly available.

The fact that the mOSAIC’s platform is deployable makes the difference from other PaaS, like Google Application Engine [80] or Microsoft Azure [81]. An open-source and deployable PaaS, developed in the same time with mOSAIC, is the VMware’s Cloud Foundry [82]. Compared with this one, an advantage is the complete openness of the mOSAIC’s API.

Platform-as-a-Service characteristics

As discussed earlier, by using mOSAIC, the developer of a Cloud application can postpone the selection of a Cloud infrastructure provider, from the development to the deployment phase. Through the usage of the application tools, a seamless deployment of the application in various Public Clouds is possible after its development and debugging in a Private Cloud or on a local computer. This is more than a Platform-as-a-Service can currently offer – usually the application is deployed immediately on the infrastructure that the PaaS owner provides.

A classical PaaS is not exposing the infrastructure services that are used, while in mOSAIC its user is aware and able to control the resource services. From this point of view mOSAIC distinguishes from other PaaS, as being a portable and lightweight management software for IaaS.

Proof-of-concept applications

The concept of a mOSAIC Cloud application

A mOSAIC compliant application is built from loosely coupled components. Its execution is expected to have no limits in time. It may be expected that some of the components would be elastic, i.e. able to scale up and down in number. The most common cases of Cloud applications are Web applications, which fully fit into this behavioral model. However, the mOSAIC API and platform are suitable for building and deploying also other applications which can have the same behavior.

There are two basic scenarios of using the mOSAIC set of solutions:
  1. 1.

    Developing a new application from scratch. In this case the developer has the possibility to use most of the software tools provided by mOSAIC, starting with the API implementation and the application tools. The Semantic Engine can be used to find proper design patterns. Application tools can be used to prepare a Call-for-Proposal for the Cloud Agency and to approve one of its responses. Software platform services are responsible to deploy, control and monitor the executing application.

  2. 2.

    Migration of an existing application. In this case the application owner may be interested in finding a proper place to deploy the application, and the Cloud Agency is the main tool which is used in the process. The application owner may use the application tools to properly describe the application and to make a Call-for-Proposal to the Cloud Agency. Only a part of the platform is used to control the application after its deployment.


Benefits of using mOSAIC

The main reason of using the mOSAIC solution may be its vendor-agnosticity. The application developer and owner can select at run-time the Cloud services to be consumed (usually this decision need to be made at design phase). A side effect is the possibility to migrate applications from one Cloud provider to another. Therefore mOSAIC can be used to port applications between Clouds. Other reasons for using mOSAIC may be more technical:
  1. 1.

    Ability to ensure the elasticity at component level (usually done to a lower level of granularity, at virtual machines level).

  2. 2.

    Integration in one set of solutions of application development tools with deployment and control tools, as well as with Cloud brokering mechanisms.

  3. 3.

    Open-source technology that allows extensions as needed for special applications or embedding of other technologies.

  4. 4.

    Deploy-ability that allows to use on-premises resources in development phase and to build Private or Hybrid Clouds enabled applications.


Demo applications for the API usage

Simple applications, like the ’Hello world’, producer-consumer, ping-pong messaging and so on, are provided for the Java implementation of the API. The example applications as well as various Cloudlet templates are available in the open-source repository.

A more complex application that combines COTS and developed Cloudlets, is a so-called real-time-feed application. It is small a RSS feed alerter. A classical implementation supposes a poll mechanism that constantly fetches content and makes a comparison with the previous version of the retrieved content to see what is new. On contrary, the demo application implements a push method which identifies the changes and announces them to the event listeners. It uses Twitter’ streams of updates to subscribed applications. A first-time description is available in [83].

Proof-of-concept scientific and commercial applications

In the context of mOSAIC project, a variety of applications were developed. These include:
  1. 1.

    an Earth observation application where IaaS is procured for processing satellite data in emergency situations (e.g. earthquakes);

  2. 2.

    an Intelligence Maintenance System allowing maintenance of devices from different industrial scenarios through early diagnosis of faults in critical components and real-time monitoring of key variables;

  3. 3.

    a Model Exploration Service, an online service to run agent-based simulation, requiring scalability;

  4. 4.

    a port to the Cloud of a legacy application for the information extraction from scientific papers;

  5. 5.

    a port to the Cloud of an engineering application for analysis of structures under static loading, with the intention to make it available on the Internet without the need for special licenses or environmental settings.


The Earth observation application prototype dealing with big sets of large-sized data is based on GMTSAR, an open source processing system. It uses the mOSAIC Cloud Agency as independent component for the provisioning of computational resources to create Virtual Clusters to run an OpenGIS Web Processing Service server and a Hadoop framework. The main benefit of using the mOSAIC approach is related to vendor-agnosticity. The prototype is described in [84].

The Intelligent Management System intends to manage easily and rapidly large amounts and continuous streams of information. It has been written using the mOSAIC API specifications. Two main groups of components are used: components provided by the platform (message queues, storage systems, HTTP gateway, etc) and specific components implemented as Cloudlets (for sensor data management, knowledge extraction dispatcher, etc). The main benefits of using mOSAIC are: the elasticity of the application depending on the required computation capacity, and the usage of fault tolerance features. A preliminary description is provided in [85].

The Model Exploration Service is an online service to run agent-based simulations in the Cloud. Cloud resources are used to run large parameter sweeps of the models. The initial application has already run using Amazon’s AWS. The porting of the application by applying the mOSAIC approach has not involved only the change of calls from the Amazon API to the mOSAIC API. The internal architecture of the application was changed to adopt mOSAIC design principles (the Cloudlet model) to facilitate scalability, portability and autonomous reconfiguration. By avoiding vendor lock-in, the new version of the application can be moved across ‘Cloud borders’, or the application can be Multi-Cloud in the sense that certain parts run on different provider infrastructures. The application architecture was first presented in [86].

Information extraction from scientific papers is a part of the ReReSearch project that aims to build a knowledge base about research. It is a computationally expensive task and, as the number of papers to be processed varies considerably in time, there is a need for elasticity of the Cloud (the preliminary study [87] lists the requirements). The legacy Python code implementing the extraction algorithms was split into components and wrapped into Cloudlets. These Cloudlets, managed by the mOSAIC platform, make the application elastic and portable. The Cloudified extractor is exposed as a RESTful web service which can be used as needed by ReReSearch control system. Implementation details are exposed in [88].

The Analysis of Structures under Static Loading application is based on a specific Finite Element formulation, which allows the modeling of a desired structure by beam elements. It is based on the NoDeK software which is written in Matlab and used by small number of construction engineers, due to the required Matlab licenses for running the simulation. The application has scalability problems and its user-friendly interface could be considerably improved. There are several reasons to use Cloud computing technology, e.g. offering the application as a service has the target of widening the customer base. The reasons of selecting mOSAIC is related to the expectations of faster calculation in Clouds than on the local desktops, as well as to deal with the dynamic change in the number of concurrent users. The design of the Cloudified version of the application is available in [89]. Matlab-based Cloudlets were designed and are presented in further details in [90]. The use of Semantic Engine usage in the development phase of the application is exposed in [91].


A mOSAIC application is developed without taking into account the target provider, however when the application needs to run and consume resources, the choice of the infrastructure provider may significantly affect the application performances and costs of using the infrastructure. The evaluation and prediction of such performances for applications is a complex task, due for example, to the elasticity offered by Cloud resources, or the high number of layers involved.

In order to face the problem of choosing appropriate infrastructure provider, mOSAIC provides a Benchmarking Framework. The framework contains a set of components that can be used in order to setup a custom benchmark which measures the performances of the target application under well known workloads. Such benchmarks are built “ad-hoc” for each different application, even if a set of stable application for common resources and application are available and can be used as kernel benchmark to compare different providers [92]. Moreover, through the adoption of simulation techniques it is possible to use benchmark results to predict the behavior of application in different execution conditions, as proposed and demonstrated in [93].

Scientific applications support

While being partially an open-source solution, it is expected that mOSAIC is interesting especially for the academic communities. As pointed above, mOSAIC has prove its utility for several scientific applications with different requirements. Therefore, the opportunity for mOSAIC to be a science facilitator was investigated recently in [94]. An early study of migration from Grid to Cloud using mOSAIC concepts is provided in [95] for a platform intended for high education activities in Earth observation. The support for scientific legacy applications through self-configuration is exposed in [96]. For the particular case of engineering application, a comprehensive study can be found in [97].

Beyond the promises


Security is a critical issue for the Cloud adoption. While mOSAIC has not promised initially to deal with this topic, in order to offer a complete solution, the problem of security in multiple Clouds was studied in order to define, develop and adopt a mOSAIC-specific security approach. Taking into account the target of mOSAIC for multiple Clouds, the available solutions for Cloud Federations were analyzed in deep in [98], establishing the basic requirements. The research activities acquired experiences from previous work related to Cloud and Grid integrations, as exposed in [99]. The main security problem that was treated is related to the access control solutions, as presented in [100]. The mOSAIC’s SLA framework was integrated into an automated access control mechanism for the Cloud and Grid, as proved in [53]. The FP7 project SPECS (Secure Provisioning of Cloud Services based on SLA management [101]), starting in Autumn of 2013, will continue to enhance the mOSAIC’s SLA framework.

Due to the Cloud elasticity and auto-scalability features, denial of services was considered one major threat. Therefore denial of service attacks, specially targeted to Cloud systems, were were studied in [50, 52]. A mOSAIC based solution for protecting Cloud applications against such attacks was proposed in [51]. Finally, a special service was designed based on SLAs: Intrusion tolerance as a Service [102].

Another research direction considered the secure authentication negotiation in Cloud. The first results are exposed in [103].


Cloud governance comes as the next development step after Cloud management. It provides the ability to set policies within the environment in order to ensure the system’s wide security, privacy and compliance. It is provide also the business level missing in Cloud management solutions. While the Cloud management is providing an execution environment, according [104], the Cloud governance is in charge of decision making in order to achieve objectives that meet its customers’ needs.

As shown in [105] the multi-agent systems are fit to build a Cloud governance solution due to the autonomous nature, fault tolerant behavior and ability to self-organize. Therefore the mOSAIC which is based partially on multi-agent systems provides a convenient environment to study the merge of Cloud management and Cloud governance. To do so, the requirements in order to achieve Cloud governance in mOSAIC were established in [106], most importantly being the ones related to service lifecycle control and governance bus.

Cloud service lifecycle in a Multi-Cloud needs to take into account the distribution of services across different provider sites and the ability of services to scale. The core aspects of a service lifecycle, including service template, offering, contract, provisioning service, runtime maintenance, and end of service, are extended in the mOSAIC’s governance architecture, first time presented in [107].

A Cloud governance bus needs to handle messages, security, exceptions, protocol conversion and to provide an adequate level of quality of services. The bus proposed in [108] implements enterprise integration patterns as well as data integration services which enables easy access to datastores.

Particular attention was given in mOSAIC to the data services as part of the proof-of-concept applications which are dealing with big data (static and streaming). Data-stores and the appropriate services were studied and developed in conjuction with the mOSAIC’s Cloud governance solution [109, 110]. Another issue that was treated in the same context is the security of the data [111].

The Cloud governance can lead to an unitary ecosystem, where applications can be easily created, managed, discovered and can easily interact one another. This is aligned with the idea of InterCloud and Cloud Blueprint, introduced in [112]. The grounds for such an ecosystem based on mOSAIC’s approach were put in [113].

Resource management: scheduling and application monitoring

Scheduling mechanisms are widely used in distributed systems. However the particularities of Clouds impose a reconsideration of these mechanisms. In order to come with a practical offer, the scheduling problem in Clouds and Multi-Clouds was studied. An initial proposal for the particular case of workflows and based on multi-agent systems was presented in [114]. Starting from this proposal and exploiting the capacity of multi-agent systems for regeneration, a self-healing scheduling mechanism was later on presented in [115].

A large category of Cloud applications are long-running and their high availability is essential. In this context and taking into account the design of mOSAIC application based on components, in [116] is proposed a scheduling mechanism of replicated components aiming to reach the objective of highly availability despite multiple faults in Multi-Cloud. Another scheduling mechanism based on cost constraints was presented in [117], while a novel P2P scheduling scheme has been introduced in [118].

Monitoring services are usually referring to the infrastructure delivery indicators and are in relationship with service level agreements and quality of services. However, the user is highly interested in the behavior of particular applications deployed in Clouds. Therefore an important topic should be the Cloud application monitoring. Taking into account the component based architecture of the mOSAIC applications (including the communication system as a component), the component monitoring can be considered. This approach for the monitoring services was first presented in [119].

Model-driven engineering

In mOSAIC a Cloud application consists of loosely coupled components, which in particular can wrap legacy software. In this context, the paper [120] investigates the possibilities to introduce a model-driven architecture which support composition, customization, flexibility, maintenance and reusability of Cloud application components in the particular case of scientific and engineering applications.The approach is illustrated through the design and operation of the application for analysis of structures under static loading.

A methodology, named MetaMORP(h)OSY, that uses model-driven engineering and model transformation techniques to analyse Cloud services was introduced in [121]. Due to the complexity of the systems to analyse, when modeling profiles are built with MetaMORP(h)OSY, the mOSAIC Ontology is used as being able to specify Cloud domain-related properties. Following the methodology, a proof-of-concept for a particular Cloud use case is provided in [122].

Related projects, prototypes or applications

Related projects

mOSAIC has a strong relationship with two national projects: the Italian Cloud@Home [123] and the Romanian AMICAS [124].

The primary goal of Cloud@Home is to implement a volunteer Cloud, by which both the commercial/business and the volunteer/scientific viewpoints coexist. Several topics that are treated by Cloud@ Home and are not primary targets to mOSAIC have lead to common proposals. Two topics are in this context relevant: performance management exposed in [125], and quality of services exposed in [126]. Moreover the SLA-based mechanisms for brokerage are common to mOSAIC and Cloud@Home [127]. CHASE [128], Cloud@Home’s Automatic Service Engine is designed to optimize the scheduling of virtual machines in a Cloud environment based on the a performance prediction service and a forecast service.

The primary goal of AMICAS is to offer a solution for Automatic Clouds. Opposite to mOSAIC which is targeting the Cloud users, AMICAS is targeting the Cloud providers, intending to offer them an easy manageable middleware (Cloudware) for Multi-Cloud. It starts from the mOSAIC’s software platform and enhances it with facilities of interest to Cloud providers. An important topic that is tackled by AMICAS, using the mOSAIC experimental platform, is the programmability of services for multiple Clouds. The steps to reach a high level of programmability were discussed in [129], while the programmatic management of services from multiple Clouds using mOSAIC was described in [130]. Another subject is the auto-scaling mechanisms, essential in Cloud computing environment. Currently most of such mechanisms that are used by Cloud providers are centralized. Taking into account the perspective of the Multi-Cloud, such centralized approach is not appropriate. A decentralized auto-scaling mechanism was therefore proposed in [131] for the case of homogeneous systems, and was extended for the heterogeneous systems in [132]. Theoretical analysis of the background algorithm correctness is presented in [133].

mOSAIC’s software platform is used as a Multi-Cloud resource management middleware in another current project funded by the European Commission: more precisely, it plays the role of run-time environment in the model-driven engineering project named MODAClouds [134]. Its role in the architecture is explained in the early position paper [135].

Moreover, the Earth Observation application can be viewed as a preliminary study for the Earth Observation Use Case scheduled in the frame of the Helix Nebula project (Science Cloud initiative funded by the European Commission [136]).

Related prototypes

As stated earlier, mOSAIC is interested to support scientific applications running in Clouds. A large category of scientific applications are based on parallel computing simulations.

mJADES is a prototype for concurrent simulations in Clouds, using the mOSAIC’s SLA framework. It is the result of Italian PerfCloud project (building an environment for IaaS provision based on Cloud and Grid integration). Its architecture is explained in [55]. Using this prototype several performance prediction studies of Cloud-based parallel simulations were done [54, 137].

The mOSAIC software platform is used by the prototypes of services delivering HPC-in-the-Cloud in the frame of HOST project [138] funded by European Commission in the frame of FP7 Capacities programme [139].

The mechanism used in Clouds and Grids for resource identification and brokering are close. Key ideas that were the basis for mOSAIC Ontology and Brokering systems were used recently in the Grid context. An Ontology for contract negotiations was presented in [140], while negotiations in an agent-based grid resource brokering system are exposed in [141].

An adaptive and semantic database model for RDF data stores [142] was also conceived following mOSAIC data service examples.

Related software products

Olaii [143] is a commercial product emerged as side effect of developing the dynamic semantic discovery service of mOSAIC. Information extraction library developed under the umbrella of mOSAIC’s dynamic semantic discovery service is focused on extraction of the semantic descriptors for REST APIs, but can be extended to cover other use cases. The product is an application which will help discovering events or finding friends to go out with. The semantic extractor developed in mOSAIC is modified to extract the events instead of REST operations. Machine learning techniques applied in the semantic extractor to classify REST operations and to find irregular operations are applied for the events for building a recommendation system based on users’ Facebook or Twitter profiles.

mOSAIC is currently used to provide an information service to the citizens of the third largest town of Romania. More precisely in the frame of SEED project [144], funded by European Commission through the CIP programme [145], a particular information service was build using mOSAIC API and platform and continuously extracts feeds from governmental sites (European, national and regional) as well as public service institutions (theaters, public transportation etc) and display them on in- and out-door large devices. The application is similar to the real-time-feed demo application.

mOSAIC positioning

Position as a solution for interoperability and portability in multiple Clouds usage scenarios

Generally speaking, the interoperability problem has three dimensions in the case of Cloud computing domain:
  1. 1.

    a design dimension, that deals with the need to abstract the programmatic diverse interfaces of various services,

  2. 2.

    a dynamic run-time dimension, that deals with the need to support migration of the Cloud application from one provider Cloud to another provider Cloud, and

  3. 3.

    a policy dimension, that deals with the need to support communication and federation among the Cloud providers.


mOSAIC is dealing mainly with the first dimension, ensuring an abstraction level for vendor-agnosticity. While is not tackling explicitly the migration or federation, it allows on-demand re-deployment of the supported application in various Clouds.

The portability problem has also three dimensions (all tackled by mOSAIC):
  1. 1.

    a functional dimension, that refers to the application functionality in an environment-agnostic manner,

  2. 2.

    a service dimension, that refers to the on-the-fly adding, reconfiguration and removal of resources, and

  3. 3.

    a data dimension, that refers to the import and export of data in different formats.

The main requirements of portability (following the comprehensive list from [146]) are met by the mOSAIC solution as indicated in Table 3.
Table 3

Portability requirements (five most important ones in of the six category) and their degree of fulfillment by mOSAIC







Economic models

Model of a component-based market

SLA and performancemonitoring

SLA compliance checks,component monitoring

License flexibility


Sets of benchmarks

Benchmarks forcomponent based applications

Negotiated SLAs

Through Cloud Agency

Load balance monitor

Through Containers


Broker mechanism

Service audit

Leasing mechanisms

QoS aware services



Data portability and exchange

Unique API for sametype of data services

Deploy in multiple Cloudswith single tool

PaaS’ Deployer

Scale-in and -out

Elasticity of Cloudlets

Service discovery

Based on semantics


No location restriction

Automated provisioning

Requires user consensus

Workflow management

Componentsstarted in requested order

Navigation between services

Span on multiple Clouds

If no communication

Behavior prediction


AA & Security

Minimal reimplementationwhen move


Trust mechanisms

Intrusion-detection as a service

Common set or standard APIs



Credential service

Same tools for cloud and entreprise appls

Eclipse and Web GUIs

Security standards

Use Cloud vendor certificates

Ontology of Cloud

Own Cloud Ontology

Single sign-on

High level modelling

Digital identities

There are currently several technical approaches to deal with portability and interoperability: open APIs and protocols (like jclouds [147], libcloud [148], OpenStack, OCCI [149] or δ-Cloud [150]), standards (like OVF [151], CDMI [152] or CIMI [153]), frameworks (like for SLAs from SLA@SOI project), semantic repositories (like UCI [154]), or domain specific languages (like CloudML [155]). mOSAIC is an integrated solution that offers an open API with a high level of abstraction, and uses OCCI, SLA@SOI framework and semantic processing.

Position as enabler for Multi-Cloud, Federations and InterCloud

There are several reasons for the use of services from multiple Clouds. The ones motivating mOSAIC are the following two: (1) ensure the avoidance of vendor lock-in by relaying upon the services from two or more providers; (2) support Hybrid Clouds build from Private and Public Clouds in order to deal with peaks or customer requirements.

According to the NIST report [156], multiple Clouds can be used sequentially or simultaneous. The sequentially usage is related to the migration from one Cloud to another driven from economic reasons (e.g. cost reductions, emergencies, back-ups etc). The simultaneous usage of services from different Clouds can also have several benefits like high availability and fault tolerance. mOSAIC is mainly targeting the first scenario, while is not excluding the second one.

According to [157], two delivery models can distinguished for multiple Clouds. The first one, the Federated Cloud, assumes a formal agreement between the Cloud providers. The second model, of Multi-Cloud, assumes that there is no priori agreement between the Cloud providers. mOSAIC is targeting mainly the Multi-Cloud, establishing only at deployment phase the needs in terms of services and the contacts with the Cloud providers.

According to [158], the term Multi-Cloud denotes the usage of multiple and independent Clouds by a client or a service. Clients or their software representatives are responsible for managing resource provisioning. In the same paper Multi-Clouds are classified in two categories. The first category is that of libraries allowing the usage of multiple clouds in a uniform way (including brokers that directly take care of provisioning of services across Clouds). The second category is that of services for provisioning resources which are hosted either externally or in-house by the clients, and which usually includes a broker. In this case the clients are entitled to specify a service level agreement or a set of provisioning rules and the service performs accordingly the deployment and execution. As the authors of [158] have correctly noted, mOSAIC can be mapped to the second category, of services.

We should remind that in the category of libraries, the most known products are the Python library Libcloud, the Java library jclouds, the REST API δ-Cloud, the PHP API Simple Cloud [159], or C++/ Python/Java API SAGA [160]. These libraries can be used as Drivers in mOSAIC. Moreover, mOSAIC’s API libraries are available for Java, Python, Erlang and Node.js.

In what concerns the Multi-Clouds based on services, we consider that there are two categories: hosted services and deployable services. mOSAIC belongs to the deployable category.

Three hosted services are most relevant in this moment: RightScale, Enstratius and Kaavo. RightScale [161] offers a Private Cloud management platform for control, administration, and life-cycle support of deployments across multiple Clouds (it supports Amazon, Eucalyptus, GoGrid, VMware and FlexiScale); server templates are available to automatically install software on supported Cloud infrastructures. Enstratius [162] allows configuration management, monitoring, governance and automation and it supports Amazon, CloudStack, CloudSigma, Eucalyptus, GoGrid, Joyent Cloud, OpenStack, Rackspace, vCloud, Azure and others. Kaavo [163] allows also the deployment and management of distributed applications, workloads, and environments in various Clouds enabling resource management across Public, Private, and Hybrid Clouds (it supports Amazon, Rackspace, OpenStack, Eucalyptus,, Terremark, Logicworks, HP Cloud and IBM Cloud).

In terms of number of Cloud providers that are supported, mOSAIC is similar with the above mentioned hosted services, but with a clear preference for the support of European Cloud providers. In terms of GUIs the mOSAIC Web oriented one is considerably different, as designed to serve applications, not resource management: the user does not control the resources distribution or consumption (provider interfaces can be used for this purpose), but instead controls the processes of the application that are running (an application oriented view, instead a resource provider view).

The current deployable services for Multi-Cloud are in prototype phases as results of different research projects. Two main competitors for mOSAIC are currently available: Aoleus and Optimis. The RedHat’s Aoleus [164] is an open-source Cloud management software written in Ruby for Linux systems. It allows users to choose between Private, Public or Hybrid Clouds, using δ-Cloud library. The Optimis Toolkit [165], result of the project with the same name and funded by the European Commission in the same work-programme as mOSAIC (in parallel with it), offers a platform for Cloud service provisioning that manages the lifecycle of the service and addresses issues like risk and trust management. Compared with Aoleus, mOSAIC has the advantage of including more than a resource management middleware (not restricted to the δ-Cloud list of providers). Compared with Optimis, mOSAIC is weaker in terms of trust and risk management, or even in brokerage process due to the reduced set of policies; however the semantic processing support, the SLA-based negotiation mechanisms, or the application tools are the main comparative advantages of mOSAIC.

A comprehensive analysis of mOSAIC positioning versus the research prototypes for Federations and Multi-Clouds, complementary to the above one that is mentioning software products, was recently exposed in [166].

A Cloud Federation or a Multi-Cloud that includes at least one Cloud Broker and offers dynamic service provisioning is an Inter-Cloud. In the case of Multi-Cloud, the Broker is often part of the service or library. This is the case also for mOSAIC. According [158], the brokering mechanisms are: SLA-based, i.e. requirements are specified by clients in the form of a service level agreements; or trigger-action, i.e. rules are becoming active, triggering an action, when a predefined condition considering the externally visible application performance indicators becomes true. Evidently, mOSAIC has a SLA-based brokering mechanism. However, taking into account its event-driven orientation, part of its behavior is based on rules and triggered-actions.

The most relevant representatives for SLA-based brokers for Multi-Clouds are SpotCloud and Stratos. SpotCloud [167] provides a marketplace where service providers sell the extra capacity they have and the clients can select the ’best’ service provider at a certain moment. WSO2 Stratos [168] provides core services and building blocks for federated identity and single sign-on, data-as-a-service and messaging-as-a-service, and monitors SLAs, CPU, memory and bandwidth utilization and automatically scales up or down depending on the load. The mOSAIC brokering, monitoring, scaling or messaging mechanisms are rather simpler compared with SpotCloud and Stratos ones. However, its component-based and open-source design has the comparative advantage of easy updates and customization according to user’s needs.

mOSAIC has not been yet able to establish a market place, as SpotCloud, but it does not exclude the idea. A Cloud platform supporting applications composed of software components can come with a component store which provides components for common tasks. Using such a store, developers should be able to build new applications and services by configure and compose the existing components, or by extending them with new functionalities. Moreover, a dynamic recomposition of software during execution, i.e. adding, removing or reconfiguring components within an application at runtime, should be possible. A case study of using mOSAIC and a component market for the design of a Bussiness-Process-as-a-Service is sketched in [169].

Position as PaaS

As described earlier, mOSAIC exhibits some characteristics of a PaaS. Despite the fact that is not a hosted service, but a deployable one, it offers several tools and facilities to develop, deploy and control at run-time new applications. We consider here only two significant PaaSs to be compared with mOSAIC’s PaaS. While the PaaS offer is quite diverse, the selection is based on the usage spread, respectively closeness to mOSAIC.

Google’s Application Engine (GAE) is one of the most known PaaS. While the deployment facilities are more complicated in mOSAIC due to the need of the user final decision in selecting the Cloud provider, several limitations of GAE are avoided by mOSAIC. For example file-system write access are forbidden in GAE; applications are not allowed to make arbitrary network connections to the Internet and HTTP requests must be made only through a special library. All data handled by GAE must be stored in a columnar database, and even though the developer has a query language resembling SQL, it is very limited in what concerns filters. Moreover, in GAE the requests should be handled within one minute or less. All of these restrictions are not encountered in mOSAIC approach.

From the long list of hosting PaaS, Heroku [170] is the most closest to mOSAIC concepts. Its features have inspired not only mOSAIC, but also most of the recently emerged PaaSs. The reason is its simple scheme to handle development, configuration, deployment, and management. It supports a variety of programming languages (Ruby, Python, Node.js, Scala and Clojure), as well as arbitrary executables either as binary or scripts. However, there are several improvements that mOSAIC has been able to provide. For example, it is actually impractical to mix multiple languages in the same Heroku application, while in mOSAIC components can be written in various languages if they are able to use a message passing system. Any update of component of a Heroku application needs the complete shutdown of the application. In mOSAIC components can be stopped, started or updated during the execution of the application, as the messages are waiting in the queues. Several other advantages are comprehensively discussed in [171].

Position in open-source community

As earlier mentioned, mOSAIC is included in the category of services for Multi-Cloud. However there are other open-source middlewares that are deployable, while not necessary designed with the Multi-Cloud in mind, still able to deal with homogeneous distributed resources. A comprehensive comparisons of them and mOSAIC positioning is presented in [172], including ConPaaS, the Contrail [173] solution for Federations. In the same paper are provided a series of criteria that can be used to compare PaaSs.

We mention here only VMware’s Cloud Foundry and Red Hat’s OpenShift [174], developed in the same time as mOSAIC. Both are dedicated to Web applications, while mOSAIC scope is more broader. mOSAIC is stronger also in terms of data support, the number of Cloud providers that are supported, the interfacing variants, the SLA and brokerage mechanisms, as well as portability on other Linux system than VMware or RedHat provided ones. However is weaker in terms of performance analytics or integration with other development environments than Eclipse.

Position in the landscape of Cloud Computing projects funded by the European Commission

Beyond Optimis, Contrail and MODAClouds that were mentioned earlier, there are several other Cloud computing projects that have run in parallel with mOSAIC and have provided close related solutions. A snapshot of the landscape covered by these projects in the late 2011 was provided with mOSAIC contribution in [175] in the book [176] that collects reports on the states of more than twelve such projects. The positioning of mOSAIC in relationship with several Multi-Cloud projects was expressed more recently in [177].

We remind here only few projects offering alternatives to mOSAIC approach or complementing it. 4CaaSt [178] is building a BluePrint for registering Cloud services in an e-Market. Cloud4SOA [179] is dealing with semantic based interoperability at platform level. Cloud-TM [180] is proposing another programming paradigm for Clouds. Remics [181] is dealing with migration of legacy applications to Clouds through model-driven engineering. TClouds [182] is offering security, privacy and resilience mechanisms for Multi-Clouds. Vision Cloud [183] is looking in details to the issues of data management in Federations and Multi-Clouds.

Conclusions and future developments

Drawing the line at the end of project, the mOSAIC’s multi-national team is checking the degree of fulfillment of the initial promises. Shortly these were:
  1. (i)

    a set of APIs for application portability between Clouds,

  2. (ii)

    agent technologies supporting dynamic negotiations with multiple Cloud providers,

  3. (iii)

    user-centric service level agreements,

  4. (iv)

    Cloud ontology and semantic data processing,

  5. (v)

    an open-source and portable platform-as-a-service,

  6. (vi)

    proof-of-concept applications.

Targeting to provide an innovative solution in these fields, mOSAIC approach has proven its uniqueness and advantages over other existing approaches in what concerns:
  1. (a)

    deployable and portable services of platform type on top of IaaS;

  2. (b)

    brokering system based on customizable service level agreements and agent technologies;

  3. (c)

    portability of Cloud applications supported by semantic processors and multi-layered API;

  4. (d)

    usefulness for porting scientific and commercial applications towards the Cloud;

  5. (e)

    a stable, complete and innovative middleware for building, deploying and controlling applications following Multi-Cloud usage scenarios.

While disparate proofs of the innovations are dispersed in various mOSAIC-related articles, the present report tried to offer a general overview of the main achievements and advantages of mOSAIC. However it highlights also some weaknesses in relationship with other approaches, subject to improvements in the next years:
  1. (1)

    the event-driven programming style of mOSAIC applications is considered to be complex by less skilled programmers; the templates collections as well as the workbench and wizzards should be improved to better assist the application developers;

  2. (2)

    the deployment of special libraries still require manual intervention; the deployment procedures are therefore expected to be improved;

  3. (3)

    the mechanism of the brokerage system allow complex policies to be applied; however, simple policies are currently used and the full potential was not yet exploited;

  4. (4)

    semantic processing is used currently at design phase; the potential of the dynamic discovery services, for example, has not yet been fully exploited.

  5. (5)

    several software prototypes have been developed as proof-of-concept and a considerable part of them, yet functional, are not ready for a production phase; according to the interest expressed by the community surrounding mOSAIC, particular components (like the PTC simulator and resource allocator) will be further improved to offer production-level quality of service;

  6. (6)

    commercial products developments has underline the need of enlarging the number of COTS that are wrapped to work with mOSAIC platform;

  7. (7)

    the proof-of-concept applications developed in the frame of the project are expected to be improved to satisfy the requirements of their external users.


Several topics that were not in the main focus of mOSAIC project are expected to be pursued in the near future relying on the mOSAIC approach and software repositories. We have already mentioned some of them in this paper: model-driven engineering for Clouds, Cloud security or automated management of Cloud resources. With certainty this will happen in the frame of the research, development and collaborative projects that already rely upon the mOSAIC’s specific components. We remind here some of them:

FP7 projects: MODAClouds in model-driven engineering direction, SPECS in security direction, HOST in scientific application support direction, Helix Nebula in Earth observation application field;

National projects: AMICAS, in the direction of automated management of multiple Cloud resources, or Cloud@Home in the direction of Volunteer Cloud.

The fact that the mOSAIC architecture is built from loosely coupled components enhance the chances for the open-source software prototypes to be adopted and enhanced in other contexts that mOSAIC initial scenarios. This is the case of the commercial product Olaii that was mentioned in this paper, which has started from the semantic extractor developed in the frame of mOSAIC project.



The research and development reported in this article was partially supported by the European Commission grant no. FP7-ICT-2009–5-256910 (mOSAIC).

The development of the mOSAIC approach was sustained by a large multinational team that is far from being reflected in the list of the authors of this paper: the paper’s authors are the key persons from each team that have drive the approach development. They are taking this opportunity to express their gratitude to the team members of mOSAIC project that are not in the author list:

– from Second University of Naples: Alba Amato, Giuseppe Aversano, Rocco Aversa, Antonio Bagarolo, Daniele Bove, Pasquale Cantiello, Giuseppina Cretella, Vincenzo De Crescenzo, Massimiliano Diodati, Massimo Ficco, Loredana Liccardo, Francesco Moscato, Manuela Serrao, Luca Tasquier;

– from Institute e-Austria Timişoara: Bogdan Alexandru Căprărescu, Adrian Copie, Ciprian Dorin Crăciun, Teodor-Florin Fortiş, Marc Eduard Frîncu, Georgiana Macariu, Victor Ion Munteanu, Marian Neagul, Viorel Negru, Silviu Panica, Călin Şandru;

– from AITIA: Rajmund Bocsi, Gabor Ferschl, László Gulyás;

– from Tecnalia: Unai Antero, Imanol Padillo Cruz, Gorka Mikel Echevarria Velez, Iñigo Lazkanotegui Larrate, Miguel Loichate, Asier Sesma;

– from TerraDue: Hervé Caumont, Pedro Gonçalves, Simone Tripodi;

– from ESRIN-ESA: Claudio Di Giulio, Fulvio Marelli;

– from Xlab: Mariano Cecowski, Gregor Pipan, Boris Savič;

– from Brno University of Technology: Petr Škoda, Pavel Smrž;

– from University of Ljubljana: Peter Češarek, Jernej Južna, Matija König, Aleš Kroflič, Gašper Stegnar.

Authors’ Affiliations

Institute e-Austria Timişoara and West University of Timişoara
Second University of Naples
AITIA International Inc
Industrial Systems Unit
Terradue SRL
Earth Observation Science, Applications and Future Technologies Department, ESRIN, European Space Agency
XLAB d.o.o.
Brno University of Technology
University of Ljubljana


  1. Armbrust M, Fox A, Griffith R, Joseph AD, Katz RH, Konwinski A, Lee G, Patterson DA, Rabkin A, Zaharia M: Above the clouds: A berkeley view of cloud computing. 2009. Tech. rep., EECS Department, U.C. Berkley, UCB/EECS-2009–28.Google Scholar
  2. Buyya R, Yeo CS, Venugopal S, Broberg J, Brandic I: Cloud computing and emerging it platforms: Vision, hype, and reality for delivering computing as the 5th utility. Future Generation Comput Syst 2009, 25(6):599–616. 10.1016/j.future.2008.12.001Google Scholar
  3. Schubert L, Jeffery Ke: Above the clouds: A berkeley view of cloud computing. 2012. Tech. rep., European Commission, Expert Group on Cloud Computing.Google Scholar
  4. Ict – information and communication technologies
  5. mOSAIC project
  6. Di Martino B, Petcu D, Cossu R, Gonçalves P, Máhr T, Loichate M: Building a mosaic of clouds. In Euro-Par 2010 Parallel Processing Workshops, Lecture Notes in Computer Science, vol 6586. Edited by: Guarracino MR, Vivien F, Täff JL, Cannatoro M, Danelutto M, Hast A, Perla F, Knüpfer A, Martino B, Alexander M. Springer; 2011b:571–578..–3-642–21878–1_70 10.1007/978-3-642-21878-1_70Google Scholar
  7. Malawski M, Meizner J, Bubak M, Gepner P: Component approach to computational applications on clouds. Procedia Comput Sci 2011, 4(0):432–441. 10.1016/j.procs.2011.04.045Google Scholar
  8. Petcu D, Şandru C: Towards component-based software engineering of cloud applications. In WICSA/ECSA 2012 Companion Volume. ACM; 2012:80–81.. 10.1145/2361999.2362013Google Scholar
  9. Kächele S, Domaschka J, Hauck FJ: Cosca: an easy-to-use component-based paas cloud system for common applications. In 1st International Workshop on Cloud Computing Platforms (CloudCP 2011).. ACM; 2011:4:1–4:6.. 10.1145/1967422.1967426Google Scholar
  10. Advanced message queuing protocol
  11. Amazon simple queue service
  12. Petcu D, Crăciun C, Rak M: Towards a cross platform cloud api - components for cloud federation. In 1st International Conference on Cloud Computing and Services Science (CLOSER 2011). Edited by: Leymann F, Ivanov I, van Sinderen M, Shishkov B. SciTePress; 2011c:166–169.Google Scholar
  13. Petcu D, Macariu G, Panica S, Crăciun C: Portable cloud applications—from theory to practice. Future Generation Comput Syst 2012b, 29(6):1417–1430. 10.1016/j.future.2012.01.009Google Scholar
  14. Petcu D, Panica S, Şandru C, Crăciun CD, Neagul M: Experiences in building an event-driven and deployable platform as a service. In Web Information Systems Engineering (WISE 2012), Lecture Notes in Computer Science, vol 7651. Edited by: Wang XS, Cruz I, Delis A, Huang G. Springer; 2012c:666–672.–3-642–35063–4_51 10.1007/978-3-642-35063-4_51Google Scholar
  15. Petcu D, Crăciun C, Neagul M, Lazcanotegui I, Rak M: Building an interoperability api for sky computing. In International Conference on High Performance Computing and Simulation (HPCS 2011). IEEE Computer Society Press; 2011a:405–411. Scholar
  16. Cloud Computing Use Case Discussion Group: Cloud computing use cases, version 4.0. Tech. rep. 2010. Scholar
  17. Petcu D: Identifying cloud computing usage patterns. In IEEE International Conference on Cluster Computing Workshops and Posters (Cluster Workshops 2010). IEEE Computer Society Press; 2010:1–8. Scholar
  18. Fortiş TF, Lopez GE, Cruz IP, Ferschl G, Máhr T: Cloud patterns for mosaic-enabled scientific applications. International Conference on Parallel Processing (Euro-Par 2011). Springer, Lecture Notes in Computer Science, vol 7156 2012b, 83–93.–3-642–29737–3_10 10.1007/978-3-642-29737-3_10Google Scholar
  19. Aversa R, Di Martino B, Rak M, Venticinque S: Cloud agency: A mobile agent based cloud system. In International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2010). IEEE Computer Society Press; 2010:132–137. Scholar
  20. Şandru C, Venticinque S: Agents layer to support cloud applications. In Intelligent Distributed Computing VI, Studies in Computational Intelligence, vol 446. Edited by: Fortino G, Badica C, Malgeri M, Unland R. Springer; 2013:281–286..–3-642–32524–3_35 10.1007/978-3-642-32524-3_35Google Scholar
  21. Cuomo A, Rak M, Venticinque S, Villano U: Enhancing an autonomic cloud architecture with mobile agents. International Conference on Parallel Processing (Euro-Par 2011). Springer, Lecture Notes in Computer Science, vol 7156 2012, 94–103.–3-642–29737–3_11 10.1007/978-3-642-29737-3_11Google Scholar
  22. Venticinque S, Aversa R, Di Martino B, Petcu D: Agent based cloud provisioning and management - design and prototypal implementation. In 1st International Conference on Cloud Computing & Services Science (CLOSER 2011).. Edited by: Leymann F, Ivanov I, v Sinderen M, Shishkov B. SciTePress; 2011a:184–191.Google Scholar
  23. Tasquier L, Venticinque S, Aversa R, Di Martino B: Agent based application tools for cloud provisioning and management. In 3rd International Conference on Cloud Computing (CloudComp 2012). Edited by: Yousif M, Schubert L, Jeffery K. 2012, 24–30. Scholar
  24. Venticinque S, Amato A, Di Martino B: An occi compliant interface for iaas provisioning and monitoring. In 2nd International Conference on Cloud Computing and Services Science (CLOSER 2012).. Edited by: Leymann F, Ivanov I, van Sinderen M, Shan T. SciTePress; 2012a:163–166.Google Scholar
  25. Cao BQ, Li B, Xia QM: A service-oriented qos-assured and multi-agent cloud computing architecture. In 1st International Conference on Cloud Computing (CloudCom 2009). Springer-Verlag; 2009:644–649..–3-642–10665–1_66 10.1007/978-3-642-10665-1_66Google Scholar
  26. Venticinque S, Tasquier L, Di Martino B: Agents based cloud computing interface for resource provisioning and management. In 6th International Conference on Complex, Intelligent & Software Intensive Systems (CISIS 2012). IEEE Computer Society; 2012c:249–256. Scholar
  27. Amato A, Venticinque S, Di Martino B: Evaluation and brokering of service level agreements for negotiation of cloud infrastructures. In International Conference for Internet Technology and Secured Transactions (ICITST-2012). Infonomics Society; 2012b:144–149.Google Scholar
  28. Aversa R, Tasquier L, Venticinque S: Management of cloud infrastructures through agents. In 3rd International Conference on Emerging Intelligent Data and Web Technologies (EIDWT 2012). IEEE Computer Society Press; 2012:46–53. Scholar
  29. Ficco M, Venticinque S, Di Martino B: Mosaic-based intrusion detection framework for cloud computing. In On the Move to Meaningful Internet Systems: OTM 2012. Springer-Verlag, Lecture Notes in Computer Science, vol 7566 Edited by: Meersman R, Panetto H, Dillon T, Rinderle-Ma S, Dadam P, Zhou X, Pearson S, Ferscha A, Bergamaschi S, Cruz I. 2012, 628–644..Google Scholar
  30. Amato A, Tasquier L, Copie A: Vendor agents for iaas cloud interoperability. In Intelligent Distributed Computing VI Studies in Computational Intelligence, vol 446. Edited by: Fortino G, Badica C, Malgeri M, Unland R. Springer; 2013b:271–280..–3-642–32524–3_34 10.1007/978-3-642-32524-3_34Google Scholar
  31. Şandru C, Petcu D, Munteanu V: Building an open-source platform-as-a-service with intelligent management of multiple cloud resources. In 5th IEEE/ACM Internat. Conference on Utility & Cloud Computing (UCC 2012). IEEE Computer Society; 2012:333–338. Scholar
  32. Rackspace
  33. GoGrid
  34. Flexiant
  35. CloudSigma
  36. NIIFI Cloud
  37. Arctur vCloud
  38. Hostko
  39. VMware vCloud
  40. OnApp
  41. Eucalyptus
  42. OpenNebula
  43. CloudStack
  44. OpenStack
  45. SLA@SOI project
  46. Theilmann W, Yahyapour R, Butler J: Multi-level sla management for service-oriented infrastructures. In Towards a Service-Based Internet, Springer Berlin, Lecture Notes in Computer Science, vol 5377 Edited by: Mähönen P, Pohl K, Priol T. 2008, 324–335.–3-540–89897–9_28Google Scholar
  47. Comuzzi M, Kotsokalis C, Rathfelder C, Theilmann W, Winkler U, Zacco G: A framework for multi-level sla management. In ICSOC/ServiceWave 2009 Workshops, Springer Berlin. Lecture Notes in Computer Science, vol 6275 Edited by: Dan A, Gittler F, Toumani F. 2010, 187–196.–3-642–16132–2_18Google Scholar
  48. WS-Agreement for Java framework
  49. Rak M, Aversa R, Venticinque S, Di Martino B: User centric service level management in mosaic applications. In Euro-Par 2011: Parallel Processing Workshops, Lecture Notes in Computer Science, vol 7156,. Edited by: Alexander M, D’Ambra P, Belloum A, Bosilca G, Cannataro M, Danelutto M, Di Martino B, Gerndt M, Jeannot E, Namyst R, Roman J, Scott S, Traff J, Vallée G, Weidendorfer J. Springer; 2012a:106–115.–3-642–29740–3_13 10.1007/978-3-642-29740-3_13Google Scholar
  50. Ficco M, Rak M: Intrusion tolerant approach for denial of service attacks to web services. In International Conference on Data Compression, Communications and Processing (CCP 2011).. Los Alamitos: IEEE Computer Society Press; 2011:285–292. Scholar
  51. Ficco M, Rak M: Intrusion tolerance in cloud applications: The mosaic approach. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012a:170–176. Scholar
  52. Ficco M, Rak M: Intrusion tolerance of stealth dos attacks to web services. In SEC 2012, Springer, IFIP Advances in Information and Communication Technology, vol 376 Edited by: Gritzalis D, Furnell S, Theoharidou M. 2012b, 579–584.–3-642–30436–1_52Google Scholar
  53. Rak M, Liccardo L, Aversa R: A sla-based interface for security management in cloud and grid integrations. In 7th International Conference on Information Assurance and Security (IAS 2011). IEEE Computer Society Press; 2011b:378–383. Scholar
  54. Rak M, Cuomo A, Villano U: Cloud-based concurrent simulation at work: Fast performance prediction of parallel programs. In 21st IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2012). IEEE Computer Society Press; 2012b:137–142. Scholar
  55. Rak M, Cuomo A, Villano U: Mjades: Concurrent simulation in the cloud. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). Edited by: Barolli L, Xhafa F, Vitabile S, Uehara M. IEEE Computer Society Press; 2012c:853–860. Scholar
  56. Amato A, Venticinque S: Multi-objective decision support for brokering of cloud sla. In 27th IEEE International Conference on Advanced Information Networking and Applications Workshops (WAINA 2013). IEEE Computer Society; 2013:1241–1246. Scholar
  57. Venticinque S, Negru V, Munteanu VI, Şandru C, Aversa R, Rak M: Negotiation policies for provisioning of cloud resources. In 4th International Conference on Agents and Artificial Intelligence (ICAART 2012). Edited by: Filipe J, Fred ALN. SciTePress; 2012b:347–350.Google Scholar
  58. Amato A, Liccardo L, Rak M, Venticinque S: Sla negotiation and brokering for sky computing. In 2nd International Conference on Cloud Computing and Services Science (CLOSER 2012).. Edited by: Leymann F, Ivanov I, van Sinderen M, Shan T. SciTePress; 2012a:611–620.Google Scholar
  59. Venticinque S: Agent based services for negotiation, monitoring and reconfiguration of cloud resources. In European Research Activities in Cloud Computing. Cambridge Scholars Publishing; 2012:178–202.–4438–3507–2.htmGoogle Scholar
  60. Venticinque S, Aversa R, Di Martino B, Rak M, Petcu D: A cloud agency for sla negotiation and management. In Euro-Par 2010 Parallel Processing Workshops, Lecture Notes in Computer Science, vol 6586. Edited by: Guarracino MR, Vivien F, Träff JL, Cannatoro M, Danelutto M, Hast A, Perla F, Knüpfer A, Di Martino B, Alexander M. Springer; 2011b:587–594.–3-642–21878–1_72 10.1007/978-3-642-21878-1_72Google Scholar
  61. Cretella G, Di Martino B: Towards a semantic engine for cloud applications development. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012a:198–203. Scholar
  62. Cretella G, Di Martino B: Semantic web annotation and representation of cloud apis. In 3rd International Conference on Emerging Intelligent Data and Web Technologies (EIDWT 2012). IEEE Computer Society Press; 2012:31–37. Scholar
  63. Cretella G, Di Martino B: Towards automatic analysis of cloud vendors apis for supporting cloud application portability. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012b:61–67. Scholar
  64. Di Martino B, Cretella G: Semantic and algorithmic recognition support to porting software applications to cloud. In Joint Workshop on Intelligent Methods for Software System Engineering (JIMSE 2012) Edited by: Bibi S, Moschitti A, Plank B, Stamelos I. 2012, 24–30. Scholar
  65. Amato A, Cretella G, Di Martino B, Venticinque S: Semantic and agent technologies for cloud vendor agnostic resource brokering. In 27th International Conference on Advanced Information Networking and Applications Workshops (WAINA 2013). IEEE Computer Society; 2013a:1253–1258. 10.1109/WAINA.2013.163Google Scholar
  66. Youseff L, Butrico M, Da Silva D: Toward a unified ontology of cloud computing. Grid Computing Environments Workshop (GCE 2008) 2008, 1–10. 10.1109/GCE.2008.4738443Google Scholar
  67. Moscato F, Aversa R, Di Martino B, Fortiş T, Munteanu V: An analysis of mosaic ontology for cloud resources annotation. Federated Conference on Computer Science and Information Systems (FedCSIS 2011) 2011, 973–980. Scholar
  68. Aversa R, Di Martino B, Moscato F, Petcu D, Rak M, Venticinque S: An ontology for the cloud in mosaic. In Cloud Computing: Methodology Systems, and Applications. Edited by: Wang L, Ranjan R, Chen J, Benatallah B. CRC Press; 2011b:467–486. Scholar
  69. Fortis TF, Munteanu VI, Negru V: Towards an ontology for cloud services. In 6th International Conference on Complex, Intelligent, and Software Intensive Systems (CISIS 2012). Washington: IEEE Computer Society Press; 2012:787–792. 10.1109/CISIS.2012.138Google Scholar
  70. RabbitMQ
  71. Amazon Simple Storage Service
  72. Riak
  73. Hadoop Distributed File System
  74. Petcu D, Crăciun C, Neagul M, Panica S, Di Martino B, Venticinque S, Rak M, Aversa R: Architecturing a sky computing platform. In Towards a Service-Based Internet. ServiceWave 2010 Workshops, Lecture Notes in Computer Science, vol 6569. Edited by: Cezon M, Wolfsthal Y. Springer; 2011b:1–13.–3-642–22760–8_1 10.1007/978-3-642-22760-8_1Google Scholar
  75. Petcu D: How to build a reliable mosaic of multiple cloud services. In 1st European Workshop on Dependable Cloud Computing (EWDCC 2012). ACM; 2012b:4:1–4:2. 10.1145/2365316.2365320Google Scholar
  76. CouchDB
  77. Jetty
  78. VirtualBox
  79. mOSAIC’s open-source code repository
  80. Google App Engine
  81. Windows Azure
  82. Cloud Foundry
  83. Petcu D, Frîncu ME, Crăciun C, Panica S, Neagul M, Macariu G: Towards open-source cloudware. In 4th IEEE International Conference on Utility and Cloud Computing (UCC 2011). IEEE Computer Society Press; 2011d:330–331. Scholar
  84. Cossu R, Di Giulio C, Brito F, Petcu D: Cloud computing for earth observation. In Data Intensive Storage Services for Cloud Environments, IGI Global, chap 12 Edited by: Kyriazis D, Voulodimos A, Gogouvitis S, Varvarigou T. 2013, 256–277.–1-4666–3934–8Google Scholar
  85. Panica S, Petcu D, Lazkanotegi Larrate I, Máhr T: Sky computing platform for legacy distributed application. In International Symposium on Parallel and Distributed Computing (ISPDC 2012). IEEE Computer Society Press; 2012:293–300. Scholar
  86. Ferschl G, Máhr T: Migrating a simulation framework from the cloud to the sky. In WoSS-4, CLASS Conference. Slovenia; 2012:25–27.Google Scholar
  87. Škoda P, Šperka S, Smrž P: Extracting information from scientific papers in the cloud. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012:775–780. Scholar
  88. Šperka S, Škoda P, Smrž P: Cloudification of legacy information extraction system. In WoSS-4, CLASS Conference. Slovenia; 2012:9–14. Scholar
  89. Stankovski V, König M: A sustainable building application design based on the mosaic api and platform. 8th International Conference on Semantics, Knowledge and Grid (SKG 2012) 2012, 249–252. 10.1109/SKG.2012.13Google Scholar
  90. Južna J, Češarek P, Stankovski V: Porting existing matlab applications to the cloud by using the mosaic platform. In 3rd International Conference on Parallel, Distributed, Grid and Cloud Computing for Engineering (PARENG 2013). Edited by: Topping BHV, Iványi P. Civil-Comp Press; 2013. paper 30. paper 30.Google Scholar
  91. Cretella G, Di Martino B, Stankovski V: Using the mosaic’s semantic engine to design and develop civil engineering cloud applications. In 14th International Conference on Information Integration and Web-based Applications & Services (iiWAS2012). Edited by: Taniar D, Pardede E, Steinbauer M, Khalil I. ACM; 2012:378–386. Scholar
  92. Rak M, Aversano G: Benchmarks in the cloud: The mosaic benchmarking framework. In 14th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC 2012). IEEE Computer Society; 2012:415–422. Scholar
  93. Cuomo A, Rak M, Villano U: Simulation-based performance evaluation of cloud applications. In Intelligent Distributed Computing VI Studies in Computational Intelligence, vol 446. Edited by: Fortino G, Badica C, Malgeri M, Unland R. Springer; 2013b:263–269.–3-642–32524–3_33 10.1007/978-3-642-32524-3_33Google Scholar
  94. Petcu D: Cloudware support for scientific applications. In RO-LCG 2012. Romania: IEEE; 2012a:70–73.Google Scholar
  95. Petcu D, Panica S, Neagul M: From grid computing towards sky computing. case study for earth observation. In 10th Cracow Grid Workshop (CGW 2010). Poland: Academic Computer Center; 2010:11–20.Google Scholar
  96. Panica S, Neagul M, Crăciun C, Petcu D: Serving legacy distributed applications by a self-configuring cloud processing platform. In 6th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems (IDAACS 2011), vol 1. IEEE Computer Society Press; 2011:139–144. Scholar
  97. Stankovski V, Južna J, Petcu D: Enabling legacy engineering applications for cloud computing: Experience with the mosaic api and platform. In 3rd International Conference on Emerging Intelligent Data and Web Technologies (EIDWT 2012). IEEE Computer Society Press; 2012:281–286. Scholar
  98. Rak M, Ficco M, Luna J, Ghani H, Suri N, Panica S, Petcu D: Security issues in cloud federation. In Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice. Edited by: Villari M, Brandic I, Tusa F. IGI Global; 2012d:176–194.–1-4666–1631–8.ch010Google Scholar
  99. Casola V, Cuomo A, Rak M, Villano U: The cloudgrid approach: Security analysis and performance evaluation. Future Generation Comput Syst 2013, 29(1):387–401. 10.1016/j.future.2011.08.008Google Scholar
  100. Casola V, Cuomo A, Villano U, Rak M: Access control in federated clouds: The cloudgrid case study. In Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice. Edited by: Villari M, Brandic I, Tusa F. IGI Global; 2012:395–417.–1-4666–1631–8.ch020 10.4018/978-1-4666-1631-8.ch020Google Scholar
  101. SPECS project
  102. Rak M, Ficco M: Intrusion tolerance as a service - a sla-based solution. In 2nd International Conference on Cloud Computing and Services Science (CLOSER 2012). Edited by: Leymann F, Ivanov I, van Sinderen M, Shan T. SciTePress; 2012:375–384.Google Scholar
  103. Rak M, Liccardo L, Aversa R: A sla-based interface for secure authentication negotiation in cloud. J Inf Assur Secur 2012e, 7(2):137–146. Scholar
  104. Bennett T, Stephen an Erl, Gee C, Laird R, Manes AT, Schneider R, Shuster L, Tost A, Venable C: SOA Governance: Governing Shared Services On-Premise & in the Cloud. Prentice Hall/Pearson PTR; 2011.Google Scholar
  105. Munteanu VI, Fortiş T F, Negru V: An event driven multi-agent architecture for enabling cloud governance. 2012b. Scholar
  106. Fortiş T, Munteanu V, Negru V: Steps towards cloud governance. a survey. 34th Internat. Conference on Information Technology Interfaces (ITI 2012) 2012a, 29–34. Scholar
  107. Copie A, Fortis TF, Munteanu VI, Negru V: Datastores supporting services lifecycle in the framework of cloud governance. Scalable Comput: Pract Exp 2012b, 13(3):251–267. Scholar
  108. Munteanu VI, Fortiş TF, Copie A: Building a cloud governance bus. Int J Comput Commun Control 2012a, 7(5):900–906. Scholar
  109. Copie A, Fortis T, Munteanu V, Negru V: Service datastores in cloud governance. In 10th IEEE International Symposium on Parallel and Distributed Processing with Applications (ISPA 2012). IEEE Computer Society Press; 2012a:473–478. Scholar
  110. Copie A, Fortis TF, Munteanu VI: Datastores in cloud governance. Int J Comput Commun Control 2013b, 8(1):42–49. Scholar
  111. Copie A, Fortis TF, Munteanu VI: Data security perspectives in the framework of cloud governance. In EuroPar 2012 Workshops – BDMC 2012, no. 7640 in Lecture Notes in Computer Science. Springer; 2013a:24–33.–3-642–36949–0_4Google Scholar
  112. Bernstein D, Vij D, Diamond S: An intercloud cloud computing economy - technology, governance, and market blueprints. Annual SRII Global Conference (SRII 2011) 2011, 293–299. 10.1109/SRII.2011.40Google Scholar
  113. Fortiş TF, Munteanu VI, Negru V: Towards a service friendly cloud ecosystem. In 11th International Symposium on Parallel and Distributed Computing (ISPDC 2012). IEEE Computer Society Press; 2012c:172–179. Scholar
  114. Frîncu ME: Scheduling service oriented workflows inside clouds using an adaptive agent based approach. In Handbook of Cloud Computing. Edited by: Furht B, Escalante A. Springer; 2010:159–182.–1-4419–6524–0_7 10.1007/978-1-4419-6524-0_7Google Scholar
  115. Frîncu ME, Villegas NM, Petcu D, Muller HA, Rouvoy R: Self-healing distributed scheduling platform. In 11th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid 2011). IEEE Computer Society Press; 2011:225–234. 10.1109/CCGrid.2011.23Google Scholar
  116. Frîncu ME: Scheduling highly available applications on cloud environments. Future Generation Comput Syst 2012., 29: 10.1016/j.future.2012.05.017Google Scholar
  117. Frîncu ME, Crăciun C: Multi-objective meta-heuristics for scheduling applications with high availability requirements and cost constraints in multi-cloud environments. In 4th IEEE International Conference on Utility and Cloud Computing (UCC 2011). IEEE Computer Society Press; 2011:267–274. 10.1109/UCC.2011.43Google Scholar
  118. Di Martino B, Aversa R, Venticinque S, Buonanno L: Competitive p2p scheduling of users’ jobs in cloud. In 2nd Internat. Conference on Cloud Computing, Grids, & Virtualization (Cloud Computing 2011). IARIA; 2011a:105–112. Scholar
  119. Rak M, Venticinque S, Máhr T, Echevarria G, Esnal G: Cloud application monitoring: The mosaic approach. In 3rd IEEE International Conference on Cloud Computing Technology and Science (CloudCom 2011). IEEE Computer Society Press; 2011c:758–763. Scholar
  120. Stankovski V, Petcu D: Developing a model driven approach for engineering applications based on mosaic. Cluster Computing. 2013. Scholar
  121. Moscato F, Di Martino B, Aversa R: Enabling model driven engineering of cloud services by using mosaic ontology. Scalable Comput: Pract Exp 2012b, 13(1):29–47. Scholar
  122. Moscato F, Aversa R, Amato A: Describing cloud use case in metamorp(h)osy. In 6th International Conference on Complex, Intelligent, and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012a:793–798. 10.1109/CISIS.2012.143Google Scholar
  123. Cloud@Home project
  124. Amicas project
  125. Aversa R, Bruneo D, Cuomo A, Martino B, Distefano S, Puliafito A, Rak M, Venticinque S, Villano U: Cloud@home: Performance management components. In Euro-Par 2010 Parallel Processing Workshops, Lecture Notes in Computer Science, vol 6586. Edited by: Guarracino M, Vivien F, Träff J, Cannatoro M, Danelutto M, Hast A, Perla F, Knüpfer A, Di Martino B, Alexander M. Springer; 2011a:579–586.–3-642–21878–1_71 10.1007/978-3-642-21878-1_71Google Scholar
  126. Distefano S, Puliafito A, Rak M, Venticinque S, Villano U, Cuomo A, Di Modica G, Tomarchio O: Qos management in cloud@home infrastructures. In International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC 2011). IEEE Computer Society Press; 2011:190–197. Scholar
  127. Cuomo A, Di Modica G, Distefano S, Puliafito A, Rak M, Tomarchio O, Venticinque S, Villano U: An sla-based broker for cloud infrastructures. J Grid Comput 2013a, 11: 1–25.–012–9241–4 10.1007/s10723-012-9241-4Google Scholar
  128. Rak M, Cuomo A, Villano U: Chase: An autonomic service engine for cloud environments. In 20th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE 2011). IEEE Computer Society Press; 2011a:116–121. Scholar
  129. Petcu D: Towards programmable infrastructures: the steps made by cloud computing and their technical support. In WoSS-4, CLASS Conference. Slovenia; 2012e:19–21. Scholar
  130. Petcu D, Frîncu ME, Panica S, Neagul M: Towards programmatic management of services from multiple clouds. In 4th International Conference on Intelligent Networking and Collaborative Systems (INCoS 2012). IEEE Computer Society Press; 2012a:487–488. Scholar
  131. Calcavecchia NM, Căprărescu BA, Di Nitto E, Dubois DJ, Petcu D: Depas: A decentralized probabilistic algorithm for auto-scaling. Computing 2012, 94: 701–730.–012–0198–8 10.1007/s00607-012-0198-8Google Scholar
  132. Căprărescu BA, Petcu D: Decentralized probabilistic auto-scaling for heterogeneous systems. 4th International Conference on Adaptive and Self-Adaptive Systems and Applications (Adaptive 2012) 2012, 7–12. Scholar
  133. Căprărescu BA, Kaslik E, Petcu D: Theoretical analysis and tuning of decentralized probabilistic auto-scaling. 2012. CoRR abs/1202.2981,Google Scholar
  134. MODAClouds project
  135. Ardagna D, di Nitto E, Mohagheghi P, Mosser S, Ballagny C, D’Andria F, Casale G, Matthews P, Nechifor CS, Petcu D, Gericke A, Sheridan C: Modaclouds: A model-driven approach for the design and execution of applications on multiple clouds. ICSE Workshop on Modeling in Software Engineering (MISE 2012) 2012, 50–56. 10.1109/MISE.2012.6226014Google Scholar
  136. Helix Nebula project
  137. Aversa R, Di Martino B, Rak M, Venticinque S, Villano U: Performance prediction for hpc on clouds. In Cloud Computing. John Wiley & Sons, Inc; 2011c:437–456. 10.1002/9780470940105.ch17Google Scholar
  138. HOST project
  139. Research potential of convergence regions
  140. Drozdowicz M, Wasielewska K, Ganzha M, Paprzycki M, Attaoui N, Lirkov I, Olejnik R, Petcu D, Bădică C: Ontology for contract negotiations in an agent-based grid resource management system. In Trends in Parallel, Distributed, Grid and Cloud Computing for Engineering. Edited by: Iványi P, Topping BHV. Saxe-Coburg Publications; 2011:335–354.. Scholar
  141. Wasielewska K, Ganzha M, Paprzycki M, Drozdowicz M, Petcu D, Badica C, Attaoui N, Lirkov I, Olejnik R: Negotiations in an agent-based grid resource brokering system. In Trends in Parallel, Distributed, Grid and Cloud Computing for Engineering. Edited by: Iványi P, Topping BHV. Saxe-Coburg Publications; 2011:355–374.. Scholar
  142. Šperka S, Smrž P: Towards adaptive and semantic database model for rdf data stores. In 6th International Conference on Complex, Intelligent and Software Intensive Systems (CISIS 2012). IEEE Computer Society Press; 2012:810–815. Scholar
  143. Olaii
  144. SEED project
  145. Competitiveness and Innovation Framework Programme
  146. Petcu D: Portability and interoperability between clouds: Challenges and case study. In Towards a Service-Based Internet, Lecture Notes in Computer Science, vol 6994. Edited by: Abramowicz W, Llorente IM, Surridge M, Zisman A, Vayssière J. Springer; 2011:62–74.–3-642–24755–2_6 10.1007/978-3-642-24755-2_6Google Scholar
  147. Jclouds
  148. Libcloud
  149. OCCI
  150. Deltacloud
  151. Open Virtualization Format
  152. Cloud Data Management Interface
  153. Cloud Infrastructure Management Interface – Common Information Model
  154. Unified Cloud Interface Project
  155. CloudML
  156. Hogan M, Liu F, Sokol A, Tong J: Nist cloud computing standards roadmap-version 1.0. Tech. rep. 2011. NIST Special Publication 500–291.Google Scholar
  157. Ferrer AJ, Hernández F, Tordsson J, Elmroth E, Ali-Eldin A, Zsigri C, Sirvent R, Guitart J, Badia RM, Djemame K, Ziegler W, Dimitrakos T, Nair SK, Kousiouris G, Konstanteli K, Varvarigou T, Hudzia B, Kipp A, Wesner S, Corrales M, Forgó N, Sharif T, Sheridan C: Optimis: A holistic approach to cloud service provisioning. Future Generation Comput Syst 2012, 28(1):66–77. 10.1016/j.future.2011.05.022Google Scholar
  158. Grozev N, Buyya R: Inter-cloud architectures and application brokering: Taxonomy and survey. Softw Pract Exp 2012. 10.1002/spe.2168Google Scholar
  159. Simple Cloud API
  160. SAGA – a simple api for grid applications
  161. RightScale
  162. Enstratius
  163. Kaavo
  164. Aeolus
  165. OPTIMIS Toolkit v2
  166. Petcu D: A panorama of cloud services. Scalable Computing: Pract Exp 2012d, 13(4):303–314.Google Scholar
  167. SpotCloud
  168. WSO2 Stratos
  169. Petcu D, Stankovski V: Towards cloud-enabled business process management based on patterns, rules and multiple models. In 10th IEEE Internat. Symposium on Parallel & Distributed Processing with Applications (ISPA 2012). IEEE Computer Society; 2012:454–459. Scholar
  170. Heroku
  171. Crăciun CD: Building Blocks of Scalable Applications. 2012. Master’s thesis, West University of Timişoara, Computer Science Department.Google Scholar
  172. Petcu D, Rak M: Open-source cloudware support for the portability of applications using cloud infrastructure services. In Cloud Computing: Methods and Practical Approaches, Computer Communications and Networks. Edited by: Mahmood Z. Springer, chap 15; 2013:323–341.–1-4471–5107–4_15Google Scholar
  173. Contrail project
  174. OpenShift
  175. Petcu D: Invitation to a journey in the era of cloud computing. In European Research Activities in Cloud Computing. Cambridge Scholars Publishing; 2012c:1–20.–1-4438–3507–7-sample.pdfGoogle Scholar
  176. Petcu D, Vasquez-Poletti JL: European Research on Cloud Computing. Cambridge: Cambridge Scholars Publishing; 2012.Google Scholar
  177. Bessani A, Kapitza R, Petcu D, Romano P, Gogouvitis SV, Kyriazis D, Cascella RG: A look to the old-world sky: Eu-funded dependability cloud computing research. SIGOPS Oper Syst Rev 2012, 46(2):43–56. 10.1145/2331576.2331584Google Scholar
  178. 4CaaSt project
  179. Cloud4SOA project
  180. Cloud-TM pproject
  181. REMICS project
  182. TClouds project
  183. VISION Cloud project


© Petcu et al.; licensee Springer. 2013

This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.