MINISTRY OF EDUCATION AND TRAINING
HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY

HUYNH HOANG LONG

RESEARCHING MULTI-CLOUD MARKETPLACE
MODEL

Major: Information Systems
Code: 9480104

THE SUMMARY OF INFORMATION SYSTEM DISSERTATION

Hanoi - 2022


The doctoral dissertation was completed at:
Hanoi University of Science and Technology

Supervisors:
1. Ph.D. NGUYEN HUU DUC
2. Assoc.Prof. LE TRONG VINH

Reviewer 1:
Reviewer 2:
Reviewer 3:

The Dissertation was approved by Ph.D Thesis Evaluation
Board at Hanoi University of Technology.

……..….., day ….. month ….. year ………

The Dissertation is available at:

2


1. Ta Quang Buu Library-Hanoi University of Science and
Technology
2. National Library of Vietnam

LIST OF PUBLICATIONS
1. Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, and
Duc-Hung Le, “Towards the cloud marketplace for Multicloud infrastructures”, In Proceedings of the 18th Vietnam
National Conference: Selected issues of information
technology and communication, pp. 100-105, Ho Chi Minh,
November 2015 (In Vietnamese).
2. Hoang-Long Huynh, Van-Dang Tran, Huu-Duc Nguyen,
Zhenjiang Hu, Trong-Vinh Le, Quyet-Thang Huynh, “Autoupdating Portable Application Model of Multi-cloud
Marketplace through Bidirectional Transformations System”,
In Proceedings of the International Conference on Intelligent
Software Methodologies, Tools, and Techniques (SOMET
2019),
pp.
11-24,
Malaysia,
September
2019.
Doi:10.3233/FAIA190035. (SCOPUS Indexed)
3. Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le,
“Matchmaking for Multi-cloud Marketplace Application”,

Journal of Research and Development on Information and
Communication Technology, Ministry of Information and
Communications,
Vietnam, Vol 2019(1), pp. 31-42,
September 2019. ISSN1859-3534. DOI:10.32913/MIC-ICTRESEARCH.V2019.N1.854.
4. Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le, ThiNhan Vu, Quyet-Thang Huynh, “An approach for autorepairing cloud application on Multi-cloud Marketplace”, In
Proceedings of the 22th Vietnam National Conference:

3


Selected
issues
of
information
technology
and
communication, pp. 17-22, Thai Binh, June 2019.
5. Hoang-Long Huynh, Huu-Duc Nguyen, Trong-Vinh Le,
Quyet-Thang Huynh, “CAM-D: A description method for
Multi-cloud Marketplace Application”, Journal of Research
and Development on Information and Communication
Technology, Ministry of Information and Communications,
Vietnam, Vol 2020(2), pp. 51-61, December 2020. ISSN
1859-3534.
DOI:10.32913/MIC-ICTRESEARCH.V2020.V2.943.

4



Chapter 1: Introduction
1.1. Context
In general, most SaaS are closely tied to the technical
infrastructure of their owners. This leads to the problem of tying
consumers and application developers into the separate
infrastructures of cloud ecosystems. This is the cause of vendor
lock-in problem in cloud computing, which is characterized by
expensive and time-consuming migration of application and data to
alternative providers. Cloud vendors lock customers in several
ways: (i) by designing a system incompatible with software
developed by other vendors; (ii) by using proprietary standards or
private architectures that lack interoperability with other
applications; (iii) by licensing the software under exclusive
conditions. Thus, vendor lock-in deters organizations adopting
cloud technology. In our view, it is possible to evolve cloud
marketplace model and multi-cloud application model to reduce
vendor lock-in if efficiently leveraging the outstanding advantages
of the multi-cloud environment.

1.2. Thesis research issues
Most cloud providers have been building proprietary SaaS
platforms where their applications are hosted in a SaaS business
model and establishing a series of restrictions for their cloud
platforms. Hence, these proprietary platforms prevent that
applications offered by different SaaS application vendors cannot
easily host on the platforms offered by others and the cloud
software is developed with their tools will be coupled to the
libraries and services provided by each cloud provider. This open

