Multi-party Contract Management for Microservices

Zakaria Maamar

1 a

, Noura Faci

2 b

, Joyce El Haddad

3 c

, Fadwa Yahya

4 d

and Mohammad Askar

3,5

Zayed University, Dubai, U.A.E.

Universit

e Calude Bernard, CNRS, LIRIS, 69622 Villeurbanne Cedex, France

Universit

e Paris Dauphine-PSL, Paris, France

Prince Sattam Bin Abdulaziz University, Al kharj, Saudi Arabia

Universit

e Paris Nanterre, Nanterre, France

Keywords:

Cloud, Contract, Edge, Internet of Things, Microservices, Quality-of-Service.

Abstract:

This paper discusses the necessary steps and means for ensuring the successful deployment and execution of

software components referred to as microservices on top of platforms referred to as Internet of Things (IoT)

devices, clouds, and edges. These steps and means are packaged into formal documents known in the literature

as contracts. Because of the multi-dimensional nature of deploying and executing microservices, contracts

are specialized into discovery, deployment, and collaboration types, capturing each speciﬁc aspect of the

completion of these contracts. This completion is associated with a set of Quality-of-Service (QoS) parameters

that are monitored allowing to identify potential deviations between what has been agreed upon and what has

really happened. To demonstrate the technical doability of contracts, a system is implemented using different

datasets that support experiments related to assessing the impact of the number of microservices and platforms

on the performance of the system.

1 INTRODUCTION

A cloud/edge-based Internet-of-Things (IoT) environ-

ment comprises a number of interconnected devices

(aka things) working together to provision services

that end-user applications would compose together.

To sustain this provisioning and avoid the pitfalls of

monolithic applications, the best architectural styles

should be adopted with focus lately on microser-

vices (Brito et al., 2021; Butzin et al., 2016). In

a recent post by NGINX

, Netﬂix shared its expe-

rience of transitioning “from a traditional develop-

ment model with 100 engineers producing a mono-

lithic DVD-rental application to a microservices ar-

chitecture with many small teams responsible for the

end-to-end development of hundreds of microservices

that work together to stream digital entertainment to

millions of Netﬂix customers every day”.

https://orcid.org/0000-0003-4462-8337

https://orcid.org/0000-0001-7428-6302

https://orcid.org/0000-0002-2709-2430

https://orcid.org/0000-0003-4661-1344

https://tinyurl.com/ojm9zgp.

Tapping into microservices’ core characteristics

as per (Lewis and Fowler, 2014), high-cohesion and

loosely-coupled, the trend nowadays is to deploy

microservice-based applications on a mix of cloud

and edge platforms despite their differences. Ac-

cording to Khebbeb et al., cloud means more re-

sources, more reliability, and more latency, and edge

means less resources, less reliability, and less la-

tency (Khebbeb et al., 2020). In fact, they comple-

ment each other (De Donno et al., 2019; Singh, 2017).

In a previous work, we designed and implemented

the deployment and execution of microservices in

the presence of many stakeholders exempliﬁed with

things, edge platforms, and cloud platforms (Maa-

mar and Faci, 2021). The design and implementation

took into account constraints related to things’ lim-

ited technical capabilities, edges’ closeness to things,

and clouds’ inappropriateness for real-time applica-

tions

along with additional characteristics like types

Puliaﬁto et al. report that “the average round trip time

between an Amazon Cloud server in Virginia (U.S.A.) and

a device in the U.S. Paciﬁc Coast is 66ms; it is equal to

125ms if the end device is in Italy; and reaches 302ms when

the device is in Beijing” (Puliaﬁto et al., 2019).

276

Maamar, Z., Faci, N., El Haddad, J., Yahya, F. and Askar, M.

Multi-party Contract Management for Microservices.

DOI: 10.5220/0011266200003266

In Proceedings of the 17th International Conference on Software Technologies (ICSOFT 2022), pages 276-287

ISBN: 978-989-758-588-3; ISSN: 2184-2833

of things (static versus mobile), forms of interac-

tions (vertical versus horizontal), and properties of

resources that are consumed (limited versus limited-

but-renewable versus non-shareable). In this pa-

per, we identify and afterwards formalize the nec-

essary steps and mechanisms that would ﬁrst, con-

ﬁrm the binding of things/edges/clouds as stakehold-

ers to microservices and second, allow these stake-

holders to collaborate together, should they run into

any obstacles that these constraints and characteristics

could cause. We package the steps and mechanisms

into contracts and track their satisfaction through a

set of non-functional properties forming what the

ICT community refers to as Quality-of-Service (QoS)

model (Menasc

e, 2002).

The adoption of contracts is commonly reported

in the ICT literature as per the survey paper (Marino

et al., 2019). However, to the best of our knowl-

edge, little exists when it comes to ﬁrst, identify-

ing contracts in the context of microservices, things,

and edge/cloud platforms and second, deﬁning con-

tracts’ types, lifecycles, and adjustments, should the

QoS non-functional properties become unsatisﬁed.

To address this gap, we proceed with (i) deﬁning con-

tracts to regulate microservices’ deployment and exe-

