A Domain Speciﬁc Language to Provide Middleware for Interoperability

among SaaS and DaaS/DBaaS through a Metamodel Approach

Babacar Mane

, Ana Patricia Magalhaes

2,3

, Gustavo Quinteiro

, Rita Suzana Pitangueira Maciel

and Daniela Barreiro Claro

Formalisms and Semantic Applications Research Group (FORMAS), Federal University of Bahia – DCC – IME,

Av. Adhemar de Barros, Ondina, 40170-110, Salvador, Bahia, Brazil

Department of Exact Sciences and Earth, State University of Bahia, 2555 Silveira Martins st. Cabula, Bahia, Brazil

Post Graduate Program in Computing and Systems, Salvador University, 251 Dr. Jose Peroba st., Bahia, Brazil

Keywords:

Metamodel, Cloud Computing, Model Driven Development, Interoperability.

Abstract:

Cloud Computing (CC) is a paradigm that manages a pool of virtualized resources at infrastructure, platform,

and software levels to deliver them as services over the Internet. Cloud Platforms are heterogeneous, and

therefore cloud users may face interoperability and integration issues regarding consumption, provisioning,

management, and supervision resources among distinct clouds. Due to the lack of standards in such a hetero-

geneous environment, an organization may face a lock-in situation. A middleware can minimize the effort to

overcome lock-in problems. The MIDAS middleware ensures semantic interoperability between Software as

a Service (SaaS) and Data as a Service (DaaS), and at the same times provides data integration between DaaS.

Currently, MIDAS runtime implementations rely on Cloud Foundry, Amazon Web Services, OpenShift and,

Heroku providers. To avoid ambiguity in MIDAS development and deployment an unambiguous deﬁnition of

MIDAS architectural concepts must be provided. Thus, our work presents a Domain-Speciﬁc Modeling Lan-

guage (DSML) comprising a metamodel of MIDAS semantic architecture and a Uniﬁed Modeling Language

(UML) proﬁle. To evaluate the DSML expressiveness, we instantiate several middleware models, and the ﬁnd-

ings demonstrate that our modeling language has an acceptable level of concepts to specify the middleware.

1 INTRODUCTION

Cloud Computing (CC) is a paradigm that manages

a pool of virtualized resources at infrastructure, plat-

form, and software levels to deliver them as services

over the Internet (Shawish and Salama, 2014). These

services are classiﬁed by the National Institute of

Standards and US Technology (NIST) into Software

as a Service (SaaS), Platform as a Service (PaaS), and

Infrastructure as a Service (IaaS) respectively. CC is

organized into three deployment models according to

providers’ access policies (private, public, and hybrid

cloud). Everything in the cloud is considered as a ser-

vice. For instance, a database is provided as a service

(Database as a Service - DBaaS), and Data are also

offered as a service (Data as a Service - DaaS). In

the cloud market, providers are categorized into pro-

prietary and open-source platforms, and each of them

has their application programming interfaces (API),

protocol, and data format to provide their services

(Zhang et al., 2013).

In such a heterogeneous environment, organiza-

tions that migrate their applications or exchange their

data from one provider to another may stay in a lock-

in situation due to the lack of standard solutions.

These situations can occur between the same service

level of distinct clouds caused by horizontal hetero-

geneity (e.g., distinct DaaS or different DBaaS) or

among different service levels of clouds arising from

the vertical heterogeneity (e.g., SaaS and DaaS or

SaaS and DBaaS) (Ranabahu and Sheth, 2010; Sanaei

et al., 2013).

To solve the lock-in situation, portability or in-

teroperability solutions have been proposed (Lewis,

2013; Maciel et al., 2016). Reuven Cohen deﬁnes a

portability solution as the ability to move data or ap-

plication components regardless of the provider’s op-

erating system, storage, data format, or API (Cohen,

2009). Meanwhile, an interoperability solution has

been deﬁned by the Institute of Electrical and Elec-

tronics Engineers (IEEE) as the ability to exchange

and mutually use information among systems. Sys-

Mane, B., Magalhaes, A., Quinteiro, G., Maciel, R. and Claro, D.

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach.

DOI: 10.5220/0010459600830094

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 1, pages 83-94

ISBN: 978-989-758-509-8

tems in different clouds should exchange and operate

data transparently among independent platforms. In-

teroperability provides transparency when exchang-

ing data between multiple clouds and also manag-

ing cloud resources with the same customized tools

(Lewis, 2013). Three levels of interoperability are de-

ﬁned (Maciel et al., 2016): syntactic, semantic and

pragmatic. In a syntactic interoperability context, dif-

ferent applications exchange data or messages to per-

form an activity with a common protocol. A seman-

tic interoperability solution requires meaning on data

exchange to disambiguate each message communica-

tion. A pragmatic interoperability solution ensures

that an intended effect of a message is exchanged be-

tween applications or systems.

DaaS and DBaaS providers store and manage a

high volume of heterogeneous data produced by, for

instance, mobile computing, ubiquitous devices, so-

cial networks, and web-based applications. Such data

are distributed geographically and available to con-

sumers or organizations. However, to access similar

data distributed from distinct DaaS/DBaaS providers,

users from SaaS must connect to each provider at

a time and then use a mechanism (e.g., a program)

to process or aggregate data. For instance, a de-

mographic researcher will do the same thing to get

census data provided by governments from different

DaaS.

To mitigate the vertical heterogeneity issue among

SaaS and DaaS/DBaaS levels, an automated solution

so-called MIDAS (Middleware for DaaS/DBaaS and

SaaS) has been developed as an intermediate com-

munication layer (Mane et al., 2020a; Mane et al.,

2020b). MIDAS allows a cloud user to transform its

request in a single real-time Structured Query Lan-

guage (SQL) or Not Only SQL (NoSQL) query to re-

trieve data at once from distinct DaaS/DBaaS. This

avoids data migration, ensures semantic interoperabil-