5



up the well-known issue: vendor lock-in. As a result, cloud
developers are often locked into specific technological ecosystems.
The main goal of our studies is to develop a new multi-cloud
marketplace model which has a special mechanism to reduce
vendor lock-in and a component-based cloud application model by
which a cloud application is made up from independent
components and spread across various clouds. To achieve this goal,
we must overcome several issues as follows: Multi-cloud
marketplace model, Multi-cloud application model, Matchmaking
method of multi-cloud marketplace application, Multi-cloud
application portability, Method for auto-repairing multi-cloud
application, Service Level Agreement, Cloud application
scalability, Security, etc.

1.3. Thesis contributions
Our main contributions are are described as follows:
1. Proposing O-Marketplace Model, a new multi-cloud
marketplace model.
2. Presenting Composable Application Model, a new
cloud application model for multi-cloud marketplace.
Beside key models mentioned above, some issues have to be
solved to prove the practicality of O-Marketplace Model and
Composable Application Model as follows:
• Matchmaking method, presenting an advantageous method
for matching cloud software components to a cloud
platform group in the context of O-Marketplace.
• Multi-cloud application portability, presenting an approach
for multi-cloud application portability and building up a

Bidirectional Transformations System to auto-update cloud
application modeled by CAM.

6


• Multi-cloud application auto-repairing, introducing an
approach for auto-repairing cloud application in the context
of O-Marketplace.
Chapter 2 introduces related technologies and related works.
The cores of thesis are Chapter 3,4. Chapter 5 is Conclusion.

7


hapter 3. O-Marketplace
3.1. Introduction
Almost cloud providers currently have their own marketplace
such as Amazon,IBM,Google,etc., whereby cloud services are
only allowed to operate on their own infrastructures. The singlevendor dependence has been binding both consumers and
developers to the technology ecosystems of particular cloud
providers. This is the cause of vendor lock-in
In another aspect, Multi-cloud environments use a mix of cloud
offerings, sharingthe workloads between them with cloud
application could be spread across differentservice providers. The
multi-cloud approach is very effective for reducing the vendor
lock-in. To leverage the advantages of multi-cloud environment for
reducing vendor lock-in and creating a free environment for cloud
developers, we propose a new cloud marketplace model, called OMarketplace. It is an independent entity from cloud providers and
operated by a third party. O-Marketplace is not only as a

brokerage center, but also integrates individually developed cloud
software components on different cloud platforms to create a
complete cloud software. So this function facilitates consumers to
use multi-cloud applications.

3.2. O-Marketplace Model
3.2.1. The proposed cloud service delivery
method for multi-cloud marketplace
To overcome these restrictions from existing methods of cloud
service delivery of cloud marketplace and to leverage the

8


advantages of multi-cloud environment, we propose the method of
cloud service delivery for multi-cloud marketplace.
The main differences of proposed method are as follows:
• Cloud service information is transparent (Features, Price,
QoS,. . . ).
• Creating a competitive environment that promote cloud
providers have to develop their services to serve the cloud
software independently developed by developers.
• Reducing vendor lock-in and increasing value-added
consumers and developers.
• Providing multi-cloud application and supporting
consumers to deploy and manage the multi-cloud
application.

3.2.2. Overall structure of O-Marketplace
Relying on the proposed cloud service delivery method for multicloud marketplace. We build up O-Marketplace Model, which is a

multi-cloud marketplace model. O-Marketplace provides to customers
a catalogue of cloud software and cloud resource services bundles
with detailed information about functions, prices, etc. of cloud
services provided by cloud providers and cloud software
vendors/developers.
Especially, the novelty of O-Marketplace is to provide cloud
application that can be distributed across various clouds. Therefore,
with just one application, customers can consume various cloud
services provided by different providers. Moreover, OMarketplace
lead to create an open market that facilitate developers and cloud
providers to sell their products flexibly. This is extremely significant
for developers who do not own cloud infrastructure.

9


To express this idea, we sketch O-Marketplace model which has
five main building block depicted in Figure 3.6 as follows:
(i). Graphical User Interface is a portal that facilitate for
consumers to approach cloud application. It is a catalogue of
cloud services, cloud software and cloud software components
provided by the third parties such as cloud application vendors,
developers, and cloud providers.
(ii). O-Marketplace Repository contains cloud software (artifacts,
software component specifications, software composition
specifications) and cloud platform services (IaaS specifications
and PaaS specifications).
(iii). O-Marketplace Electronic Commerce Platform has the
main functions inherited from the electronic marketplace model.
(iv). O-Marketplace Runtime Platform includes some main

functionalities such as Description, Deployment, Configuration,
Migration, Monitoring.
Especially, O-Marketplace aims to the significant difference
compared to the current cloud marketplace models in particular and
other cloud service delivery models in general as follows:
• Providing the component-based cloud application. Cloud
software and cloud resources are provided separately. A cloud
software is a combination of application components which
can be developed independently and consume various
underlying cloud platform services.
• Supporting developers to develop individual cloud software
components in depth that can host on various cloud platforms.

10


Figure 3.6: O-Marketplace Model.
This novelty in SaaS provisioning is the basis for direct
competition mechanism. Especially, the separation allows cloud
application avoiding vendor lock-in problem.

3.2.3. The operation mechanism of O-Marketplace
There are four actors involved in the O-Marketplace model as
follows:
consumer,
cloud
provider,
cloud
software
vendor/developer and O-Marketplace Administrator as an

intermediary. The activities of actors have a close relationship with
each other in the transaction process. In which, O-Marketplace is a
brokerage center, providing the best brokerage method to supply
cloud applications to consumers.

3.3. The goals of O-Marketplace Model
O-Marketplace model aims to distinct outstanding advantages
described as follows:
• Creating a direct competition, bringing the most benefit and
convenient way to customers.

11


• Towards a diverse cloud application market where developer is
the pilot of cloud application development. Cloud software
products are independently developed and are no longer tied to
cloud service providers.
• There is no outdated solution because cloud software are
always adopted by the developer community.
• A cloud application is a combination of intensive capabilities
from orders. So promoting cooperation among parties in cloud
application development. Consumer could can pick the best
services from each provider to build his app.
• Consumers are completely proactive in the service fees they
have to pay.
To sum up, O-Marketplace is not only a vendor-neutral
ecosystem which focus on reducing vendor lock-in, but also is an
attractive business ecosystem that support facilities, promote and
monetize cloud applications as well as create an active community

for cloud consumers, cloud providers and developers.

12


Chapter 4: Composable Application
Model
4.1. Introduction
In our view, cloud application should be designed in a fashion
that it consume various types of resource offered by cloud
providers. We propose Composable Application Model (CAM), a
component-based cloud application model in which the cloud
software of multi-cloud marketplace is composed from software
components, each of them can be independently developed by
different developers and can reside in different clouds. Thus, the
development of cloud software could not be bound to any specific
cloud provider ecosystem.

4.2. General concept of CAM
In our approach, we adopt component-based application
approach, a cloud software is able to spread on a group of
compatible cloud platforms to form a cloud application system
without having to re-engineer or to re-develop. Thus, we divide a
cloud application into two separated parts: a cloud software and
underlying runtime systems, which are provided by particular
cloud providers. We name this cloud application model is
Composable Application Model (CAM). The proposed model is
depicted in Figure 4.1.

13



Figure 4.1: Composable Application Model.

4.2.1. Cloud application
A cloud application is a runtime service that offers specific
business functionalities. To customers, this refers to a similar
concept to Software as a Service (SaaS). Internally, a cloud
application including a cloud software hosted on an underlying
platform. On this basis, Our idea is that a cloud application may
be constructed as a distributed system whose elements are
compute servers running specific component-based software and
located at specific cloud providers. A cloud application is divided
into two separated parts: a component-based cloud software and an
underlying runtime system (which is a single or a group of cloud
platforms) as illustrated in Figure 4.1. The software part can be
developed separately from the underlying cloud platforms. All
dependencies between the cloud software and the cloud platforms
should be explicitly described as they will be used to check the
compatibilities at the time of deployment.
Depends on the number of cloud platforms are used, we classify
cloud applications into two categories:
• Single-platform application: A single platform application is a
cloud application operating on a single cloud platform.
• Multi-platform application: a multi-platform application is a
cloud application operating on a group of cloud platforms
which may be distributed among different cloud providers.

4.2.2. Cloud Software
Cloud software is a collection of artifacts (i.e. code and data)

grouped as a software bundle in a standard format. There are
several types of cloud software. In the simplest form, cloud
software is just a single component which can resides in a single

14


cloud platform. In more complex situations, a cloud software is a
composition of software components that could be distributed
across many cloud platforms. With this component-based
approach, developers can build up an application by just
integrating existing components into their own software solution.
This would help to increase reusability of the software components
and reduces unnecessary efforts in the software development
process.
Cloud Software Component, or component for short, is a basic
element of CAM. Components are used to build up more complex
cloud software. Beside the content of code and data, the definition
of a component should specify necessary conditions for the
component to be integrated with others and to be deployed on a
specific platform
and/or a platform group. A component may be an atomic entity or a
combination of other components. Cloud software components are
classified into three following types:
• Simple component type stands for a set of atomic entities, the
building blocks for cloud software. A simple component packs
its code and data together with the necessary requirements for
running properly. It also explicitly defines the capabilities
which other components may need when combining to form a
cloud software.

• Cloud Software Stack, or Stack for short, is a special kind of
multi-component cloud composition. It defines a sequence of
cloud software components in which a component run upon its
below components consuming the software services provided
by them and set up necessary environment for the components
above. Dependencies among layers of components should be
satisfied when developing a software stack. A stack can only be
deployed on a single platform.

15


• Cloud Software Composition, or composition for short, refers
to a more generic multi-component cloud composition.
Different from cloud software stack, which can only be
deployed on a single platform, a cloud software composition
can host its components on multiple platforms. Dependencies
among software components should be satisfied according to
the composition specification.

4.2.3. Cloud Platform
Cloud platform is a kind of runtime system provided by cloud
providers for hosting cloud software components. We refer the
term cloud platform as a model of delivery IaaS (Infrastructure as a
Service) and/or PaaS (Platform as a Service).
Various cloud providers can develop and provide the same kind
of cloud platform service, but with different price, QoS, resource
capacity, policies, etc... In our research scope, we only consider the
technical capabilities of cloud platforms for matching them with
the proposed software model.


4.3.

Simple Definition
Application Model

for

Composable

4.3.1. Matching Definition
To depict the relationships of components within a cloud
application modeled by CAM, we specify two types of
dependencies in the multi-cloud application model: software
dependence and platform dependence. Software dependence
denotes the inter-connection between two software components.
The platform dependence denotes deployment capability of a pair
of software components or a pair of a software component and a
cloud platform. We define two elements to make up a dependence:

16


Requirement and Capability. Relying on these elements, matching
rules is constructed to denote the dependencies within a cloud
application. Requirement specification, capability specification,
and matching condition is defined as follows:
• Requirement specification: requirement for short is denoted the
dependency of a component on other another component. It
poses the necessary conditions for component to perform its

functionality and behaviors. Requested interfaces and
properties of a component are encapsulated in requirement. We
specify two types of requirement: software requirement and
platform requirement. Software requirement (sreq) is a
constraint on the functionality and behavior of another
component. Platform requirement (preg) is a constraint on the
environment and technology of another component.
• Capability specification: capability for short denote the
available capacity that can meet the request from outside. Its
functionality and behavior are performed when it satisfies the
condition from another external component. Responded
interfaces and properties of a component are encapsulated in
capability. We specify two types of capability: software
capability and platform capability. Software capability (scap)
is a supply of the functionality and behaviors of a component.
Platform capability (pcap) is a supply of the environment and
technology of a component.
• Matching condition: we define a dependence between two
components is valid if requirement of a component match with
capability of the other.

17


4.3.2. Abstract model of Composable Application
Model
We develop an abstract model of CAM in which we ignore
the implementation details of the components but focus on the
relationship among components inside a software composition and
the relationship between a component and its underlying platforms.

