mOSAIC is a 30-month European project developing an open-source API and platform for multiple clouds. The project aims to address challenges of data and application portability and interoperability across clouds. Key features of the mOSAIC platform include a vendor-agnostic API, cloud resource and service brokering capabilities, SLA negotiations and monitoring, and a cloud ontology. The platform is being developed to enable applications to dynamically negotiate cloud services from multiple providers based on their requirements.

1. mOSAIC: Open-Source API and
Platform for Multiple Clouds
CloudCamp – TechnologyBiz – 9 Novembre 2011
Beniamino Di Martino
Project Coordinator – Second University of Naples

2. mOSAIC main facts
• Project acronym: mOSAIC
• Project full title: Open-Source API and
Platform for Multiple Clouds
• Grant agreement no: 256910
• Funding Scheme: STREP
• Call: FP7-ICT-2009-5 Obj: ICT-2009.1.2
• Cost: 3,705 Meur (EC financing: 2,85 M)
• Duration: 30 months
• Start: Sept 1st 2010. End: Feb 28th 2013
• Web site: http://www.mosaic-cloud.eu

3. mOSAIC Partners
Second University of Naples – It (Prj Coordinator)
Institute IeAT – Ro
European Space Agency - Fr
AITIA - Hu
Tecnalia - Sp
Terradue - It
XLAB - Slo
University of Lubljiana - Slo
Brno University of Technology - Ck

4. The Cloud Computing Challenges
In literature main challenges are identified:
• data and application interoperability
• data and application portability
• governance and management,
• metering and monitoring,
• security.
mOSAIC will fully address the first two of these
challenges, and partially address the next two
ones.

5. Portability and Interoperability
Avoiding “Cloud Vendors Lock-in”
and “Walled Gardens”
Allow Interoperability among
Clouds and Cloud Providers at API
spec
Service and Application level
API
spec
010
110
01
API
spec

6. How we develop a Cloud-based application?
High level
Google App Engine
Microsoft Azure Service Platform [or wait for Orleans]
Manjrasoft Aneka
Amazon Web Services
Low level
APIs offered by IaaS Cloud service providers
to create and manage cloud resources, including compute,
storage, and networking components
e.g. Amazon EC2, Eucalyptus, Oracle (Sun) Cloud, ElasticHosts,
FlexiScale, GoGrid, Enomaly, OpenNebula, SliceHost, Nimbus,
AppNexus, F5, Tashi, CohesiveFT, Mosso, Joyent ……
So many! So different! This are the right APIs for the Cloud
appls?

7. Towards the usage of multiple Clouds
Portability
At high level? NO!
At low level? Ongoing task!
OCCI – January 2010
UniCluster, OpenStack, Jcloud, DeltaCloud … from Spring
2010
Approaches:
At IaaS level:
Migration of VMs between Cloud providers (e.g. Reservoir)
Agreements between Cloud providers
Communications between Clouds
At PaaS level:
Use services from different Clouds

8. Federation of Clouds vs Using multiple
Clouds
Federation On-demand
of Clouds: Multiple Cloud:
01011
Horizontal 01011 Cross-Cloud
001
or 001 or
? InterClouds ? Sky computing
01
011 01
011 01011
001
01 01 01
011 011 011
001
01011
01
011

9. mOSAIC Approach
The mOSAIC project aims to develop an open-
source platform that enables applications to
negotiate Cloud services as requested by their
users.
Using the Cloud ontology, applications will be able
to specify their requirements and communicate
them to the platform via the innovative API.
The platform will implement a multi-agent
brokering mechanism that will search for
services matching the applications‟ request, and
possibly compose the requested service if no
direct hit is found.

10. mOSAIC Approach
Cloud-application developers and maintainers will
be able to postpone their decision on the
procurement of Cloud services until runtime,
while end-user applications will be able to find
best-fitting Cloud services to their actual needs
and efficiently outsource computations.
The platform will facilitate competition and
cooperation among Cloud providers, who, in
return, will be able to reach customers they
could not reach before.