ity, and enables DaaS and DBaaS data integration.

Currently, MIDAS runtime implementations are

published on Cloud Foundry, Amazon Web Services,

OpenShift and, Heroku PaaS providers. However, dif-

ferents PaaS offer heterogeneous tools and services

(Gonidis et al., 2013). Thus, to be able to deploy MI-

DAS across multiple PaaS, without lock-in to a partic-

ular vendor, model-based approaches can be exploited

to develop, maintain, and reuse cloud applications.

Our work proposes a Domain-Speciﬁc Model-

ing Language (DSML) for MIDAS architecture with

well-deﬁned syntax and semantics. It enables the

speciﬁcation of the MIDAS platform-independent ar-

chitecture within software components and connec-

tions. The DSML abstract syntax and static seman-

tics are speciﬁed following the Meta-Object Facility

(MOF) metamodel and the concrete syntax using a

UML proﬁle. This DSML assists software project

to guide developers in a model-driven development

project as a base for model transformations (Da Silva,

2015). To evaluate the DSML expressiveness, we in-

stantiate several middleware models, and we conclude

that the modeling language has an acceptable cover-

age level of the concepts to deﬁne a middleware.

The remainder of this paper is organized as fol-

lows: Section 2 presents the State of Art; Section 3

describes some related work; Section 4 depicts our

domain speciﬁc modeling language (DSML); Section

5 presents the metamodel validation; and ﬁnally, Sec-

tion 6 presents the conclusion and future work.

2 BACKGROUND

In this section, we present a brief overview of models

and modeling language concepts.

2.1 Domain Modeling Languages

Model-Driven Development (MDD) is a model-based

approach emerging as one of the leading software en-

gineering approaches employing models as a primary

artifact to maintain the development process on track

and be able to implement an increasingly reliable soft-

ware design (Christensen and Ellingsen, 2016).

Models are abstract representations of a system,

which comprise both the structure and the behav-

ior(Mellor, 2004). In MDD, models are the funda-

mental artifacts, and they produce other models as

well as the application source code. Models must be

speciﬁed according to a modeling language with well-

deﬁned syntax and semantic. A model is a set of el-

ements describing some aspects of a system with an

abstraction level, and it is a real authentic representa-

tion simpliﬁed and contextualized (Mellor, 2004). In

MDD, models are more than documentation; they fa-

cilitate and improve communication among technical

and non-technical stakeholders by sharing the same

vision and knowledge. During the systems develop-

ment process, the model concept provides a product

that is easier to understand through its graphical rep-

resentations.

In MDD, modeling languages are employed to

specify models graphically, textually, or both, and

they are always based on speciﬁc domain require-

ments in use. These languages are classiﬁed into two

categories: one is speciﬁed to a domain (a knowl-

edge area), called DSML (Domain-Speciﬁc Model-

ing Language) and, the other is a general-purpose,

called GPL (General Purpose Languages), such as the

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

Uniﬁed Modeling Language (UML) (Da Silva, 2015).

GPL is widely used in different application ﬁelds and

provides a higher number of generic constructs in-

stead of DSMLs that use a few constructs or con-

cepts tailored to the needs of a speciﬁc application

domain and make models more expressive. For each

application domain, it is often necessary to create a

new DSML; thus, this task can generate a new lan-

guage implementing, maintaining, and learning cost.

A General-Purpose Language (e.g., UML) can be cus-

tomized for speciﬁc domains based on the speciﬁca-

tion of proﬁles and does not change the original se-

mantic elements. A proﬁle deﬁnition comprises the

speciﬁcation of stereotypes, meta-classes, and labeled

values.

Modeling languages formally write models with

a well deﬁned syntax and semantic, and are com-

posed of four main elements: abstract syntax, con-

crete syntax, static semantics, and dynamic semantics

(Da Silva, 2015).

• Abstract Syntax: this conceptualizes, and synthe-

sizes the application domain knowledge by iden-

tifying concept names close to the application

domain and by establishing particular relations

among them. Language constructors are deﬁned

in the abstract syntax;

• Concrete Syntax: This is either textual or graph-

ical. The graphical concrete syntax is often de-

ﬁned by the structure of the abstract syntax and

a set of graphical representations for classes and

associations in the abstract syntax (Herrera et al.,

2016). It deﬁnes how abstract syntax features are

presented to users (e.g., UML proﬁle);

• Static Semantics: Constraints and rules deﬁne re-

lations among concept names to ensure static se-

mantics. The Object Constraint Language (OCL)

is a declarative constraint language that is the

most used in this case

;

• Dynamic semantics: This deﬁnes how instanti-

ated models are executed.

In MDD, the abstract syntax and static semantics of

a DSML is usually expressed in terms of metamod-

els. According to OMG

a metamodel is a model of

models. Models built along the MDD-based software

development process are metamodel instances, and

should always be in accordance with their metamodel.

Models must satisfy restrictions deﬁned by the meta-

model and should be syntactically correct concerning

the metamodel. Through a metamodel we can doc-

ument our models, reuse, debug and execute them

without its source code.

https://www.omg.org/spec/OCL/

https://www.omg.org//

3 RELATED WORK

Diversities of the cloud PaaS environment (a set

of application framework, runtime environment, and

programming languages) do not permit multi-cloud

applications development and deployment from one

cloud to another. Solutions to mitigate lock-in issues

in the cloud can face a challenge when deploying or

implementing them in another cloud. A way to solve

this issue is to employ model-based approach features

to simplify solutions design, management, and mi-

gration across multiple clouds. In this section, we

highlight some works from researchers who have at-

tempted to solve the same problem.

Researchers in (Merle et al., 2015) propose a

metamodel for Open Cloud Computing Interface

(OCCI) to ensure interoperability at IaaS, PaaS and

SaaS levels. OCCI core concepts are speciﬁed in nat-

ural language and interpreted in various ways during

their implementation. To avoid an imprecise, ambigu-