cution, (ii) identifying types of contracts to ensure the

success of this deployment and execution, (iii) spec-

ifying lifecycles of and dependencies between con-

tracts, and, ﬁnally, (iv) demonstrating contract man-

agement through a system. The rest of this paper is

organized as follows. Related work is discussed in

Section 2. Section 3 presents our microservices’ de-

ployment and execution approach that is referred to as

choreOrchest mixing choreography and orchestration

to achieve this deployment and execution. Section 4

examines contracts in terms of types, clauses, and

lifecycles. Section 5 discusses the system that was

implemented and the results obtained out of the ex-

periments. Finally, Section 6 concludes and points out

some future work.

2 RELATED WORK

To the best of our knowledge, there are not dedicated

works that examine contracts and their complete life-

cycles in an ecosystem of microservices, IoT, cloud,

and edge. To address this gap, we discuss some works

that adopt contracts for multiple purposes like moni-

toring, regulation, and security.

Balint and Truong propose a contract-aware

IoT framework to manage and monitor IoT data mar-

ketplaces in (Balint and Truong, 2017). Contracts re-

fer to data rights (e.g., derivation and reproduction),

quality of data (e.g., completeness and conformity),

pricing model (e.g., charges and subscription period),

purchasing policy (e.g., contract termination and re-

fund) and control (e.g., warranty and indemnity).

Contracts are established between customers (either

persons or software) and things’ providers. Both

providers and customers engage in contract negotia-

tion to specify contractual terms when purchasing or

selling data. To address the scalability of data mar-

ketplaces, the framework is designed as a microser-

vices architecture allowing each service to scale with-

out disrupting other services in the framework.

Longo et al. discuss the importance of pub-

lic contracts to regulate the management of pub-

lic services such as data services in (Longo et al.,

2019). The authors note that the rapid and con-

tinued change of these services’ requirements and

expectations, is making contracts “obsolete” calling

for their regular adjustment. To keep the contracts

up-to-date, Longo et al. propose a cloud-based ap-

proach for assessing the QoS of local Transporta-

tion Services (TS) in Apulia Region (Southern Italy).

SLA between TS providers and the Regional Au-

thority, as well as the minimal guaranteed QoS lev-

els between TS providers and passengers, are mod-

eled as contracts enacted via a cloud-based system,

which gathers data from sensors embedded into pas-

sengers’ smartphones. As a result, changes in con-

tracts’ conditions to improve the perceived and deliv-

ered QoS have been quick and facilitated based on

collected data.

Pan et al. report about ﬁrst, the security and scala-

bility challenges that IoT is facing because of the lim-

ited capabilities of IoT devices and second, the role

that edge could have in helping IoT tackle these chal-

lenges in (Pan et al., 2019). The authors designed and

prototyped an edge-based IoT framework, EdgeChain,

that capitalizes on blockchain and smart contract tech-

nologies. EdgeChain uses a credit-based resource

management system to control how much edge re-

sources are made available for IoT devices with re-

spect to predeﬁned policies that consider priority, ap-

plication types, and past behaviors. To enforce these

policies, smart contracts regulate IoT devices’ behav-

iors in a non-deniable and automated manner. In ad-

dition, all IoT devices’ activities and transactions are

recorded using blockchain for secure data logging and

auditing. As a result, contracts permit carrying out

trusted transactions.

Singh et al. propose a Service Level Agree-

ment (SLA)-aware autonomic Technique for Allo-

cation of Resources (STAR) given that current re-

source management solutions may not provision ef-

ﬁcient services for cloud nodes and may end-up vio-

Multi-party Contract Management for Microservices

277

lating the SLA’s clauses in (Singh et al., 2020). STAR

aims at mitigating such violations and improving user

satisfaction. Furthermore, STAR considers different

QoS parameters such as execution time, cost, latency,

reliability and availability to analyze the impact of

QoS parameters on SLA violation and to dynamically

manage resources based on QoS requirements.

Sun et al. present a contract-based resource shar-

ing approach to schedule tasks in a fog-cloud envi-

ronment in (Sun et al., 2020). Due to clouds’ limi-

tations, the authors address how to take advantage of

clusters of fog resources so, that, more tasks can run

on these resources. Using a sealed-bid bilateral auc-

tion mechanism (buyers, sellers, and auctioneers) and

constructing functional domains, Sun et al. identify

the best fog nodes (where some are mobiles) in each

cluster with respect to the betweeness centrality, com-

puting performance, and communication delay to the

IoT nodes. During contract formation, a fog cluster

can be either a buyer in the sense of having the right

to use some fog nodes in other fog clusters or a seller

in the sense of giving the right to other fog clusters to

use the fog nodes that fall into its cluster, the cloud is

seen as a trusted third party, and the commodity in the

auction is the speciﬁc type of fog nodes in a particular

fog cluster under corresponding time slot.

Truong and Klein adopt DevOps contracts to en-

sure the proper execution of IoT microservices over

edge resources in (Truong and Klein, 2020). The

authors note that many stakeholders participate in

preparing the contracts, for instance IoT service users,

IoT service providers, IoT unit providers, IoT devel-

