A Model-Driven Method for Fast Building Consistent Web Services in

Practice

David Sferruzza

1,3

, Jérôme Rocheteau

1,2

, Christian Attiogbé

and Arnaud Lanoix

LS2N - UMR CNRS 6004 / F-44322 Nantes Cedex 3, France

ICAM / 35, avenue du Champ de Manœuvres, 44470 Carquefou, France

Startup Palace / 18, rue Scribe, 44000 Nantes, France

Keywords:

Software Engineering, Web Applications, Web Services, Model-driven Engineering, Formal Veriﬁcations.

Abstract:

Nowadays, lots of software companies rely on web technologies to test market hypothesis and develop viable

businesses. They often need to quickly build web services that are at the core of their Minimum Viable Pro-

ducts (MVPs). MVPs must be reliable and are based on speciﬁcations and hypothesis that are likely to change.

Model Driven Engineering approaches have been proposed and used to develop and evolve web services. Ho-

wever, these approaches lack the ability to be suitable for both (i) rapid prototyping, (ii) model veriﬁcation

and (iii) compatibility with common programming languages. Here we propose a meta-model to express web

services and the related tool to verify models consistency. We adopt a shallow veriﬁcation process to allow

rapid prototyping by developers who are not formal methods experts, while still offering design-time gua-

rantees that improve product quality and development efﬁciency. Web services are deﬁned using parametric

components which enable to express and formally verify web service patterns and to safely reuse them in other

contexts. We built a tool to check consistency of models and associated components implementations in order

to generate corresponding web services. This allows us to give ﬂexibility to developers, as well as veriﬁcation

support and an easier onboarding for new developers.

1 INTRODUCTION

Context. Web agencies are software companies that

often work with their customers to help them develop

new projects involving the web. Most of these cus-

tomers need web applications to bring value to their

own customers. These web applications are built ite-

ratively to limit their cost while allowing startups to

converge toward a viable market. This approach be-

gins by building a Minimum Viable Product (MVP).

In this context, it is a web application with a high level

of quality but a limited set of features. MVPs (among

other kinds of web applications) need to be functio-

nal, reliable, usable and designed with users’ emoti-

ons in mind, with only the features required to test

market hypotheses. In this domain, it is very com-

mon for agencies and IT companies to be paid a lump

sum which is negotiated with customers before pro-

jects begin. Startup Palace, a web agency that evol-

ves in this context, is investigating new ways of buil-

ding web applications for several years.

Motivation. Software companies, and more speciﬁ-

cally web agencies, are always in need of new approa-

ches to reduce time-to-market while ensuring quality

of web applications and proﬁts. When developing a

MVP it is important to focus on features that really

bring value to users, also called game-changers. Ot-

her features, called show-stoppers, do not bring va-

lue directly but are required to make the application

functional, reliable or usable. With that in mind, lump

sum payments imply that if a project takes too much

time to reach the expected (and sold) level of quality

and features, companies will have to reduce their pro-

ﬁts. Show-stopper features are often tedious to im-

plement and so error-prone. Furthermore, because of

the iterative process and the purpose of MVPs, spe-

ciﬁcations are likely to evolve, which can introduce

bugs. This means that developers need abstractions

to be able to safely express, isolate, reuse and evolve

behaviors. Some programming languages do provide

such abstractions, along with modern type checkers

that are able to statically verify consistency of pro-

grams. But this is not practicable in our context be-

Sferruzza, D., Rocheteau, J., Attiogbé, C. and Lanoix, A.

A Model-Driven Method for Fast Building Consistent Web Services in Practice.

DOI: 10.5220/0006531900150024

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 15-24

ISBN: 978-989-758-283-7

cause we would like to leverage existing expertises

of developers instead of forcing them to learn a new

programming language and its ecosystem from scra-

tch. While these motivations relate to web applicati-

ons, they also apply to web services development that

is addressed in this article. Web services are appli-

cations provided by a server, which are communica-

ting with other applications using the HTTP protocol

through the network. Lots of web applications rely on

web services as they allow to separate UI from core

features and data management, which is useful, for

example, when having several UIs (like in mobile ap-

plications).

Contribution. This work is an attempt to solve the

problem of building web services using safe abstracti-

ons on top of an existing programming language in

order to ease development and reuse of show-stopper

features.

We introduce a meta-model to express web ser-

vices and a corresponding semantics for veriﬁcation.

This leverages existing theory in Model Driven En-

gineering (MDE) (Bernardi, Cimitile, Di Lucca, et

al. 2012; Rocheteau and Sferruzza 2016; Scheid-

gen, Efftinge, and Marticke 2016) and a component-