ous, and incomplete OCCI speciﬁcation, the static se-

mantic of the OCCI metamodel is deﬁned in the Ob-

ject Constraint Language (OCL). This proposes a pre-

cise type classiﬁcation system, an extensible datatype

system, both extension and conﬁguration concepts.

Authors in (Zalila et al., 2019; Zalila et al., 2017) then

extends the previous work of (Merle et al., 2015) pro-

viding an OCCIware approach to allow design, val-

idate, generate, implement, deploy, execute, and su-

pervise everything as a service with OCCI.

Cloud Modelling Framework (CloudMF) (Ferry

et al., 2018) is another approach relying on a model-

driven concept to simplify the complexity of main-

taining and evolving complex applications potentially

deployed across multiple cloud platforms. CloudMF

captures cloud applications provisioning and deploy-

ment in platform-independent models and automates

their operations and adaptations through a models at

run-time environment. The Cloud Application Mod-

elling Language (CAML) (Bergmayr et al., 2014)

is a UML internal language developed during the

ARTIST EU project to represent cloud-based deploy-

ment topologies, and to capture cloud environment-

speciﬁc information from different perspectives with

a set of UML proﬁles. Following the PIM/PSM con-

cept in the MDA framework, CAML manages to sep-

arate cloud-provider into independent and speciﬁc de-

ployment models. CAML does not provide a runtime

environment to perform the multi-cloud application

deployment. There are some conﬁguration manage-

ment tools such as Cloudify

, Puppet

, Chef

, and

https://cloudify.co/

https://puppet.com/

https://www.chef.io/products/chef-infra/

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach

Ansible

providing Domain Speciﬁc Modeling Lan-

guage (DSML) to facilitate the speciﬁcation of an ap-

plication’s conﬁgurations, services, their dependen-

cies, deployment, monitoring, adaptation, and execu-

tion plans, without employing a language-dependent

of platform.

In contrast to the metamodel architecture of MI-

DAS, the approaches mentioned above are con-

ceived DSML automatically or semi-automatically

from design-time to the run-time to allow multi-cloud

applications to deploy from a particular cloud to an-

other. Our work provides a DSML to specify the MI-

DAS independent platform that can generate code in

any speciﬁc platform.

4 OUR DOMAIN SPECIFIC

LANGUAGE

To address the MIDAS deployment or development

issue across multiple clouds, we rely on the MDD ap-

proach to simplify MIDAS’ design, implementation,

and migration from one cloud to another. This section

presents MIDAS DSML for the speciﬁcation of MI-

DAS middleware models independent of the platform.

The abstract syntax and static semantic of our DSML

are speciﬁed in the metamodel presented in (Section

4.2), and the concrete syntax is represented as a UML

proﬁle in (Section 4.3). This language makes it possi-

ble to deﬁne models independent of the platform us-

ing UML diagrams. First, we provide an introduction

to the MIDAS architecture.

4.1 MIDAS Architecture

To mitigate vertical heterogeneity issues among SaaS

and DaaS/DBaaS, an automated solution so-called

MIDAS (Middleware for DaaS/DBaaS and SaaS) has

been developed as an intermediate communication

layer to allow the retrieval of data from DaaS or

DBaaS through a single real-time Structured Query

Language (SQL) or Not Only SQL (NoSQL) (Mane

et al., 2020a; Mane et al., 2020b). This solution

avoids data migration, and ensures semantic interop-

erability among SaaS and DaaS/DBaaS and, data in-

tegration among DaaS and/or DBaaS.

MIDAS is developed in two phases following the

interoperability types classiﬁcation: syntactic and se-

mantic. The MIDAS syntactic interoperability is

composed of three modules (Request, Data, and Re-

sult), a Dataset Information Storage (DIS), and an ex-

ternal Crawler to update DIS. To provide a semantic

https://www.ansible.com/

solution in MIDAS, a (semantic) module is appended

to the syntactic interoperability. Figure 1 shows the

syntactic and semantic architecture of MIDAS.

Figure 1: MIDAS Architecture.

The Request Module Query Decomposer component

receives users queries from SaaS providers, breaks

them into terms, and sends results to the Query

Builder component to build DaaS APIs. Before set-

ting DaaS APIs, the Query Builder component always

check terms consistency accessing Dataset Informa-

tion Storage (DIS) storing DaaS APIs information.

If some terms are different, it accesses the Semantic

Module Storage database to ﬁnd terms which are se-

mantically similar. After that, DaaS APIs are send to

be performed by the Request Module Query Execute

component and the results are forwarded to the Result

Module Filtering component. If user requests contain

a Join SQL or a lookup NoSQL clause allowing users

to get data from more than one DaaS or DBaaS, the

Data Module Data Join component aggregates the

results of DaaS APIs executed, and send them to the

Filtering component.

The Data Module Data Mapping component re-

ceives DBaaS query terms from the Query Builder

component decomposed and datasets credentials

stored in DIS to build DBaaS APIs and execute them

at the corresponding DBaaS. If join SQL or lookup

NoSQL clause are employed in user queries, data are

aggregated by the Data Join component and sent to

the Filtering component to be ﬁltered. Otherwise,

data are sent directly to the Filtering component.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

The Filtering component can receive data from the

components Data Join, Query Execute or Data Map-

ping to be ﬁltered. This component is responsible

for removing some irrelevant attributes (e.g., id) be-

fore sending the data to the Formatter component to

be formatted into comma-separated-values (csv), Ex-

tensible Markup Language (xml) or JavaScript Object

Notation (json) format. Result Module manages in-

distinctly users data from DBaaS or DaaS.

The Mapping component of Semantic Module

shares DIS database with Query Builder component

to manage APIs attributes evolution. Each time the

DIS database is updated by the MIDAS Crawler, the

Mapping component identiﬁes the semantic similar-

ity between old and new DaaS attributes evolution

and it stores the results in the Storage component in

a tree data structure. The Crawler is out of MIDAS’