opers, and IoT gateway/platform and edge platform

providers. All these stakeholders share many con-

cerns about IoT units, services, and, infrastructure re-

sources. Terms such as access to data, quality of data,

QoS, and price are included in the contracts.

It is clear that the works above (although a sample)

expose the gap in examining contracts in an ecosys-

tem of microservices, IoT, edge, and cloud. Our ap-

proach to manage contracts for microservices sheds

light on types of contracts, lifecycles of contracts, in-

teractions between contracts, and properties of con-

tracts. This management also considers the platforms

upon which microservices will be deployed and ex-

ecuted. Some platforms like things have limited pro-

cessing capabilities while others like clouds are not ﬁt

for satisfying real-time applications’ requirements.

3 MICROSERVICES

DEPLOYMENT AND

EXECUTION

This section summarizes our previous work on de-

ploying and executing microservices over things,

edges, and/or clouds.

Three elements namely, types of things, forms

of interactions, and availabilities of resources, were

taken into account:

Types of things. We identify 2 types of things la-

belled as either static or mobile. By considering these

2 types, we identify the strengths and limitations of

things when it comes to interacting with the environ-

ment and consuming resources. On the one hand,

a static thing is assigned to a physical location and

cannot be moved because of its size, security con-

cerns, and safety regulations for example. On the

other hand, a mobile thing is ﬁtted with wireless com-

munication means so, that, it roams the environment.

It happens that a mobile thing becomes temporar-

ily static for reasons like running out of resources

before resuming its planned/unplanned roaming and

suspending roaming until some conditions are met.

Forms of interactions. We identify 2 forms of in-

teractions labelled as either horizontal, occurring be-

tween homogeneous peers, or vertical, occurring be-

tween heterogeneous peers. A peer is either a thing,

an edge, or a cloud. Interactions are a mix of bottom-

up from things to edges then clouds conveying data,

and top-down from clouds to edges then things con-

veying commands. These interactions permit to form

coalitions of peers to handle complex users’ demands

and ofﬂoad demands from one peer to another and

even from one coalition to another.

Availabilities of resources. We consider avail-

abilities of resources since they impact the deploy-

ment and execution of microservices on things, edges,

and/or clouds. Some resources are limited like

storage while others are (temporarily) non-shareable

like data. Building upon our previous work on re-

source management (Baker et al., 2018), we asso-

ciate resource availabilities with 5 consumption prop-

erties referred to as unlimited, shareable, limited (the

consumption of a resource is restricted to a par-

ticular capacity and/or period of time), limited-but-

renewable (the consumption of a resource continues

to happen since the (initial) agreed-upon capacity has

been increased and/or the (initial) agreed-upon period

of time has been extended), and non-shareable (the

concurrent consumption of a resource must be coordi-

nated - e.g., one at a time -). Unless stated, a resource

is by default unlimited and/or shareable.

Deploying microservices would be either orches-

ICSOFT 2022 - 17th International Conference on Software Technologies

278

Cloud

Edge coalition

M-things S-things

edge

M-thing

request

update

deploy

Interface Layer

Repository

of resources

Repository

microservices

deploy

request

consult

update

request

update

request

update

deploy

Legend

S/M-thing: static/mobile thing; r: resource; ms: microservice; : horizontal interactions; : vertical interactions

Figure 1: choreOrchest in-action.

trated or choreographed. Orchestration would rely

on a centralized component that would decide on

where microservices would be deployed. Contrar-

ily, choreography could rely on peer-to-peer inter-

actions to let communicating platforms decide on

where microservices would be deployed. To cater

for the needs of our cloud, edge, and IoT ecosystem,

we mix choreography and orchestration into a ded-

icated component that we refer to as choreO rchest.

Fig. 1 illustrates how choreOrchest, running on top

of the pool of microservices, is responsible for se-

lecting those that will be deployed on the available

platforms (clouds, edges, static things, and/or mo-

bile things). choreOrchest is aware of the platforms’

resource availabilities along with the microservices’

needs of resources. These availabilities are reported

in the repository of resources that all platforms regu-

larly update. Once choreOrchest consults the repos-

itory of resources and pool of microservices, it dis-

covers relevant platforms that match with microser-

vices. This matching aims at maximizing the income

of each platform (i.e., total sum of incomes for re-

sources that a platform secures when hosting a mi-

croservices for deployment and execution) under the

constraint that deployment and execution of microser-

vices must not exceed a certain budget. Upon match-

ing completion, choreO rchest selects on which plat-

forms the microservices will be deployed and then re-

quests the interface layer to deploy and track them.

In conjunction with the orchestration-based deploy-

ment, it happens during execution that the platforms

would ofﬂoad some of the hosted microservices to

other peers. Ofﬂoading supposes that each platform

maintains a vicinity list containing those collabora-

tive peers that would be willing to support this plat-

form in hosting some microservices in return of a

fee. These ofﬂoading opportunities that choreO rchest

may not be aware of could permit to ensure that next

microservices or a group of microservices are exe-

cuted in the same platforms to avoid for instance, un-

necessary data transfer between platforms. It happens