based approach in order to provide an expressive

and language-agnostic solution to build web services.

This meta-model does not allow to completely specify

web services but is rather limited to a high-level repre-

sentation in order to provide support while keeping

models simple.

We propose a tool (Sferruzza 2017) (i) to check

models consistency, (ii) to generate working web ser-

vices from a given valid model. For example, every

component preconditions must be fulﬁlled in their in-

stance contexts in order for a model to be consis-

tent. This mechanism, coupled with the consistency

checking, gives developers the ability to quickly and

safely write and use components. But above all they

can reuse existing components in a reliable way. This

mechanism, coupled with the consistency checking,

gives developers means to quickly and safely write

and use components, and to reuse them in a reliable

way.

The article is structured as follows. Section 2 des-

cribes the meta-model of web services. Section 3

deﬁnes consistency of compliant models and shows

how they can be checked. Section 4 introduces a

tool to generate actual implementations from models.

Section 5 shows a case study that illustrates our ap-

proach. Section 6 presents related work. Finally,

Section 7 concludes the article with some lessons and

future work.

2 A META-MODEL TO EXPRESS

WEB SERVICES

We introduce a meta-model of web services. This

meta-model is voluntarily simple in order to provide

two advantages: (i) to give developers good abstracti-

ons to write reusable code while giving them a good

ﬂexibility and (ii) to allow tools to provide support to

developers, such as design-time consistency veriﬁca-

tion (see Section 3).

2.1 Notations

The union or sum type of two types T

and T

is de-

noted T

] T

A tuple T is a product type between n types T

, with n ≥ 2. It is denoted T ≡ T

×...×T

. A value

t of type T is written as t = (t

,...,t

) where t

∈ T

. . . , t

∈ T

. The notation t(x) is also used to designate

, where x ∈ {1,...,n}.

A record R is a tuple with labeled elements. It is

denoted R ≡ hlabel

: T

,...,label

: T

i. It is syn-

tactic sugar over a tuple T

× . .. × T

and n functi-

ons label

: R → T

, . . . , label

: R → T

. As for tu-

ples, a value r of type R is written as r = (t

,...,t

)

where t

∈ T

, . . . , t

∈ T

. Associated functi-

ons can also be written r.label

, . . . , r.label

. For

example, for a record person = (”Batman”,35) ∈

hname : String,age : Inti we have name(person) =

person.name = ”Batman” ∈ String.

A set whose elements are all of type T has the type

P(T ).

A sequence or list of type T is a set of elements

of type T which are listed in a speciﬁc order. It is de-

noted List(T ). It is similar to a function from indexes

I to values of T , that is List(T ) : I → T where I is a

1..N and N = card(List(T )). It can also be written as

List(T ) ≡ [t

,...,t

] where t

,...,t

∈ T .

The projection of a set or list of tuples S on the

element of a tuple is written Pr j

(S). Similarly, the

projection of a set or list of records S on one of the ele-

ments of a record label

is written Pr j

label

(S). For ex-

ample, for a set of records S ∈ P(hname : String,age :

Inti) where S = {(”Batman”,35), (”Robin”,26)},

Pr j

name

(S) = {”Batman”, ”Robin”} ∈ P(String).

2.2 The Meta-model

A meta-model of web services is deﬁned by the UML

class diagram in Figure 1. It does not aim to replace

existing standard meta-models like for instance the

OpenAPI Speciﬁcation (Open API Initiative and The

Linux Foundation 2017) or RAML (RAML Work-

group 2017), but rather to be compatible and com-

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

plementary with them. These models allow to de-

ﬁne programming language-agnostic interface des-

criptions for HTTP APIs (i.e. informal contracts) in

order to be able for both humans and computers to

discover and understand their capabilities, while our

meta-model allows to express actual implementati-

ons of such HTTP APIs. It is designed in order

to match needs and requirements about veriﬁcation

(see Section 3), generation and ease of writing (see

Section 4). For this reason, and to be more acces-

sible to practitioners, our approach does not rely on

existing standards such as BPEL (Fu, Bultan, and Su

2004) or WSDL (Gronmo et al. 2004).

A model of web services m

∈ M is speciﬁed as a

record of three elements: a set of entities of type E

that stands for the data model, a set of components of

type C that stands for the process model and an orde-

red list of services of type S that exposes component

to the outer world (see Formula (1)).

M ≡ hentities : P(E),components : P(C),

services : List(S)i (1)

Entities are non-primitive data types. An entity

∈ E is represented by a record of two elements: a

name and a set of variables that represent attributes:

E ≡ hname : String,attributes : P(V )i. A variable

∈ V is deﬁned by a record composed of a name and

a type: V ≡ hname : String,type : T i. An attribute of

an entity can be another entity, making it a recursive

type.

Components are units of processes and compu-

tations that occur inside web services. Their exe-

cution happens in an isolated context, that can con-

tain variables. They can mutate this context by ad-

ding and removing variables. A component c

∈ C

is deﬁned as the union type of atomic components

AC and composite components CC: C , AC ] CC.

Both types of components are deﬁned by a name

and a set of variables that express components’ pa-

rameters. Because they have parameters, we call

them parametric components. An atomic compo-

nent ac

∈ AC is represented by a record of the fol-

lowing elements: name, parameters, preconditions

(a set of variables that might be needed in the exe-

cution context), additions (a set of variables that

will be added to the execution context) and remo-

vals (a set of variables that will be removed from

the execution context): AC ≡ hname : String, params :

P(V ), pre : P (V ),add : P(V ),rem : P(V )i. A

composite component cc

∈ CC is represented by

a record of the following elements: name, para-

meters and an ordered list of component instances:

CC ≡ hname : String, params : P(V ), components :

List(CI)i. A component instance ci

∈ CI is repre-

sented by a record of two elements: a component

and a set of bindings used to instantiate the compo-

nent by associating arguments to its parameters: CI ≡

hcomponent : C, bindings : P(hparam : V,argument :

Termi)i. Terms can be variables or literal values:

Term , V ]Value. Atomic components are meant to

be along with an implementation written using a pro-

gramming language whereas composite components

are not. Components can be seen as an abstraction to

encourage separation of concerns and reusability by

leveraging two mechanisms: composition and para-

metrization.

Services are the entry points of web services. A

service s

∈ S is represented by a record of four ele-

ments: a HTTP method, a URL pattern, a set of va-

riables that represent expected input parameters and

a component instance: S ≡ hmethod : String,url :

String, params : P (V ),component : CIi. URL pat-

terns are regular expressions with named capturing

groups. It is easy to use one of these regular expres-

sions to check if it matches the URL part of an inco-

ming HTTP request, or to do a projection to get a set

of expected parameters (corresponding to the named

capturing groups). In a model of web services, servi-

ces are gathered in an ordered list. This abstraction is

very common in web frameworks and is often called

router. Instead of considering a web application as a

huge function of HTTP requests to HTTP responses,

a router allows to dispatch HTTP requests to several

such functions by ﬁltering them declaratively by met-

hod and by URL pattern. That is to reduce complexity

of the whole application by encouraging separation of

concerns.

2.3 Concrete Syntax for Models of Web

Services

We presented a mathematical deﬁnition of our meta-

model in Section 2.2 and an equivalent class diagram

in Figure 1. These notations are meant to introduce

formal deﬁnitions that are used to deﬁne properties

on the meta-model, which we do in Section 3. But

they are cumbersome to read or write actual models.

We introduce a concrete syntax that is more com-

pact and readable. Because it is equivalent to diagram

in Figure 1, we won’t deﬁne it formally here but only

provide some intuition on it.

A model is represented, with respect to its formal

deﬁnition, as an unordered list of deﬁnitions, each

on its own lines. A deﬁnition starts with an element

identiﬁer: e for entity, s for service, ac for atomic

component and cc for composite component. Ele-

ment’s properties are placed on their own indented

A Model-Driven Method for Fast Building Consistent Web Services in Practice

Model

Entity

name : Identiﬁer

Variable

name : Identiﬁer

Type

String

Boolean

Integer

Float

Date

DateTime

Component

name : Identiﬁer

AtomicComponent

CompositeComponent

ComponentInstance

Binding

Term

Constant

value : object

Service

method : method

url : url

attributes *

type 1

params *

pre * add * rem *

«ordered»

components *

component 1

bindings *

param 1

argument 1

type 1

params *

component 1

entities *

components *

«ordered»

services *

Figure 1: Meta-model diagram.

line and preﬁxed with the property name (or a short

alias). Here is an example of a service declaration.

method POST

url \/getName\/(?<email>[^\/]+)

params (email: String)

ci GetName

For readability reasons, every item of a composite

component list of component instances can be written

on its own line (see examples in Section 5). The con-

crete syntax of the other structures of the meta-model

is deﬁned in a similar way.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

2.4 Evaluating a Model of Web Services

Our meta-model gives helpful abstractions to develop

web services but the built models need a rigorous eva-

luation semantics. Here is how web services based on

an instance of this meta-model could handle incoming

HTTP requests.

Routing. First, the application receives a HTTP re-

quest. Its list of services is sequentially scanned until

a service matches the request; that is, the HTTP met-

hod is the same and the URL matches the pattern. If

no service matches, then a static 404 HTTP response

is sent back.

Flattening. Then, the component instance contai-

ned in the service is reduced to a ﬂattened ordered

list of instances of atomic components: instances of

composite components are recursively replaced by

their subcomponents. We deﬁne by cases a function

f latten(c) that ﬂattens a given component:

if c ∈ AC, then f latten(c) = [c]

if c ∈ CC, then f latten(c) =

[

ci∈c.components

f latten(ci)

if c ∈ CI, then f latten(c) = f latten(c.component)

(2)

Evaluating Components. An initial evaluation

context is created by extracting parameters (if pre-

sent) from the request URL and putting them into an

empty context. This ﬂattened list is then evaluated:

every atomic component is executed given the previ-

ous context as an input and produces a new context

as an output. This behavior is very similar to state

monads (see § 2.5 in (Wadler 1992)).

Responding. Finally, a HTTP response is built.

There are two cases to consider. If one of the eva-

luated components returned a HTTP response instead

of a new context, the following components are not

evaluated and this response is returned to the client.

Otherwise, the context is serialized and encapsulated

into a HTTP response of code 200.

3 CONSISTENCY OF WEB

SERVICES

Section 2 showed that our web services meta-model

uses components as an abstraction to improve sepa-

ration of concerns and reusability. In order to allow

developers to safely use this abstraction we propose

a way to do veriﬁcation of models. This veriﬁca-

tion checks if a model is consistent. It can happen

at design-time – outside any evaluation context – so

that inconsistent models won’t be run in production.

Deﬁnition. A model of web services m ∈ M is con-

sistent if it veriﬁes the following properties identiﬁed

by Formulas (3) to (13).

Component Name Uniqueness. Every component

in a model has a unique name:

∀c ∈ m.components, ∀c

∈ m.components

(c.name = c

.name ⇒ c = c

) (3)

Entity Name Uniqueness. Every entity in a model

has a unique name:

∀e ∈ m.entities, ∀e

∈ m.entities

(e.name = e

.name ⇒ e = e

) (4)

Same Entity’s Attributes Name Uniqueness.

Every attribute of an entity has a unique name:

∀e ∈ m.entities, ∀a ∈ e.attributes,∀a

∈ e.attributes

(a.name = a

.name ⇒ a = a

) (5)

Composite Components Flattenability. When re-

cursively resolving component references from a

composite component’s subcomponents, there can’t

be a reference to this component:

∀c ∈ m.components

(c /∈ f latten(c)) (6)

Context Variable Name Uniqueness. Variables in

atomic components cannot have the same name if

they are not identical:

∀c ∈ m.components, ∀v ∈ (c.pre ∪ c.add ∪ c.del),

∀v

∈ (c.pre ∪ c.add ∪ c.del)

(v.name = v

.name ⇒ v = v

) (7)

Composite Component Nonemptiness. Compo-

site components must have subcomponents:

∀c ∈ m.components,

(c ∈ CC ⇒ c.subcomponents 6= /0) (8)

A Model-Driven Method for Fast Building Consistent Web Services in Practice

Context Immutability. Components don’t override

existing variables of the context. Every atomic com-

ponent does not add a new variable to its output con-

text if there is already a variable with the same name

in its input context:

∀c ∈ m.components

(c ∈ AC ⇒ c.add ∩ c.pre = /0) (9)

Component’s Precondition Exhaustivity. Com-

ponents depend on the variables they remove. Every

atomic component has every variable it will remove

from the context in its preconditions:

∀c ∈ m.components

(c ∈ AC ⇒ ac.rem ⊆ ac.pre) (10)

Component Instances’ Parameters Exhaustivity.

Component instances provide values for every para-

meter of the instantiated component. Every compo-

nent instance provides exactly as much arguments as

the component it instantiates needs parameters. Na-

mes and types of the arguments match those of the

parameters:

∀c ∈ m.components

(c ∈ CC ⇒ ∀ci ∈ c.components

(Pr j

param

(ci.bindings) = ci.component.params))

(11)

∀s ∈ services

(Pr j

param

(s.component.bindings) =

s.component.params) (12)

Context Validity. Components are instantiated in

contexts that fulﬁll their preconditions. When buil-

ding ﬂat ordered lists of atomic components for each

service (see Section 2.4), every atomic component of

these lists has its preconditions fulﬁlled by its input

context:

∀s ∈ S

( f latten(s.component) J s.params) (13)

We introduce J as a function of List(C) ×

P(V ) → Boolean in inﬁx notation

. This function is

true when applied to a component and a context that

satisﬁes the component’s preconditions. It is deﬁned

by the following semantic rules:

ctx

∈ P(V )

[ ] J ctx

(14)

ctx

∈ P(V )

∀i ∈ [0, n],c

∈ CI

.pre ⊆ ctx

ctx

= ctx

∪ c

.add \ c

.rem

,...,c

] J ctx

,...,c

] J ctx

(15)

The point of these properties is not to ensure that

a model is consistent with functional speciﬁcation of

web services; it would be too intrusive in the deve-

lopment process and the cost would not be worth the

gain in our context. It is rather to guarantee a structu-

ral consistency of a model at a very small cost, so that

developers can use abstractions offered by our meta-

model while having a certain level of conﬁdence on

the result. This cannot prevent all bugs from happe-

ning at runtime; this is the price of the ﬂexibility of

our approach. But this can catch bugs related to the

misuse of abstractions offered by our meta-model at

design-time, thus reducing the footprint in terms of

added complexity and unreliability of our approach.

cs J ctx means that the context ctx satisﬁes the compo-

nent list cs

4 A TOOL TO GENERATE

CONSISTENT WEB SERVICES

The meta-model we introduced in Section 2 allows

to write web services models whose consistency can

be veriﬁed by the properties introduced in Section 3.

We propose a tool (Sferruzza 2017) to build actual

web services from models that conform to the meta-

model, after performing consistency veriﬁcations on

them (see Section 3). This tool takes two inputs: a

model ﬁle containing a serialized representation of an

instance of our meta-model, and a path to a direc-

tory which contains implementations of atomic com-

ponents.

As shown in Figure 2, our tool follows three se-

quential steps:

Model Parsing. Input model is parsed as concrete

syntax of the meta-model (see Section 2.3).

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

Start

Input model Model parsing

AC implementations

Syntax OK?

Failure

Consistency

Consistent?

FailureGeneration

Web services

Stop

yes

Figure 2: Tool process.

Model Consistency Veriﬁcation. The model is

checked in order to establish its consistency (see

Section 3).

Web Services Generation. The model is used to ge-

nerate an implementation of the web services that

it represents.

This process is generic: it can be implemen-

ted using different technologies. For example, we

choose to specialize our implementation by adding

two hypotheses: atomic components’ implementati-

ons uses the PHP programming language (The PHP

Group 2016) and the generated web services relies

on the Laravel web framework (Otwel 2016). This

choice is made because PHP and Laravel are well

known and used by our ﬁrst end-users: Startup Pa-

lace’s developers.

To be able to conclude about consistency of

web services generated from a consistent model (see

Section 3), we need to assume or manually verify that

atomic component implementations and their speciﬁ-

cations in the model are compliant. This is currently

a limitation that will be removed in a future work by

automating the compliance veriﬁcation.

The last step of our tool is the generation step.

Many similar tools (see Section 6) take the approach

to generate and output a standalone web application

that includes everything necessary to operate it. We

took another approach by generating code that should

never be manually edited; the generated code does not

override any existing ﬁles in a Laravel’s architecture

and can be easily hooked to an existing web applica-

tion through conﬁguration.

Currently, developers still have to handle secu-

rity aspects outside of the scope of our solution, for

instance when writing atomic components, because

they have control on implementation details.

5 EXPERIMENTATIONS

In order to validate our approach, that is to show that

the meta-model deﬁned in Section 2 is able to express

real web services, we illustrate it here with a volun-

tarily minimalistic case study, for the sake of bre-

vity. Further case studies focus on comparison with

other approaches or technologies. This section spe-

ciﬁes web services we want to build, shows how we

implement them and discusses advantages of our ap-

proach such as ﬂexibility, reusability and safety.

Problem Statement. In order to maintain a digital

registration list for an event named “Mastering cURL

and cheese”, we would like to create and expose web

services that would, on one hand, allow people to re-

gister themselves, and allow organizers to check re-

gistered people, on the other hand.

Informal Speciﬁcation. To register, a user would

use cURL to send a POST HTTP request to the

endpoint /register/[name]/[email] where

[name] is her name and [email] her email ad-

dress. If this user is already registered, the service

would return an error message with a 403 HTTP

code. If the given email address is invalid, the ser-

vice would return an error message with a 422 HTTP

code. If both conditions are fulﬁlled, the registration

would be persisted in a relational database along with

the registration datetime, and the service would re-

turn the input information with a 200 HTTP code.

To see registered people, an organizer would use

cURL to send a GET HTTP request to the endpoint

/attendees/[key] where [key] is a string that

needs to be the same as the one hardcoded in the ser-

vice in order to authenticate the request. If the given

key is invalid, the service would return an error mes-

sage with a 401 HTTP code. If it is valid, it would

fetch registrations from the database, serialize them

and return them with a 200 HTTP code.

Implementation. In the following examples, we

use the concrete syntax introduced in Section 2.3. We

show a possible implementation of this informal spe-

ciﬁcation into a model and explain the different steps

to build it.

First, we deﬁne our data model, that is the

entities element of our model. We have only one

entity: Registration.

A Model-Driven Method for Fast Building Consistent Web Services in Practice

name Registration

attributes (name: String, email: String, date:

DateTime)

Then, we deﬁne two services that are linked to two

composite component instances that we will deﬁne af-

terwards. These services will be the interfaces bet-

ween our application and the outer world, as deﬁned

in the informal speciﬁcation.

method POST

url \/register\/(?<name>[^\/]+)\/(?<email

>[^\/]+)

params (name: String, email: String)

ci Registration

method GET

url \/attendees\/(?<key>[^\/]+)

params (key: String)

ci GetAttendees(apiKey = "mykey")

Then, we deﬁne the two composite components

linked to the services. As they are composite compo-

nents, they are deﬁned in terms of other components.

This step is important because here we choose how

to split the features into several components, to max-

imize separation of concerns and reusability.

name Registration

ci ValidateEmail

ci CheckDupRegistration

ci CreateRegistration

ci SaveRegistration

ci RegistrationSerializer

name GetAttendees

params (apiKey: String)

ci CheckKey(correctKey = apiKey)

ci FetchRegistrations

ci RegistrationsSerializer

The last modeling step is to deﬁne the atomic

components used in our composite components.

name ValidateEmail

pre (email: String)

name CheckDupRegistration

pre (name: String, email: String)

name CreateRegistration

pre (name: String, email: String)

add (registration: Registration)

name SaveRegistration

pre (registration: Registration)

name RegistrationSerializer

pre (registration: Registration)

name CheckKey

params (correctKey: String)

pre (key: String)

name FetchRegistrations

add (registrations: Seq(Registration))

name RegistrationsSerializer

pre (registrations: Seq(Registration))

Finally, we can implement these atomic compo-

nents using PHP. As an example, here is the imple-

mentation of the CheckKey component.

<?php

class CheckKey implements Component

{

public static function execute(Params $params,

Ctx $ctx)

{

$correctKey = $params->get(’correctKey’);

$key = $ctx->get(’key’);

if ($correctKey === $key) return $ctx;

else return response(’Invalid key’, 401);

}

Consistency. We use our tool to check whether the

model veriﬁes the properties deﬁned in Section 3

in order to prove its consistency. As a par-

tial example, we show that the CheckKey ato-

mic component is well deﬁned. It veriﬁes For-

mula (9) because /0 ∩ {(”key”,String)} = /0. It ve-

riﬁes Formula (10) because /0 ⊆ {(”key”,String)}.

We also show that the CheckKey atomic com-

ponent is well used. It has one instance in

the deﬁnition of the GetAttendees composite

components. This instance veriﬁes Formula (11)

because it reduces to {(”correctKey”,String)} =

{(”correctKey”,String)}. The GetAttendees

component is instantiated by a service that provides

{(”key”,String)} as an initial context (according to

its parameters). The CheckKey instance is well

used in the context of this service because it reduces

to {(”key”,String)} ⊆ {(”key”,String)} (see Formu-

las (13) to (15)).

Generating Web Services. The next step is to ge-

nerate a consistent and working implementation of the

web services. First, PHP implementations for each

atomic component of the model are written. We as-

sume that these implementations are in adequation

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

with both the model and the informal speciﬁcation.

Next, our tool generates working web services that in-

tegrate easily in a Laravel application (see Section 4).

Finally, we setup other parts of the Laravel applica-

tion to beneﬁt from helper features such as external

dependencies management, database schema migrati-

ons or end-to-end tests.

Discussion. This case study is a ﬁrst step to show

that our meta-model is ﬂexible enough to express mi-

nimalistic yet realistic web services. Components of-

fer a ﬁrst-class system to split computations into se-

veral smaller parts. Because assemblies of compo-

nents are checked to ensure their consistency, deve-

lopers can see them as black boxes which helps a

lot when designing, implementing and testing these

components. Implementing atomic components in the

same language and environment as the generation tar-

get allows to have a ﬁne control on what is generated

without losing the advantages of building using high-

level constructions. Because generated code integra-

tes easily in a Laravel application, the result can be

deployed like any Laravel application thus beneﬁting

from good practices such as those described in (Wig-

gins 2012). Apart from generating code, our appro-

ach makes it easy to generate diagrams from models

that allow easy visualization of how services are im-

plemented or what are components dependencies, for

example. This might be a game changer for new deve-

lopers onboarding. Finally, MDE approach improves

maintainability. For example, if we want to make an

evolution and allow attendees to modify their registra-

tion information and status by adding a new service, it

is easy to implement it while reusing existing compo-

nents and still be conﬁdent about consistency, thanks

to the veriﬁcation step.

Yet, we performed preliminary experiments with

the approach; developers of Startup Palace have

been involved in these experiments. However we plan

to implement systematic evaluation tools in order to

support more realistic (by nature and by size) case

studies.

6 RELATED WORK

The use of MDE for development and automatic ge-

neration of web services or web applications is not a

new topic (Bernardi, Cimitile, Di Lucca, et al. 2012;

Bernardi, Cimitile, and Maggi 2016; Rocheteau and

Sferruzza 2016; Scheidgen, Efftinge, and Marticke

2016).

This work is built on the approach of REIFIER,

presented in (Rocheteau and Sferruzza 2016). As in

REIFIER, we use a meta-model approach instead of a

meta-programming one, as recommended for server-

side code generation in (Scheidgen, Efftinge, and

Marticke 2016). We also share the meta-modeling

approach with the M3D tool introduced in (Bernardi,

Cimitile, Di Lucca, et al. 2012) and extended in (Ber-

nardi, Cimitile, and Maggi 2016), which is itself ba-

sed on Declare (see (van der Aalst, Pesic, and Scho-

nenberg 2009)). M3D uses as an input a 4-layers

meta-model: information layer by means of UML

class diagram, service layer by means of BPMN,

presentation layer by means of (Spring/Android)-like

meta-model and a process layer by means of Declare.

M3D is evaluated on a case study to show that 90% of

the time spent developing the application is spent on

modeling. This is advantageous as modeling is often

faster, produces more stable applications and models

are easier to maintain than code.

Our approach was developed with this idea in

mind, thus focusing on design-time support. But it

differs from existing tools in several different ways,

related to both ﬂexibility and support. First, as REI-

FIER but not M3D, it is built to allow property veriﬁ-

cation at design-time. This veriﬁcation takes the form

of a set of rules that ensure structural consistency of

models. This ensures conﬁdence in the resulting sy-

stems without the drawbacks of heavy formal met-

hods. Second, because our components are speciﬁed

in terms of preconditions and effects, instead of inputs

and outputs in REIFIER, we can ease their reusability

by minimizing the coupling to their instantiation con-

text while providing the same level of veriﬁcation.

To avoid shortcomings such as described

in (Gronmo et al. 2004), that is WSDL models

contain too much technical details and are difﬁcult to

understand for humans, our method makes it possible

to express technical details in components’ imple-

mentation that are not captured in the model. This

is an attempt to ease onboarding of new developers

by both offering lots of MDE-related advantages and

at the same time giving full ﬂexibility on technology

and implementation details.

Our approach is more related to Eiffel (Meyer

1992), than to BPEL (Fu, Bultan, and Su 2004)

or to Join Calculus (Fournet and Gonthier 2002).

As BPEL, we acknowledge that programming-in-the-

large and programming-in-the-small require different

types of languages (DeRemer and Kron 1975); but

our meta-model is simpler than BPEL, thus relevant

for developing web services. Join Calculus is devo-

ted to the design or semantics of distributed langua-

ges, which is out of our scope. We share with Eif-

fel the principle of using contracts, of being exten-

sible, reusable, and reliable. However, because our

A Model-Driven Method for Fast Building Consistent Web Services in Practice

contracts are simpler (a subset of ﬁrst-order logic),

our approach is suitable for being used by non for-

mal methods experts while providing useful support

for them to build safe and reusable components.

7 CONCLUSION

We proposed a method to build web services. It is

fast, simple, robust and ﬂexible. It is based on a meta-

model that makes it possible to describe web servi-

ces using high-level constructions (such as parame-

tric components) which enables verifying their con-

sistency using an axiomatic semantics as well as ge-

nerating working web services. We also built a tool

that leverages this process in the technological con-

text of a web company, Startup Palace. The whole

approach was illustrated on a case study to show its

advantages. Even if one of the motivations was to de-

velop MVPs applications, the approach is not limited

to this scope and is suitable to most applications based

on web services.

Several main prospects are here sketched. First,

the type system used to describe component parame-

ters, preconditions and model’s entities (among ot-

hers) is at the core of the consistency veriﬁcation,

yet it is not ﬂexible enough. Making it more expres-

sive, by allowing subtyping in component preconditi-

ons for example, while keeping at least the same le-

vel of veriﬁcation might be necessary to reach a good

reusability on bigger projects. Another perspective is

to allow and ease safe model composition, to allow

developers to reuse concepts between projects when

it makes sense. Finally, the whole approach needs to

be evaluated on more realistic (by nature and by size)

case studies. This evaluation must rely on metrics that

have a good correlation with the beneﬁts of our ap-

proach, such as easing new developers to onboard on

projects and reuse of exisiting code.

REFERENCES

Bernardi, Mario Luca, Marta Cimitile, Giuseppe Di Lucca,

et al. (2012). “M3D: A Tool for the Model Driven De-

velopment of Web Applications”. In: Proceedings of

the Twelfth International Workshop on Web Informa-

tion and Data Management, WIDM 2012, Maui, HI,

USA, November 02, 2012, pp. 73–80.

Bernardi, Mario Luca, Marta Cimitile, and Fabrizio Ma-

ria Maggi (2016). “Automated Development of

Constraint-Driven Web Applications”. In: Procee-

dings of the 31st Annual ACM Symposium on Applied

Computing. ACM, pp. 1196–1203.

DeRemer, Frank and Hans Kron (1975). “Programming-

in-the Large versus Programming-in-the-Small”. In:

ACM Sigplan Notices. Vol. 10. ACM, pp. 114–121.

Fournet, Cédric and Georges Gonthier (2002). “The Join

Calculus: A Language for Distributed Mobile Pro-

gramming”. In: Applied Semantics. Springer, pp.

268–332.

Fu, Xiang, Tevﬁk Bultan, and Jianwen Su (2004). “Analysis

of Interacting BPEL Web Services”. In: In Proc. 13th

Int. World Wide Web Conf. Citeseer.

Gronmo, Roy et al. (2004). “Model-Driven Web Services

Development”. In: E-Technology, e-Commerce and

e-Service, 2004. EEE’04. 2004 IEEE International

Conference On. IEEE, pp. 42–45.

Meyer, Bertrand (1992). Eiffel: The Language. Prentice-

Hall, Inc.

Open API Initiative and The Linux Foundation

(2017). OpenAPI Speciﬁcation. URL: https://

www.openapis.org (visited on 07/25/2017).

Otwel, Taylor (2016). Laravel. URL: https://laravel.com/

(visited on 07/25/2017).

RAML Workgroup (2017). RAML. URL: https://raml.org/

(visited on 07/25/2017).

Rocheteau, Jérôme and David Sferruzza (2016). “Reiﬁer:

Model-Driven Engineering of Component-Based and

Service-Oriented JEE Applications”. In: ACM/IEEE

19th International Conference on Model Driven Engi-

neering Languages and Systems. Saint-Malo, France.

Scheidgen, Markus, Sven Efftinge, and Frederik Marticke

(2016). “Metamodeling vs Metaprogramming: A

Case Study on Developing Client Libraries for REST

APIs”. In: European Conference on Modelling Foun-

dations and Applications. Springer, pp. 205–216.

Sferruzza, David (2017). Safe Web Services Generator.

URL: https://gitlab.startuppalace.com/research/swsg.

The PHP Group (2016). PHP. URL: https://php.net/ (visited

on 07/25/2017).

Van der Aalst, Wil M. P., Maja Pesic, and Helen Schonen-

berg (2009). “Declarative Workﬂows: Balancing bet-

ween Flexibility and Support”. In: Computer Science-

Research and Development 23.2, pp. 99–113.

Wadler, Philip (1992). “The Essence of Functional Pro-

gramming”. In: Proceedings of the 19th ACM

SIGPLAN-SIGACT Symposium on Principles of Pro-

gramming Languages. ACM, pp. 1–14.

Wiggins, Adam (2012). The Twelve-Factor App. URL:

https://12factor.net/ (visited on 07/25/2017).

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development