architecture, and it is developed to maintain and up-

date semi-automatically DIS database. A temporary

data structure is created to store users’ terms query

change in order to allow the Formatter component to

send data to the user with the parameters deﬁned in

the original query.

Currently, MIDAS runtime implementations are

published on Cloud Foundry, Amazon Web Services,

OpenShift and, Heroku PaaS providers. However,

different PaaS offer heterogeneous tools and services

(Gonidis et al., 2013). To be able to deploy MIDAS

across multiple PaaS, without lock-in to a particular

vendor, model-based approaches can be exploited to

develop, maintain, and reuse cloud applications.

4.2 MIDAS Architecture Metamodel

This section presents our metamodel to represent the

semantic interoperability domain. It is deﬁned in the

M2 layer of the OMG model, and is organized into

one package as shown in Figure 2. The metamodel is

speciﬁed following the Meta-Object Facility (MOF)

meta-metalanguage (OMG layer M3), and will be de-

scribed in detail in the following subsection.

The MIDAS semantic architecture metamodel is

implemented on the Eclipse Modeling Framework

(EMF), and it provides a metamodeling technology

called Ecore to encode the metamodel structure. It

is inspired by the OMG Model-Driven Architecture

(MDA)

, and it represents the Platform-Independent

Model (PIM). It is agnostic to any development

paradigm and technology, and it enables developers to

implement their software by choosing their preferred

programming languages and frameworks.

https://www.omg.org/mda/

Figure 2: MIDAS architecture metamodel representation at

different levels of abstraction.

4.2.1 Metamodel of the MIDAS Semantic

Architecture

Our metamodel of the MIDAS is depicted in Figure

3. It comprises the concepts (as classes) and their cor-

responding properties according to the domain of a

semantic interoperability middleware.

In the context of semantic interoperability, a Mid-

dleware (Middleware class in Figure 3) has a name

(middlewareName attribute) and can be specialized

into two types: APIData, and Module.

The APIData exhibits the DaaS/DBaaS provider

information, and it is associated to several sets

of attributes (e.g., search path, query param, ﬁl-

ters param, newFields param in class Attribute)

identiﬁed by the attribute (domain). A module rep-

resents MIDAS functionalities. The four main types

of module are Request, Data, Result, and Semantic.

Each type expresses a MIDAS functionality:

• Request Module: Identiﬁes by the propriety re-

questName, and it transforms the user query into

API links;

• Data Module: Manages data from user queries,

and it has dataName as its attribute, to identify it;

• Result Module: It has a name (resultName at-

tribute), and it formats data accordingly to users

requests;

• Semantic Module: This is identiﬁed by the pro-

priety semanticName, and it manages DaaS at-

tributes updating in APIData to identify semantic

similarity between previous and new attributes so

as to execute transparently user queries.

The Request Module is composed by a QueryDe-

composer, a QueryBuilder, and a QueryExecute, rep-

resented as class. The QueryDecomposer decom-

poses user query in terms, and it has three properties

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach

Figure 3: Metamodel of the MIDAS semantic architecture.

a query, a queryType, and a resultsFormat. The query

represents user query, the queryType deﬁnes its type

(e.g., Structured Query Language, or MongoDB), and

the resultsFormat exhibits the data formatted type

provided by the user (e.g., csv, json, or xml). Users

can choose the data type format they wish to re-

ceive. The queryType value deﬁnes how to decom-

pose a user query in terms. The QueryBuilder veriﬁes

the user query terms compatibility with DaaS/DBaaS

providers information represented by APIData be-

fore building an API link. This has eight proper-

ties selectParameters, fromDataset, whereConditions,

joinType, orderbyCondition, joinDatasets, joinCon-

ditions, and limitCondition representing user query

terms. The class QueryExecute has two properties

apiWithJoin, and apiWithoutJoin to represent two

types of APIs links: an API link from a user query

formulated without Join clause (apiWithoutJoin), and

a set of APIs links gained from a user query with

Join clause (apiWithJoin). An enumeration class

named SQLQueryEntryKind is created to deﬁne the

two types of a user query: Structured Query Language

(SQL) and MongoDB.

The Data Module comprises a DataJoin, and

a DataMapping, represented as classes. The class

DataMapping has four attributes databaseName,

password, userName, and apiDBaaS. It is respon-

sible for building DBaaS API and executing them

to get data from DBaaS providers. The properties

password, and userName represent user credentials,

and databaseName the database name. The attribute

apiDBaaS represents DBaaS APIs formatted by the

DataMapping. The DataJoin class aggregates data

obtained from API Links (apiWithJoin attribute, and

apiDBaaS).

The Result Module consists of a (Filter, and a

Formatter) represented as class. The Filter has one

propriety attributesValues, which represents data col-

lected from DaaS/DBaaS providers. Some unneces-

sary data parameters are removed for user informa-

tion. The Formatter has four attributes the queryFor-

mat, the attributesValuesFormatted, the attributesVal-

uesFilters, and the previous param. The attributes-

ValuesFilters represents data ﬁltered by the Filter, and

the queryFormat exhibits three types of data format

(e.g., csv, json or xml). Previous param represents

user query terms identiﬁed in the QueryBuilder as

incompatible with DaaS/DBaaS represented by AP-

IData. To return the query result conform request

by the user with the same parameters, these terms

are used to format data ﬁltered. The attribute at-

tributesValuesFormatted represents the data format-

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

ted in one of the format types represented by the

attribute queryFormat. An enumeration class

named ResultOutPutKind is created to deﬁne three

types of data format: CSV, JSON, and XML.

SemanticMapping manages the attributes of

DaaS evolution represented in APIData to avoid mis-

matching with user query terms. SemanticMap-

pingStorage organizes these attributes per DaaS.

The SemanticMapping has three properties currentAt-

tribute, previousAttribute, and daaSDomain. The

currentAttribute, and previousAttribute represents se-

mantically similar attributes, and the daaSDomain at-