4.3.2.1. Multi-component cloud software model
In CAM, we define the abstract model of cloud software as a
nested structure where each component may be a composition of
other components. Some of them may again be compositions of
other smaller components. This approach helps us increasing the
degree of reusability since the implementation of a complex
component may be reused in other compositions. This also
motivates the cloud software marketplace where developers can
develop and sell their small components instead of complete
software solutions. We classify component in the model into the
following three types: (i) Simple Component; (ii) Stack; (iii) and
Composition. Figure 4.3 shows the overall structure of CAM and
the relationship among these three types of the components.

Figure 4.3: The formal definition of multi-component
cloud software.
4.3.2.2. Base Component
As shown in Figure 4.4, three types of software components
are modeled as subtypes of the Base Component. This formalism

18


allows us to treat components of different types uniformly as
specializations of the Base Component. Each component has its
own properties. We use the dot-notation to refer to a property of a
component. For example, X.y is the property y of the component
X.
Since we focus on the relationship among components inside a
composition and the relationship between a component and its

underlying platforms, the properties of a component should
explicitly describe its requirements and capabilities. More
specifically, as shown in Figure 4.4, a component should have at
least the following properties: (1) description of software services
provided by the component (software capabilities - scaps), (2) the
establishment of runtime environment providing to upper
components in a stack manner (platform capabilities - pcaps), (3)
descriptions of extra software services required for running the
component properly (software requirements - sreqs), (4) and the
necessary requirements for underlying platforms to host the
component (platform requirements - preqs). The specifications of
components, i.e. the description of component’s properties, are
used for verifying the correctness of software composition and for
checking the compatibilities between a component and its
underlying platforms. These specifications are written by
developers, and they are not necessary to collate the actual
implementation of the components. Instead, developers can select
the requirements and capabilities of a component from a
predefined set of terms.

19


Figure 4.4: Base Component.
Note that a component may be hosted on multiple cloud
platforms from different cloud providers, the platform
requirements should be specified for each platform. We call degree
of a component to be the total number of underlying platforms for
hosting the component. Thus, the platform requirements for the
platform i is defined as pregs[i].

4.3.2.3. Simple Component
Simple component is an atomic type of components in CAM. In a
full definition, a simple component should specify its code and data as
well as the necessary specification of requirements and capabilities. A
simple component is hosted on a single platform (degree = 1). If the
set of requirements of a simple component is empty (regs = ∅), the
component can represent a complete cloud software. In general cases,
a simple component can combine with other components to form a
more complex component (Stack or Composition).

4.3.2.4. Cloud software stack
A cloud software stack, or stack for short, denotes a sequence of
simple components deployed on top of each other vertically. For
simplicity, we define a Stack in nested manner. Each stack has two
elements: (1) top element is a simple component lay on top of the
stack, (2) and base which is either a simple component or another
stack representing the remain components in the sequence.

20


Similar simple component, a software stack can only be deployed
on a single platform (degree = 1). Beside the advantage of reusability,
the combination of multiple components into a single form of stack
would help us reducing the cost of deployment and management by
combining corresponding operations from the stack’s elements. We
will discuss this interesting problem in another study from our ongoing research.

Figure 4.5: Cloud software stack
When creating a stack, a developer must specify the top element

and the base element. The developer must also specify the stack
requirements and capabilities (i.e. sreqs, preqs, scaps, and pcaps),
like those mentioned in the Base Component. A correct
combination of a stack S should satisfy the following validation
rules:
4.3.2.5. Cloud software composition
Cloud software composition, or composition for short, denotes a
set of software components combined in a single form of
component to hide the complexity of its own inter-dependency. A
software composition is considered as a directed graph whose
vertex are either a simple component or a stack. An edge from a
component A to a component B in a composition specifies that the

21


component A consumes services provided by the component B at
runtime.
Similar with stack, we apply the nested structure for defining
compositions. Each composition consists of a set of components
and some of them may be other compositions. For simplicity, we
define a composition with two elements (Figure 6): the first, and
the second. The inter-dependence of a composition is restricted to
the software dependence of the first to the second. Degree of the
composition is calculated by the sum of degrees of the first and the
second.