11. mOSAIC Key features and technologies
Vendor agnostic API Component-based
Open source PaaS applications
Cloud resources and Multiple Clouds
services brokering Long time running
Cloud Agency applications
SLA negotiations and Event driven, asynchronous
monitoring
Cloud Ontology
Semantic Engine

12. mOSAIC goals
An API
Cloud-based language- and platform-independent API
Extends the existing language- or platform-dependent API
capabilities with composite features based on patterns
A framework
Semantic engine
Cloud ontology & Semantic representation of Cloud resources
Applications‟s needs in terms of SLAs and QoS requirements
Cloud agency
An open-source platform
a proof-of-the-concept prototype ready to be tested, exploited or
extended by its users
include instances of the APIs for two programming languages
and application tools
Proofs of validity through the use cases and applications

13. mOSAIC goals
API at high level independent from the provider
With implementation in high level languages
Common representations of resources
Cloud taxonomy and ontology
Powerful platform allowing dynamicity and
Identification of appl‟s requirements in terms of resources
(Re)Negotiation of the offers from different providers
Monitoring and benchmarking
Connectors to different services based on a common
understanding

14. mOSAIC milestones
September 2011: 1st implementation of API
Cloud ontology
September 2012: Platform available
March 2013: Full software package

15. mOSAIC: A Global View
VM
mOSAIC Cloud
Platform Provider
mOSAIC-Based
Application
Users data
Cloud
Provider
mOSAIC VM
API
mOSAIC Cloud
Framework dataProvider
Developers

16. mOSAIC: A Global View
VM
mOSAIC Cloud
Platform Provider
mOSAIC-Based
Application
Users data
Cloud
Users Sees only the Provider
Final Applicantion mOSAIC VM
API
They does not know mOSAIC Cloud
anything (as less as Framework dataProvider
possible) about the
Cloud
Developers

17. mOSAIC: A Global View
Cloud Provider are VM
Resource owners.
mOSAIC Cloud
Platform Provider
mOSAIC-Based They are involved for
Application everything related to
acquiring resources.
Users data
They are accessed
Cloud
trough mOSAIC, as less
Provider
as possible dependence
between Provider and
mOSAIC VM
developer.
API
mOSAIC Cloud
Framework dataProvider
Only Framework knows
about CP
Developers

18. mOSAIC: A Global View
VM
mOSAIC Cloud
Platform Provider
mOSAIC-Based
Application
Users data
Cloud
Provider
VM
mOSAIC Cloud
API mOSAIC
Framework dataProvider
Developers

19. Platform Components

20. Current ongoing relevant tasks
 T2.3 → Semantic engine
 T1.2 → Cloud Ontology  Semantic query
 T1.3 → API design  Service discovery
 APIs description  Matchmaking
 T2.2 → API implementation
 T2.5 → Provider Agent
 T1.4 → Cloud agency
 Agent protocols  Resources
 Cloud request  Services
 T1.5 → SLA agreement and  Offer
Qos
 T2.6 → Negotiator module
 Resource/services
 Cloud Provider  T3.1 → Cloud usage
patterns
 Performance figures (QoS
parameters)  Patterns description
 T3.2 → Platform Use cases

21. Progress so far
Finalized deliverables (at Y1)
• API design
• API first prototype implementation - in Java
• Cloud Ontology
• Cloud Usage patterns
Work in progress
• Semantic Engine
• Cloud Agency
• SLA management and monitoring
• mOSAIC Applications development/porting

22. mOSAIC API
Concepts:
in public D1.3/Sept 2011 & papers
Implementations:
In Java, available at:
http://www.mosaic-cloud.eu -> <For Developers> box
https://bitbucket.org/mosaic/
Guide in mosaic-api / mosaic-mvn / doc
In Python, in February 2012

23. mOSAIC API Architecture
mOSAIC API Layers
Lowest Layer: Native resource protocol} (Web service, RPC, etc.), or a
native resource API provided as a library by the vendor for a certain
programming language. No uniformity.
Driver API: Wraps the native API, providing the first level of uniformity: all
resources of the same type are exported with the same interface. Thus
exchanging, for example, an Amazon S3 with a Riak key-value store is just a
matter of configuration.
Connector API: depending on the programming language, provides
abstractions for the cloud resources, suitable for the programming paradigm.
This is where we provide the second kind of uniformity for the programming
paradigms, as all the implementations of the connector API in object oriented
programming languages will have similar class hierarchies, method
signatures, or patterns.
Cloudlet API: Even thought the developer already can access cloud
resources, he or she must restrict himself or herself to a cloud compliant
programming methodology, which we provide (integrated with all the layers
already mentioned) that we call Cloudlet, as similar with the existing Java
Servlet technology that provides standard programming components in J2EE
environments.

24. mOSAIC API‟s Layers
Component
Component
Component Component
Component Application components
Cloudlet API Cloudlet API Support for components
Connector API Connector API For different languages
Interoperability API Reference API
Driver Driver For same service type
API API API API

25. mOSAIC Cloud Ontology
 Provides a unified description of
 Cloud components
 Interfaces
 API
 Requirements
 SLA
 …
 Enables
 Reasoning
 Semantics-based queries executions
 Brokering
 Discovery
 Matchmaking
 Cloud Services Composition

26. mOSAIC Ontology: Top Level

27. mOSAIC Ontology: Top Level and
Standards/Proposals
NIST

28. mOSAIC Ontology: Top Level and
Standards/Proposals
OCCI

29. mOSAIC Ontology: Top Level and
Standards/Proposals
SLA@SOI

30. mOSAIC Ontology: Top Level and
Standards/Proposals
IBM/Oracle
Azure/ Google

31. mOSAIC Semantic Engine
Cloud Ontology
Developer‟s
requests:
•Functional
•Non-Functional
(e.g. resources,
SL requests)
Provider
Agents
Create: Reasoning and matchmaking
new Agent(bindings)
Looks for semantic
descriptions of
APIs APIs
{ CPU, descriptions
EC2 Understands
compliant, resource type and
bindings interface
}

32. mOSAIC Cloud Agency
 The mOSAIC Cloud agency will be
conceived according a service-oriented
architecture, where agents will implement
stateful, eventually mobile, services
Negotiation, monitoring, dynamic
benchmarking and reconfiguration of
cloud resources are some mandatory
services to be implemented
Why agents?

33. Cloud Agency
Architecture

34. SLA and QoS monitoring and management
 QoS parameters
 Negotiation
 SLA Agreement
 Monitoring
 Re-negotiation
T1.2 Ontology
T1.4 Cloud Agency
T2.5 Provider
T2.6 Negotiator

35. mOSAIC Use cases
Existing use cases
OCCI use cases with IaaS API requirements
Cloud Computing Use Case Discussion Group
Provider‟s use cases
Research use casse
mOSAIC‟s use cases
Type Title
Data intensive Storage and data distribution in Earth Observation
Earth Observation mission reprocessing
Routine production of Earth Observation products
Fast data access for crisis situations
Distributed intelligent maintenance
Compute Cloud-distributed parameter sweep

36. More details in papers:
API layers: Towards a cross-platform Cloud API, CLOSER 2011,
SciTePress.
API interop: Building an Interoperability API for Sky Computing,
InterCloud/HPCS, IEEE CS
Cloud ontology: An Ontology for the Cloud in mOSAIC Cloud. In Cloud
computing: methodology, system, and applications. CRC, Taylor &
Francis group, 2011
An Analysis of mOSAIC ontology for Cloud Resources annotation,
Proceedings of the Federated Conference on Computer Science and
Information Systems pp. 983–990, 2011.
Platform services: Arhitecturing a Sky Computing Platform, ServiceWave
2010, LNCS 6569
Cloud agency: Agent based Cloud provisioning and management, CLOSER
2011, SciTePress.
SLA manag: A Cloud Agency for SLA Negotiation and Management,
EuroPar „10, LNCS 6586
Use case: From Grid To Sky Computing. Case Study for Earth Observation,
10th CGW 2010,
Patterns: Identifying Cloud Computing Usage Patterns, IEEE Cluster 2010,
Test appls: Building a Mosaic of Clouds, EuroPar 2010, Springer, LNCS
6586