tribute exhibits DaaS domain. The SemanticMap-

pingStorage has three attributes current Attribute,

previous Attribute, and daaS Domain that organize

for each DaaS domain, semantically similar attributes

to maintain user requests transparent. This new or-

ganization allows the QueryBuilder class to format

API links even when there is a mismatch among user’

query terms and attributes represented by the API-

Data class. To do this, the QueryBuilder class has

one more property (newFields) that represents the se-

mantic similar attributes with user query terms. The

Formatter class has more than one propriety previ-

ous param to assign user terms incompatible with at-

tributes represented in the APIData class. This prop-

erty can format the user’s data with the previous pa-

rameters deﬁned in the query.

4.3 UML Proﬁle of the Metamodel of

MIDAS

This section presents the concrete syntax of our lan-

guage, speciﬁed as a UML proﬁle. A UML proﬁle

is an extension mechanism deﬁning domain-speciﬁc

languages using UML concepts. The deﬁnition of the

UML proﬁle named pmidas contains the stereotypes

speciﬁcation, metaclass and labeled values. Stereo-

types are labels that can be applied to various UML el-

ements, and extend metaclass representing UML con-

cepts to which the stereotypes can be applied. Finally,

the labeled values assign values to the extended UML

concepts. Terminologies, syntax, and notations are

introduced to provide additional semantics for exist-

ing concepts. Furthermore, new meta-attributes (tar-

get values), new meta-associations, and new meta-

enumeration are deﬁned. This extension mechanism

does not allow modiﬁcation of the underlying meta-

model.

The stereotypes names in the UML proﬁle pmi-

das are practically maintained in relation to MIDAS

metamodel concepts. For instance, the QueryDecom-

poser concept of MIDAS metamodel corresponds to

the QueryDecomposer stereotype of the pmidas

proﬁle applied to class metaclass. The pmidas

proﬁle is deﬁned in the pmidas package, illustrated in

Table 1.

Table 1 shows the corresponding stereotypes cre-

ated, and the metaclass in which the stereotype can be

applied during development.

Table 1: Stereotypes and their instantiated metaclass.

Stereotypes Metaclass

QueryDecomposer, QueryBuilder, QueryExecute Class

APIData, Attributes, DataMapping, DataJoin Class

SemanticMapping, SemanticMappingStorage Class

Formatter, Filter Class

queryDecomposed, getApis, dBaaSParameters Association

getResultsDBaaSWithJoin, getResultsDBaaS Association

getOldFields, getResultsWithoutJoin Association

AttributesAndValues, AttributesValuesFiltered Association

getAttributesfromData, getResultsWithJoin Association

semanticData, getDaaSParameters Association

getSemanticMappingStorage Association

SQLQueryEntryKind, ResultOutPutKind Enumeration

Our metamodel which represents the semantic inter-

operability of MIDAS architecture will be evaluated

qualitatively instantiating its models.

5 VALIDATION

The DSML proposed in this work comprises a meta-

model, and a UML proﬁle. Unlike programs, meta-

models are not executable artifacts, thus validation

cannot be performed using test cases (Magalh

aes

et al., 2015). The expressiveness of a modeling lan-

guage is usually assessed instantiating models accord-

ing to its metamodel. The DSML is said to be expres-

sive when it represents user requirements in a natural

way to software developers. The concept expressive-

ness measures whether the expressivity concepts lev-

els are enough to capture the main aspects of MIDAS

middleware.

This section presents the assessment of the MI-

DAS DSML expressiveness. The validation goal is

summarized using the GQM (Van Solingen et al.,

2002) template as follows:

• Analyze the MIDAS DSML;

• For the purpose of evaluating expressiveness;

• With respect to coverage of the DSML construc-

tors;

• From the perspective of software developers;

• In the context of the existing metamodel of MI-

DAS.

The questions underlying the validation are:

• Q1: Are the DSML constructors sufﬁcient to

specify aspects of semantic interoperability in the

middleware?

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach

• Q2: Are the selected UML diagrams sufﬁcient to

represent the middleware?

We use several measures as dependent variables: the

number of constructors used, the need for new con-

structors, the number of existing changes in the con-

structors, and the UML diagrams used. The construc-

tor may be represented by classes, associations among

classes or attributes. The validation process lasted one

month and was performed by a researcher who has

more than three years of experience on the MDD ap-

proach, and a knowledge of middleware concepts. It

consists of the use of MIDAS DSML to deﬁne current

middlewares.

Three scenarios with three types of user query

are deﬁned to validate our models: a user query in

a SQL statement, a user query in MongoDB, and a

user query in a SQL statement with a join clause. We

describe each of them below:

1: A User Query with SQL Statement.

• User Request: SELECT id, name, address, city

FROM nyc-wiﬁ-hotspot-locations WHERE city

= ”New York” ORDER BY id LIMIT 1

This user’s request obtains from the DaaS provider

(nyc-wiﬁ-hotspot-locations), the id, the name, and the

address of every wiﬁ hotspot located in New York.

The number of records needed is limited to one, and

is classiﬁed by values of the parameter id.

This user request retrieves from DaaS provider

(nyc-wiﬁ-hotspot-locations), the id, the name, and the

address of every wiﬁ hotspot located in New York.

The number of records is limited to one, and it is clas-

siﬁed by values of the parameter id. As the DaaS

provider nyc-wiﬁ-hotspot-locations parameter name

is updated to names, the user’s query term name must

be changed to names in MIDAS.

Figure 4 shows the instance represented in

a class diagram stereotyped using our proﬁle.

To facilitate readability in this model we named

class with the same name as the stereotype, but

this is not necessary. So, three properties of

QueryDecomposer stereotype represent query =

”SELECT id, name, address, city FROM nyc-wiﬁ-

hotspot-locations WHERE city = ”New York” OR-

DER BY id LIMIT 1”, queryType = ”SQL”, and re-

sultsFormat =”JSON”).