that a microservice would ﬁnish the execution earlier

than expected and that a platform would secure ad-

ditional resources through virtualization. As a result

the platforms request from the interface layer to in-

teract with the choreO rchest that would pull relevant

microservices from the pool for deployment through

the interface layer again. For more details, readers are

invited to consult (Maamar and Faci, 2021).

4 CONTRACT MANAGEMENT

This section introduces the concepts underpinning

contract management for microservices deployment

and execution. First, types of contracts with identi-

ﬁed QoS non-functional properties are discussed, and

then interactions between contracts as well as con-

tracts’ lifecycles are presented.

4.1 Types of Contracts

Fig. 2 illustrates the 3 types of contracts that we deem

necessary for managing microservices deployment

and execution over thing, edge, and cloud platforms.

These contracts are discovery, deployment, and

collaboration. The ﬁgure also illustrates how the

Multi-party Contract Management for Microservices

279

has impact on

Discovery

contract (QoS)

(a)

Deployment

contract (QoS)

Collaboration

contract (QoS)

has impact on

(b)

has impact on

(c)

Figure 2: Types of contracts.

contracts impact each other. Indeed, the value of a

QoS non-functional property in a contract is changed

because of a counterpart property in another contract.

In the following, each contract is deﬁned along with

its QoS non-functional properties.

Discovery contract is established between mi-

croservices, a third party (e.g., broker), and potential

hosting platforms.The following QoS non-functional

properties could populate a discovery contract (Fig. 3

as example):

- Discovery time that the third party would need to

connect microservices to platforms.

- Discovery quality that microservices and platforms

would each expect from the third party. Be-

cause of microservices’ and platforms’ separate

expectations, we specialize discovery quality into

dQuality

for the microservices that target a cer-

tain hosting level like reliability by the platforms

and dQuality

for the platforms that target a cer-

tain execution time of the hosted microservices.

Since discovery quality is assessed after the host-

ing of microservices over platforms occurs ef-

fectively, the deployment contract’s QoS non-

functional properties (discussed next) will impact

the discovery contract as per Fig. 2 (a). Any de-

viation from a discovery contract’s agreed-upon

clause like drop in execution time due to a poor

hosting level should be communicated the third

party that could consider this deviation when rec-

ommending potential platforms to microservices

in the future.

Deployment contract is established between mi-

croservices and conﬁrmed platforms upon the third

party’s recommendations as stated in the discov-

ery contract description. The following QoS non-

functional properties could populate a deployment

contract ( Fig. 4as example):

- Deployment time that a platform would need to

have a microservice ready for execution, should

the microservice require a particular set-up.

- Execution time that a platform would need to have

a microservice executed.

Figure 3: Example of JSON instantiated discovery-contract.

- Hosting level that a microservice would require

without degrading its performance nor the per-

formance of the platform. A platform’s hosting

level could be related to its capacity of performing

without failures nor interruptions over a period of

time, and would depend on its technical capabili-

ties.

- Delegation quality that a platform would use

to make a microservice aware of the (pos-

itive/negative) ofﬂoading impact on this mi-

croservice’s deployment time and execution time.

Like with the the discovery contract’s discovery-

quality property, we specialize delegation quality

into eQuality

for the microservices that end-up

executed on different platforms and eQuality

for

the platforms that receive microservices for host-

ing upon the requests of other platforms. Since

delegation quality is assessed after the ofﬂoad-

ing of microservices occurs effectively, the col-

laboration contract’s QoS non-functional proper-

ties will impact the deployment contract as per

Fig. 2 (b). Any deviation from a deployment con-

tract’s agreed-upon clause like increase/decrease

in an ofﬂoaded microservice’s hosting level due to

ICSOFT 2022 - 17th International Conference on Software Technologies

280

Figure 4: Example of JSON instantiated deployment-contract.

a better/worse platform should be communicated

to this microservice’s owner so, that, he decides

in the future on accepting/rejecting ofﬂoading de-

mands.

Collaboration contract is established between

either homogeneous peers like things-things, edges-

edges, and clouds-clouds or heterogeneous peers like

things-edges, things-clouds, and edges-clouds. The

following QoS non-functional properties could popu-

late a collaboration contract (Fig. 5 as example):

- Ofﬂoading time that a platform would need to

transfer a microservice to another platform for de-

ployment and execution.

- Ofﬂoading quality that a microservice would use

to report its experience of being deployed and ex-

ecuted on a different platform from the one that

is reported in the discovery contract. This expe-

rience refers to deployment-time and execution-

time properties that should be benchmarked to

the same properties in the deployment contract.

Along with this experience, ofﬂoading quality is

shared with the third party involved in the dis-

covery so, that, future recommendations of plat-

forms to host microservices could be adjusted,

whether the quality turns out positive or nega-

tive. This means that a collaboration contract’s

QoS non-functional properties will impact the dis-

covery contract as per Fig. 2 (c).

- Collaboration quality that a platform would use to

decide in the future on ofﬂoading microservices

to other platforms. Collaboration quality should

be benchmarked to the deployment contract’s

delegation-quality property as per Fig. 2 (b).

Like with both the discovery contract’s discovery-

quality property and the deployment contract’s

delegation-quality property, we specialize col-

laboration quality into cRecommendingQuality

for the platform recommending a peer and

cRecommendedQuality

for the platform that is

recommended by a peer and is dependent on the

deployment contract’s eQuality

Figure 5: Example of JSON instantiated collaboration-

contract.

Multi-party Contract Management for Microservices

281

4.2 Interactions between Contracts

In Fig. 2, interactions (a), (b), and (c) capture the im-

pacts that some contracts could have on each other.

Indeed, the deployment contract impacts the discov-

ery contract and the collaboration contract impacts

both the discovery contract and the deployment con-

tract. By impact, we mean the completion of a con-

tract at run-time leads into results that would be inte-

grated into the preparation of another contract or up-

dating an existing one.

1. from: Deployment Contract to: Discovery Con-

tract. On the one hand, the satisfaction level

(abstracting deploying-time and execution-time

properties) of a microservice towards a platform

upon which it has been deployed (i.e., dQuality

)

needs to be reported to the third party so, that, fu-

ture discovery cases that could involve this plat-

form could be handled differently. On the other

hand, the satisfaction level (abstracting hosting-

level property) of a platform towards the microser-

vices it has received for hosting (i.e., dQuality

)

needs to be reported to the third party so, that, fu-

ture discovery cases that could involve these mi-

croservices would be handled differently. Thanks

to details reported to the third party, this one does

not rely on what microservices and platforms an-

nounce in terms of technical requirements and ca-

pabilities, respectively. But, the third party also

relies on what happens at run-time when complet-

ing deployment contracts.

2. from: Collaboration Contract to: Deployment

Contract.] On the one hand, the satisfaction level

(abstracting eQuality

property) of a microser-

vice towards a new platform, that is different from

the initial platform reported in the discovery con-

tract, should be reported to this initial platform so,

that, future delegation cases that could involve this

new platform would be handled differently. On

the other hand, the satisfaction level (abstracting

eQuality

property) of a platform towards the mi-

croservices it has received for hosting upon the re-

quest of the initial platform reported in the discov-

ery contract should be reported to this initial plat-

form so, that, future delegation cases that could

involve these microservices could be handled dif-

ferently. Thanks to details reported to the ini-

tial platform, this one does not rely on what mi-

croservices and other platforms announce in terms

of technical requirements and capabilities, respec-

tively. But, the initial platform also relies on what

happens at run-time when implementing collabo-

ration contracts.

3. from: Collaboration Contract to: Discovery

Contract. The satisfaction level (abstracting

ofﬂoading-quality property) of a microservice to-

wards a new platform, that is different from the

one identiﬁed during the discovery, needs to be

reported to the third party so, that, future discov-

ery cases that could involve the ﬁrst platform that

recommends this new platform would be handled

differently.

4.3 Lifecycles of Contracts

To track and manage different aspects of contracts

like performance and compliance, we deﬁne their

lifecycles represented as a state diagram (Fig. 6).

States include initiated (initial state), revised (entry-

point state), performed (initial state), completed (ﬁ-

nal state), canceled (ﬁnal state), and suspended (ﬁ-

nal state) and are connected together forming Se-

quences (Seq

). Prior to listing these sequences,

we recall that a contract could be subject to

changes(e.g., a new platform is assigned) and/or could

run into obstacles (e.g., late conﬁrmation of a delega-

tion request) that both could result into either cancel-

ing or suspending the contract. For the sake of sim-

plicity, sequences having performed as an initial state

are not listed below since they are already parts of the

sequences having initiated as an initial state.

1. Seq

= initiated

start

−→ performed

success

−→ completed.

A contract is completed successfully without be-

ing subject to any changes nor running into any

obstacles.

2. Seq

= initiated

change

−→ revised

approval

−→ performed

success

−→ completed. A contract is completed suc-

cessfully after being subject to some changes and

not running into any obstacles.

3. Seq

= initiated

start

−→ performed

f ailure

−→ canceled.

A contract is canceled although it was not subject

to any changes but has run into some obstacles.

4. Seq

= initiated

change

−→ revised

approval

−→ performed

f ailure

−→ canceled. A contract is canceled because it

has been subject to some changes and has run into

some obstacles.

5. Seq

= initiated

start

−→ performed

violation

−→ sus-

pended. A contract is suspended without being

subject to any changes but has run into obstacles

that resulted into its violation and hence, suspen-

sion.

6. Seq

= initiated

change

−→ revised

approval

−→ performed

violation

−→ suspended. A contract is suspended after

being subject to some changes and running into

ICSOFT 2022 - 17th International Conference on Software Technologies

282

performed completed

suspended

revised canceled

change

approval

success

violation

handling

failure

initiated

start

Discovery/Collaboration contracts

Deployment contract

Figure 6: Contract’s lifecycle as a state diagram.

some obstacles. Both have resulted into its viola-

tion and hence, suspension.

7. Seq

= initiated

start

−→ performed

violation

−→ suspended

handling

−→ performed

success

−→ completed. A contract is

completed successfully without being subject to

any changes but has run into some obstacles that

have been handled, which has allowed its success-

ful completion.

8. Seq

= initiated

change

−→ revised

approval

−→ performed

violation

−→ suspended

handling

−→ performed

success

−→ com-

pleted. A contract is completed successfully after

being subject to some changes and running into

some obstacles that have been handled, which has

allowed its successful completion.

9. Seq

= initiated

start

−→ performed

violation

−→ suspended

handling

−→ performed

f ailure

−→ canceled. A contract is

canceled without being subject to any changes but

has run into some obstacles that although these

obstacles have been handled the contract has been

canceled.

10. Seq

= initiated

change

−→ revised

approval

−→ performed

violation

−→ suspended

handling

−→ performed

f ailure

−→ can-

celed. A contract is canceled after being subject

to some changes and running into some obstacles

that although these obstacles have been handled

the contract has been canceled.

After listing a contract’s different sequences of

states, we proceed, hereafter, with identifying the rel-

evant lifecycle per type of contract. Each lifecycle

draws the necessary states from these sequences along

with the option of dropping some states because of the

nature of each contract.

4.3.1 Discovery Contract’s Lifecycle

A discovery contract formalizes the ﬁrst steps that

lead to identifying the platforms upon which the mi-

croservices will be deployed and then, executed. This

contract’s lifecycle takes on the following states:

• In the initiated state, the discovery contract’s nec-

essary attributes are instantiated in terms of which

microservice needs hosting, which potential plat-

forms are contacted to provide this hosting, and

which third party drives the interactions between

the microservice and platforms. Additional at-

tributes to instantiate could include deadlines to

complete the interactions and particular criteria to

shortlist the platforms.

• In the revised state, the discovery contract’s in-

stantiated attributes could be adjusted, should

some changes blacklike criteria for shortlisting

platforms and/or technical details for hosting mi-

croservices arise.

• In the performed state, the discovery contract is

implemented by making the third party match the

microservice to the adequate platform.

• In the suspended state, the under-performing dis-

covery contract could run into obstacles such as

violating the deadline to identify a platform for a

microservice. Should these obstacles end-up be-

ing handled properly, then the completion of the

discovery contract would resume. Otherwise, it

would be stopped.

• In either completed or canceled state, the under-

performing discovery contract ends with either

success or failure, respectively, depending on the

outcome of assigning a microservice to a plat-

form. A successful completion of the discovery

contract triggers the instantiation of the deploy-

ment contract’s necessary attributes.

4.3.2 Deployment Contract’s Lifecycle

Once a discovery contract completes with success, a

deployment contract is drawn between the microser-

vice and platform. This contract’s lifecycle takes on

the following states:

Multi-party Contract Management for Microservices

283

• In the performed state, the deployment contract is

implemented by making the microservice run over

the platform.

• In the revised state, the instantiated attributes of

the already-prepared deployment contract (out-

come of the discovery contract) could be adjusted,

should some changes arise impacting the deploy-

ment of the microservice on the platform. An ex-

ample of change could be deploying the microser-

vice

on a different platform from the one that is men-

tioned in the discovery contract. Should this

change happen, a collaboration contract would

need to be prepared.

• In the suspended state, the under-performing de-

ployment contract is running into obstacles such

as violating the agreed-upon deployment time and

execution time. Should these obstacles end-up be-

ing handled, then the completion of the deploy-

ment contract would resume. Otherwise, it would

be stopped.

• In either completed or canceled state, the under-

performing deployment contract ends with either

success or failure depending on the outcome of

having the microservice run over the platform.

In the afore-mentioned states, it is worth noting the

absence of initiated state making performed the ini-

tial state and revised an entry-point state for the de-

ployment contract.

4.3.3 Collaboration Contract’s Lifecycle

A collaboration contract formalizes the process of

transferring a microservice from a platform to another

prior to its execution. This contract’s lifecycle takes

on the following states:

• In the initiated state, the collaboration contract’s

necessary attributes are instantiated in terms of

which microservice will be transferred to which

platform and which platform is recommending the

transfer.

• In the revised state, the collaboration contract’s

instantiated attributes could be adjusted, should

some changes arise impacting for instance, the

recommended platform for hosting the microser-

vice.

• In the performed state, the collaboration contract

is implemented through the effective transfer of

the microservice to the recommended platform.

• In the suspended state, the under-performing col-

laboration contract is running into obstacles such

as violating the agreed-upon ofﬂoading time and

ofﬂoading quality time. Should these obstacles

be handled, then the completion of the collabora-

tion contract would resume. Otherwise, it would

be stopped.

• In either completed or canceled state, the under-

performing collaboration ends with either success

or failure depending on the outcome of having

the microservice transferred to the recommended

platform.

5 IMPLEMENTATION AND

EVALUATION

This section ﬁrst describes the architecture of the sys-

tem for managing contracts and then, the experiments

that were carried out.

5.1 Implementation

Fig. 7 is the architecture of the system we

developed in Java 1.8 on a Windows 10, In-

tel Core i5-8300H processor, 16 GB RAM,

GPU Nvidia GTX 1050 4GB desktop. The system

consists of 3 repositories (platforms, microservices,

and contracts), 3 managers (contract, monitoring,

and execution), and one log ﬁle. In this ﬁgure, pr,

ex, and po stand for pre-execution, execution and

post-execution stages, respectively, and arrowed

lines correspond to interactions between all the

repositories, managers, and log.

During the pre-execution stage, the contract man-

ager prepares all types of contracts (discovery, de-

ployment, and collaboration) based on ﬁrst, microser-

vices’ technical requirements and platforms’ techni-

cal capabilities and second, these platforms’ ongo-

ing/changing loads. During this stage, different val-

ues are assigned to the QoS non-functional proper-

ties according to their roles in ﬁnalizing the contracts.

For instance, Discovery time, dQuality

, dQuality

and Deployment time are assigned random values

according to a speciﬁc range, e.g., [5, 10], while

eQuality

, eQuality

, and Ofﬂoading quality are as-

signed null, and properties cRecommendingQuality

and cRecommendedQuality

are assigned high. To

address the cold-start concern, we assumed that, at

initialization time, all platforms trust each other con-

ﬁrming the high level of collaboration between them.

During the execution stage, the execution man-

ager consults the repository of contracts to deploy the

microservices and then, proceeds with tracking their

execution and potentially ofﬂoading some to other

platforms along with measuring the effective values

ICSOFT 2022 - 17th International Conference on Software Technologies

284

inform

notify

update

Execution

Manager

Monitoring

Manager

Contract

Manager

Repository

of contracts

Repository

microservices

check

input

Cloud

Edge coalition

M-things S-things

edge

M-thing

deploy

track

consult

associated with

Log

Repository

of platforms

Figure 7: Architecture of the contract-management system.

of relevant QoS non-functional properties like Discov-

ery time, Deployment time, and Execution time. These

values are stored in the log that the monitoring man-

ager uses during the post-execution stage for bench-

marking against the corresponding values in the de-

ployment contracts.

Should there be any discrepancy according to

some thresholds, the monitoring manager would no-

tify the contract manager that would ﬂag a contract

as either suspended or canceled in compliance with

this contract’s lifecycle (Fig. 6). Otherwise, the con-

tract manager ﬂags the contract as completed in com-

pliance again with this contract’s lifecycle.

5.2 Evaluation

Experiment Setup. Due to the limited availabil-

ity of real datasets that could satisfy our techni-

cal needs and requirements, we resorted to creating

2 datasets (d1 and d2) during the pre-execution stage

and using an existing dataset (d3) that was obtained in

a previous work (Maamar and Faci, 2021). Table 1 re-

ports details about each dataset in terms of number of

microservices, number of platforms, and QoS values

whether real or generated.

Results and Discussions. We conducted a series of

experiments to compute the average execution time

of the monitoring and contract managers. Each ex-

periment was executed 10 times. The ﬁrst series of

experiments were applied to d1 evaluating the impact

of incrementing by 100 the number of microservices

from 50 to 1050 on the average execution time of both

managers. Table 2 shows that the average execution

time increases exponentially with the number of mi-

croservices. However, even with a large number of

microservices, the achieved performance remains ac-

ceptable.

In the second series of experiments that were ap-

plied to d2, we evaluated the impact of increment-

ing by 50 the number of platforms from 50 to 500

on the average execution time of both managers. As

expected, the average execution time increases expo-

nentially with the number of platforms as per Table 3.

However, even with a large number of platforms, we

still achieve an acceptable performance.

To conclude the series of experiments, we con-

ducted two more. The ﬁrst one was applied to d2 with

exactly 30 platforms resulting into an average execu-

tion time of 187,4 ms for both managers. Finally, the

second one was applied to d3 checking the validity

of the previous experiment’s results. The average ex-

ecution time of both managers is 184,4 ms which is

in line with these results.

6 CONCLUSION

This paper presented an approach for regulating mi-

croservices’ deployment and execution over plat-

forms using contracts. On the one hand, the plat-

forms are specialized into IoT devices, edges, and

clouds. On the other hand, contracts are specialized

into discovery, deployment, and collaboration deﬁn-

ing who has done what, when, where, and for what

purpose. For instance, discovery contracts regulated

the “deals” between microservices’ owners and plat-

forms’ providers while collaboration contracts regu-

lated the “deals” between platforms ofﬂoading their

micorservices to other platforms. Contracts were also

Multi-party Contract Management for Microservices

285

Table 1: Details about the datasets of the experiments.

dataset # of microservices # of platforms real QoS values generated QoS values

d1 1050 30 – discovery time, deployment

time, execution time, hosting

level, ofﬂoading time

d2 20 510 – discovery time, deployment

time, execution time, hosting

level, ofﬂoading time

d3 15 30 deployment time,

ofﬂoading time

discovery time, execution time,

hosting level

Table 2: Impact of number of microservices on the moni-

toring and contract managers.

# of microservices average execution time in ms

50 709,1

150 2587,3

250 5567,0

350 7837,3

450 11344,7

550 16044,2

650 20823,4

750 27248,6

850 34761,7

950 42227,3

1050 49351,0

Table 3: Impact of number of platforms on the monitoring

and contract managers.

# of platforms average execution time in ms

50 479,7

100 2087

150 4998

200 10116,6

250 15316,4

300 22947,9

350 31323,8

400 39518,9

450 55676,8

500 69392,2

associated with lifecycles allowing to monitor their

progress towards either successful completion or fail-

ure. To demonstrate the technical doability of the con-

tract management approach, a system’s architecture

was ﬁrst, designed identifying the necessary reposi-

tories and managers and then, implemented in Java.

The system supported different experiments examin-

ing for instance, the impact of increasing the number

of microservices on the performance of the system’s

managers.

In term of future work, we would like to exam-

ine contract monitoring and enforcement. On the

one hand, the former would track contract comple-

tion from creation until expiry going through review

and execution. How to assess the performance of con-

tracts and how to proceed with their renewals without

impacting ongoing contracts are some monitoring-

related questions that need to be addressed. To this

end, we plan to develop techniques that could help

for instance, identify reasons of renewals, recommend

amendments to expedite renewals, and predict these

amendments’ (ﬁnancial) impacts on stakeholders. On

the other hand, the latter, contract enforcement, would

ensure the full compliance of all stakeholders with

contracts’ clauses. How to build trust among the

stakeholders for long-term collaboration is a ques-

tion that needs to be addressed. To this end, we plan

to develop techniques that could foster trust and in-

centive/penalize good/bad behaviors of stakeholders

linked to contracts.

REFERENCES

Baker, T., Ugljanin, E., Faci, N., Sellami, M., Maamar,

Z., and Kajan, E. (2018). Everything as a Re-

source: Foundations and Illustration through Internet-

of-Things. Computers in Industry, 94.

Balint, F. and Truong, H. (2017). On Supporting Contract-

aware IoT Dataspace Services. In IEEE Int. Conf. on

Mobile Cloud Computing, Services, and Engineering,

San Francisco, USA.

Brito, M., Cunha, J., and de Sousa Saraiva, J. (2021). Iden-

tiﬁcation of Microservices from Monolithic Applica-

tions through Topic Modelling. In Proceedings of the

36th Annual ACM Symposium on Applied Computing,

Republic of Korea (virtual event).

Butzin, B., Golatowski, F., and Timmermann, D. (2016).

Microservices Approach for the Internet of Things. In

Proceedings of the 21st IEEE Int. Conf. on Emerging

Technologies and Factory Automation, Berlin, Ger-

many.

De Donno, M., Tange, K., and Dragoni, N. (2019). Founda-

tions and Evolution of Modern Computing Paradigms:

Cloud, IoT, Edge, and Fog. IEEE Access, 7.

Khebbeb, K., Hameurlain, N., and Belalab, F. (Novem-

ber 2020). A Maude-based Rewriting Approach to

ICSOFT 2022 - 17th International Conference on Software Technologies

286

Model and Verify Cloud/Fog Self-Adaptation and Or-

chestration. Journal of Systems Architecture, 110.

Lewis, J. and Fowler, M. (2014). Microservices.

Longo, A., Zappatore, M., and Bochicchio, M. (2019). A

Cloud-based Approach to Dynamically Manage Ser-

vice Contracts for Local Public Transportation. In-

ternational Journal of Grid and Utility Computing,

10(6).

Maamar, Z. and Faci, N. (2021). Microservices Deployment

and Execution in a Cloud, Edge, and IoT Conﬁgura-

tion. Technical report, Zayed University.

Marino, F., Moiso, C., and Petracca, M. (2019). Automatic

Contract Negotiation, Service Discovery and Mutual

Authentication Solutions: A Survey on the Enabling

Technologies of the Forthcoming IoT Ecosystems.

Comput. Networks, 148.

Menasc

e, D. A. (2002). QoS Issues in Web Services. IEEE

Internet Computing, 6(6).

Pan, J., Wang, J., Hester, A., AlQerm, I., Liu, Y., and Zhao,

Y. (2019). EdgeChain: An Edge-IoT Framework and

Prototype Based on Blockchain and Smart Contracts.

IEEE Internet Things J., 6(3).

Puliaﬁto, C., Mingozzi, E., Longo, F., Puliaﬁto, A., and

Rana, O. (2019). Fog Computing for the Internet of

Things: A Survey. ACM Transactions on Internet

Technology, 19(2).

Singh, S. (2017). Optimize cloud computations using edge

computing. In IEEE International Conference on Big

Data, IoT and Data Science (BID).

Singh, S., Chana, I., and Buyya, R. (2020). STAR: SLA-

aware Autonomic Management of Cloud Resources.

IEEE Transactions on Cloud Computing, 8(4).

Sun, H., Yu, H., and Fan, G. (2020). Contract-Based Re-

source Sharing for Time Effective Task Scheduling in

Fog-Cloud Environment. IEEE Transactions on Net-

work and Service Management, 17(2).

Truong, H. and Klein, P. (2020). DevOps Contract for As-

suring Execution of IoT Microservices in the Edge.

Internet Things, 9.

Multi-party Contract Management for Microservices

287