Figure 4.6: Cloud software composition.
When creating a composition, developers need to specify its
external requirements and capabilities. At the moment, we do not

allow extra components to lay on top of a composition. So, the
property pcaps should be empty. The following validation rules
should be applied for verifying the correctness of a composition C:
4.3.2.6 Cloud platform
Cloud platform, or platform for short, is used for modeling the
cloud platform profile in a cloud marketplace. A specification of a
single platform P should describe its capabilities (pcaps) in order to
match with the platform requirements (preqs) of cloud software
components which are aimed to deploy on it. Practically, the
specification of a platform is provided by the cloud provider or a
service broker such as cloud marketplace. In this case, developers

22


and cloud providers should agree on the same set of predefined
terms of the platform requirements and capabilities.

Figure 4.7: Cloud platform.
A cloud software composition may require more than one
platform. We define platform group as an order set of cloud
platforms, and compatible platform group as a platform group that
satisfies the platform requirements of a composition. The following
predicates are used for checking this property.
At the time of software deployment, platform compatibility
should be checked to ensure that the software component will work
fine on the underlying platform.

4.4. Description Templates of CAM (CAM-D)
With the motivation to standardize the multi-cloud application

description in a uniform, we define a description method that is not
only capable of expressing its behaviours and properties in
standardized description patterns, but also meet the multicloud
characteristics in general and O-Marketplace in particular. To
achieve this goal, our work focuses on developing description
templates for entire CAM and its components. The description of
CAM application is built from individual descriptions based on the
matching rules. Because CAM is defined as a nested structure, so
the description method has to express this special feature. The
description
templates
is
available
at:
/>
23


4.5.

Experimentation
Application Model

of

Composable

To transform a CAM-D application script to TOSCA topology
template, we apply a two-step process:
1. Flattening the given CAM-D application script into a

flattening composition;
2. Transforming the flattening composition to TOSCA
topology template.

4.6. Applications of Composable application
model in the context of O-Marketplace
4.6.1. CAM-based matchmaking method for OMarketplace
4.6.1.1. The proposed approach for matchmaking
method
Related matching solutions have limitations as follows: (i) the
compatibility and the dependencies among components in a multicomponent cloud application is not considered; (ii) these matching
solutions have not been fully defined in a specific multicloud
application pattern; (iii) There is no paper mentioned about
matchmaking a component-based cloud software and its runtime
systems delivered by different cloud providers.
To tackle this issues, the proposed approach to explicitly specify
the technological constraints among software components and
between a component and its expected underlying runtime platforms
by matching rules to verify the correctness of software composition
and deployment. Beside, we develop a matchmaking algorithm to
retrieve a group of compatible cloud platforms for a component-based

24


cloud software that suits with a criteria set ordered by cloud consumer.
On this basis, a CAM-based multi-cloud application is made up.

4.6.1.2. Matchmaking Context
To facilitate the suggestion feature of the multi-cloud marketplace,

relying on CAM concept, we develop a matchmaking method of
which algorithm would help consumers to find suitable platforms to
host a specific cloud software by matching the platform requirements
of the cloud software to the capabilites of the cloud platform service.

4.6.1.3. Matchmaking algorithm
We assume that a platform solution for hosting a cloud software
component C is a compatible platform group PG to the component
C. There may be more than one solution existed since several cloud
providers may offer a same kind of platform (with different price
and quality of service). Choosing an optimal solution means that
we need to make a comparison among the solutions based on a
designated cost function. We call Cost(PG) for the cost function of
a platform solution, i.e. the platform group PG. Some reasonable
examples for the cost function would be:
This cost function would help customers to select a platform
solution with optimal price.
This cost function would help customers to select a platform
solution with a smallest number of platforms will be used.
Using such a cost function, we develop a matchmaking
algorithm for suggesting compatible platform solution as shown in
the following pseudo code.
00. Algorithm Matchmaking(C, PS);
01. Input:

25