The user’s query is decomposed into terms and

they are assigned to ﬁve properties deﬁned in the

QueryBuilder stereotype (selectParameters=”id,

name, address, city”, whereConditions=”city=”New

York””, orderbyCondition=”id”, limitCondition=1,

and fromDataset=”nyc-wiﬁ-hotspot-locations”). The

compatibility of these terms are veriﬁed in the nyc-

wiﬁ-hotspot-locations DaaS parameters represented

in the APIData stereotype. It was found that

the term name is evolved to the term names in the

nyc-wiﬁ-hotspot-locations DaaS, and it is managed

by the SemanticMapping stereotype with their

three properties (currentAttribute=”names”, previ-

ousAttribute=”

name”, and daaSDomain=”nyc-wiﬁ-hotspot-

locations”), and it organizes by the

SemanticMappingStorage through their

three attributes (current Attribute=”names”, pre-

vious Attribute=

”name”, and daaS Domain=”nyc-wiﬁ-hotspot-

locations”). The ”nyc-wiﬁ-hotspot-locations” DaaS

API is created with the value of the attribute cur-

rent Attribute represented by the QueryBuilder

stereotype property (new Fields=”names”).

The QueryExecute stereotype represent the

API Link with its propriety (apiWithoutJoin =

"https://data.nyc-wifi-hotspot-locations.

com/ browser?dataset=data.nyc-wifi-hotspot-

locations&fields=id,names,address,city").

The data obtained from the API Link are rep-

resented by Filter stereotype attribute

(attributesValues="["id":"1359", "name":"

Metropolitan Museum of

Art","address":"1000 Fifth Avenue",

"city":"New York"]"). The ”id” parameter is

removed for a better understanding of the data by

the user. Formatter stereotype formats the data

in the type represented by (queryFormat=”JSON”),

and it exchanges the attribute ”names” repre-

sented by QueryBuilder stereotype propriety

(new Fields=”names”) with the attribute ”name” rep-

resented by the propriety (previous param=”name”).

The user data formatted is represented by the attribute

(attributesValuesFormatted=””name”:”

Metropolitan Museum of Art”,”address”:”1000 Fifth

Avenue”,”

city”:”New York””).

The user query is a request to get data from

one DaaS, and does not deﬁne a join clause in

statement. For this reason, DataJoin stereo-

type and DataMapping stereotype are not

described in this section. DataJoin stereotype

aggregate data from DaaS/DBaaS providers, and the

DataMapping stereotype get data from DBaaS

providers.

2: A User Query with MongoDB Statement.

This user request is a conversion of the user request

previously deﬁned in SQL format to a MongoDB

query. In this case, the user should get the same result

obtained by the SQL query. The DaaS provider nyc-

wiﬁ-hotspot-locations is updated, and the parameter

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

Figure 4: Executing user SQL query.

name is change to names.

• User Request: db.nyc-wiﬁ-hotspot-

locations.ﬁnd(”city”: ”New York”, ’id’:

1, ’name’: 1, ’address’: 1, ’city’:

1).limit(1).sort(’id’: ’);

We employed models in Figure 4 to test the user

MongoDB query. This model shows the instance

represented in a class diagram stereotyped using our

proﬁle, and the name of classes are the same as the

stereotype to facilitate readability. The execution

process is the same as performed by the user SQL

query. The classes stereotype and attributes used to

execute user SQL query is the same as employed by

the user MongoDB query. It is worth mentioning that

in the QueryBuilder stereotype the properties

used to represent the user SQL query terms are the

same as those employed for the user MongoDB query

terms. This is possible to identify the equivalence of

clause statements between the two types of query.

3: A User Query with SQL Statement Employing

join Clause.

This user SQL query retrieves user name, email, and

ages that have the same cpf from the three DaaS

(DaaS1, DaaS2, and DaaS3). We observe that the

term ages is evolved to age in the DaaS3 provider.

• User Request: SELECT DaaS1.name,

DaaS2.email, DaaS3.ages FROM DaaS1 INNER

JOIN DaaS2 ON DaaS2.cpf = DaaS1.cpf IN-

NER JOIN DaaS3 ON DaaS3.cpf = DaaS1.cpf;

The user’s query is decomposed into terms

and assigned to ﬁve properties deﬁned in the

QueryBuilder stereotype (selectParame-

ters=”DaaS1.name, DaaS2.email, DaaS3.ages”,

joinType=”INNER JOIN, INNER JOIN”, join-

Datasets=”DaaS2,DaaS3”, joinConditions=”

DaaS2.cpf = DaaS1.cpf, DaaS3.cpf = DaaS1.cpf ”,

and fromDataset=”

DaaS1”).

The compatibility of these terms are veriﬁed in

DaaS1, DaaS2 and DaaS3 parameters represented in

the APIData stereotype. It was found that the

term DaaS3.ages is evolved to the term DaaS3.age

in the DaaS3. Therefore, this term is managed by

the SemanticMapping stereotype with their

three properties (currentAttribute=”age”, previousAt-

tribute=”ages”, and daaSDomain=”

data.ﬁpe-parallelum.rhcloud.com”), and organized

by the

SemanticMappingStorage through three at-

tributes

(current Attribute=”age”, previous Attribute=

”ages”, and daaS Domain=”data.ﬁpe-

parallelum.rhcloud.com”). The attribute newFields

deﬁned in the QueryBuilder stereotype repre-

sents the new term ”age”. The three APIs links are

represented by the propriety aPILinkDaaS in the

QueryExecute stereotype Table 2:

In the DataJoin stereotype, results from

the three API links are represented by the attributes

resultDaaS. These data are aggregated in the Filter

stereotype, and represented by the propriety re-

sultsDaaS= ”” id: Objectid(”4578”), ’name’:’Jo

ao’,

’email’:’dao@ufba.br’,

’age’:’20’,” id: Objectid(”4589”)’name’:’Maria’,

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach

Table 2: Three APIs links.

https://data.ﬁpe-parallelum.rhcloud.com/browser?dataset=DaaS3&ﬁelds=age,cpf

https://data.cityofnewyork.us/browser?dataset=DaaS2&ﬁelds=email,cpf

https://data.public.opendatasoft.com/browser?dataset=DaaS1&ﬁelds=name,cpf

’email’:’lia@ufba.br’,’age’:

’20’”. The id parameter is removed from

the data to make the information understand-

able for the user. The result is represented

by the attribute resultsFiltered=’name’:’Jo

ao’,

’email’:’dao@ufba.br’,’age’:’20’,”name’:’Maria’,

’email’:’lia@ufba.br’,’age’:’20’ in the

ResultFormatter stereotype. The previous

term of DaaS3, ages is recovered and replace the

term age. The user query ﬁnal result is represented

by the ResultFormatter stereotype propriety

resultsFormatted=’name’:’Jo

ao’, ’email’:’dao@

ufba.br’,’ages’:’20’,’name’:’Maria’,

’email’:’lia@ufba.br’,’age’:’20’ in a JSON for-

mat speciﬁed by the attribute resultFormat=”JSON”.

Figure 5 shows the number of constructors (classes,

associations, and attributes) employed to perform the

user query. Compare to Figure 4, we have a new

class named DataJoin stereotype to perform

terms belonging to the user query Join. None of the

three user queries employed the DataMapping

stereotype to not specify a DBaaS provider

in their requests. Each attribute deﬁned in the

QueryBuilder stereotype is related to the name

of a clause stated in the user SQL query.

Related to question Q1, the results obtained exe-

cuting the three types of user queries deﬁned above

allow us to append and separate some MIDAS DSML

constructors. Classes as the QueryExecute is ap-

pended to our metamodel, the DataJoin are separated

from the DataMapping to only aggregate data from

DaaS/DBaaS providers, and the class deﬁned in the

Result Module is broken down into two classes: the

Filter and the Formatter.

The QueryExecute class is created to manage

DaaS’ API links built by the QueryBuilder class. The

DataJoin class is constructed to handle data from

DaaS/DBaaS’ API links built according to a user

query with Join or lookup clause. The DataMapping

is responsible for building DBaaS APIs and getting

data from DBaaS providers. The Filter class removes

some unnecessary data parameters for easier to user

understanding, and the Formatter class is responsible

to format the user data into JSON, XML or CSV type.

Besides the creation of classes SemanticMap-

pingStorage, and SemanticMapping stereotype

to handle the semantic interoperability con-

cept in our metamodel, three properties pre-

vious

param=”name”, newFields, and new-

Fields param are deﬁned respectively in the

Formatter, QueryBuilder, and Attributes.

News associations are created among the

QueryExecute and the two classes: DataJoin

and Filter. We also have an association between

QueryExecute and QueryBuilder class. The di-

vision of the class deﬁned in the Result Module

established a new association between the Filter

and the Formatter class. Two news properties

previous param=”name”, and newFields deﬁned

respectively in Formatter, and QueryBuilder create

association relations among SemanticMappingStor-

age and the two classes Formatter and QueryBuilder.

The attribute newFields param deﬁned in the At-

tributes class establishes an association relation

between the Attributes class and the SemanticMap-

ping.

Related to question Q2, the UML class diagram

adopted by our proﬁle was sufﬁcient to specify in-

stantiation of the syntactic, and semantic aspects of

the user query. Therefore, we consider that the DSML

was stable to be used.

We conclude that the MIDAS DSML constructors

are sufﬁcient to specify the middleware and stable

enough to be employed. The examples used covered

the concepts needed within DSML. For now, they no

longer need to be changed or added within DSML.

This may happen in the future to change or accom-

modate some concepts that the examples did not con-

template. The expressiveness of the language is eval-

uated according to the level of comprehension of the

language constructors. This means we assess whether

the deﬁned metamodel presented the necessary con-

cepts to instantiate the models. We know that our val-

idation results are limited, and the application of the

DSML in other scenarios is necessary to improve the

approach.

6 THREATS TO VALIDITY

Some threats of validity were identiﬁed in this process

validation. This section describes threats to internal

validity, external validity, and construction validity.

Internal Validity. Threats to internal validity are

related to the possibility of uncontrolled factors in-

ﬂuencing our results. The participant’s experience

can be decisive in the metamodel validation. The

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

Figure 5: Executing user’s SQL query with join clause.

expert who is responsible for validating the DSML

expressiveness has more than three years experience

with the MDD approach, and knowledge in middle-

ware and cloud computing concepts. Therefore, the

threats related to the participant’s level of experience

are quite few.

External Validity. Threats to external validity are re-

lated to the possibility of generalizing the results to

other participants than the expert. MDD is a recent

approach relevant in some areas of development in the

industry, and academia (Whittle et al., 2013). How-

ever, as it is a recent approach and therefore requires

a specialized proﬁle, it is difﬁcult to ﬁnd a partici-

pant with experience in MDD approach, middleware,

and cloud computing concepts. It is necessary to con-

ﬁrm the results obtained using a participant with ex-

perience in the MDD approach, middleware but not in

MIDAS, and in cloud computing concept.

Construction Validity. The construction threats to

the validity are related to the measures employed by

the expert, whether they really represent what is in-

tended to be evaluated. Assessing the DSML expres-

siveness is not a trivial task, as it involves partici-

pants performing tasks. As a consequence, the eval-

uation depends on the experience of each participant

in MDD approach, middleware and cloud computing

concepts.

Despite all these threats, efforts were made to

avoid bias in this validation process.

7 CONCLUSION AND FUTURE

WORK

In this paper, to enable implementing, running, and

deploying MIDAS on a large scale despite the diver-

sity of some cloud development and runtime environ-

ment characteristics, we propose a MIDAS Domain-

Speciﬁc Modeling Language (DSML) comprised of

the metamodel of MIDAS semantic architecture and

the Uniﬁed Modeling Language (UML) proﬁle. The

metamodel enables the instantiation of platforms in-

dependent models, and provides a portability solu-

tion for MIDAS to be develop and run on distinct

cloud providers without creating a lock-in situation.

Through the metamodel of MIDAS, we can document

our models, reuse, debug and perform our artifacts

without ending implementation. Models are key ar-

A Domain Speciﬁc Language to Provide Middleware for Interoperability among SaaS and DaaS/DBaaS through a Metamodel Approach

tifacts to keep the development process on track and

to implement increasingly reliable software design.

To evaluate the DSML expressiveness, we exe-

cuted three types of query, and our results show that

modeling language has an acceptable coverage level

of concepts to deﬁne the middleware. In future work,

we plan to perform a controlled experiment to analyze

the consistency, correctness, completeness, and devel-

opment time to obtain MIDAS source code from the

metamodel of MIDAS architecture.

REFERENCES

Bergmayr, A., Troya Castilla, J., Neubauer, P., Wimmer,

M., and Kappel, G. (2014). Uml-based cloud ap-

plication modeling with libraries, proﬁles, and tem-

plates. In CloudMDE 2014: 2nd International Work-

shop on Model-Driven Engineering on and for the

Cloud co-located with the 17th International Confer-

ence on Model Driven Engineering Languages and

Systems (MoDELS 2014)(2014), p 56-65. CEUR-WS.

Christensen, B. and Ellingsen, G. (2016). Evaluat-

ing model-driven development for large-scale ehrs

through the openehr approach. International journal

of medical informatics, 89:43–54.

Cohen, R. (2009). Examining cloud compatibility, portabil-

ity and interoperability. http://www.elasticvapor.com/

2009/02/examining-cloud-compatibility.html. On-

line; Accessed: 2016-12-13.

Da Silva, A. R. (2015). Model-driven engineering: A sur-

vey supported by the uniﬁed conceptual model. Com-

puter Languages, Systems & Structures, 43:139–155.

Ferry, N., Chauvel, F., Song, H., Rossini, A., Lushpenko,

M., and Solberg, A. (2018). Cloudmf: model-driven

management of multi-cloud applications. ACM Trans-

actions on Internet Technology (TOIT), 18(2):1–24.

Gonidis, F., Simons, A. J., Paraskakis, I., and Kourtesis,

D. (2013). Cloud application portability: an initial

view. In Proceedings of the 6th Balkan Conference in

Informatics, pages 275–282.

Herrera, A. S.-B., Willink, E. D., and Paige, R. F. (2016).

A domain speciﬁc transformation language to bridge

concrete and abstract syntax. In International Con-

ference on Theory and Practice of Model Transforma-

tions, pages 3–18. Springer.

Lewis, G. A. (2013). Role of standards in cloud-computing

interoperability. In System Sciences (HICSS), 2013

46th Hawaii International Conference on, pages

1652–1661. IEEE.

Maciel, R. S. P., David, J. M. N., Claro, D. B., and Braga, R.

(2016). Full interoperability: Challenges and opportu-

nities for future information systems. I GranDSI-BR,

page 107.

Magalh

aes, A. P., Maciel, R. S. P., and Andrade, A. M. S.

(2015). Towards a metamodel design methodology:

Experiences from a model transformation metamodel

design. In SEKE, pages 625–630.

Mane, B., Rocha, W. d. S., Lima, E., and Claro, D. B.

(2020a). Semantic similarity attributes for data cloud:

A case study in midas. In Proceedings of the Brazilian

Symposium on Multimedia and the Web, pages 89–96.

Mane, B., Rocha, W. d. S., Ribeiro, E. L. F., Jesus, L.

E. N. d., Motta, I. C., Lima, E., and Claro, D. B.

(2020b). Enhancing semantic interoperability on mi-

das with similar daas parameters. In XVI Brazilian

Symposium on Information Systems, pages 1–8.

Mellor, S. J. (2004). MDA distilled: principles of model-

driven architecture. Addison-Wesley Professional.

Merle, P., Barais, O., Parpaillon, J., Plouzeau, N., and Tata,

S. (2015). A precise metamodel for open cloud com-

puting interface. In 2015 IEEE 8th International Con-

ference on Cloud Computing, pages 852–859. IEEE.

Ranabahu, A. and Sheth, A. (2010). Semantics centric solu-

tions for application and data portability in cloud com-

puting. In Cloud Computing Technology and Science

(CloudCom), 2010 IEEE Second International Con-

ference on, pages 234–241. IEEE.

Sanaei, Z., Abolfazli, S., Gani, A., and Buyya, R. (2013).

Heterogeneity in mobile cloud computing: taxonomy

and open challenges. IEEE Communications Surveys

& Tutorials, 16(1):369–392.

Shawish, A. and Salama, M. (2014). Cloud computing:

paradigms and technologies. In Inter-cooperative

Collective Intelligence: Techniques and Applications,

pages 39–67. Springer.

Van Solingen, R., Basili, V., Caldiera, G., and Rombach,

H. D. (2002). Goal question metric (gqm) approach.

Encyclopedia of software engineering.

Whittle, J., Hutchinson, J., and Rounceﬁeld, M. (2013). The

state of practice in model-driven engineering. IEEE

software, 31(3):79–85.

Zalila, F., Challita, S., and Merle, P. (2017). A model-driven

tool chain for occi. In OTM Confederated Interna-

tional Conferences” On the Move to Meaningful In-

ternet Systems”, pages 389–409. Springer.

Zalila, F., Challita, S., and Merle, P. (2019). Model-driven

cloud resource management with occiware. Future

Generation Computer Systems, 99:260–277.

Zhang, Z., Wu, C., and Cheung, D. W. (2013). A survey

on cloud interoperability: taxonomies, standards, and

practice. ACM SIGMETRICS Performance Evalua-

tion Review, 40(4):13–22.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems