CLOUDMDE 2015, Ottawa, Canada, Towards an MDA Mechanism for RESTful Services Development.

1. Towards
an
MDA
Mechanism
for
RESTful
Services
Development
Chistoforos
Zolotas,
Andreas
L.
Symeonidis,
Intelligent
Systems
&
So6ware
Engineering
Labgroup,
Department
of
Electrical
and
Computer
Engineering,
Aristotle
University
of
Thessaloniki,
Greece
29.09.15
1
CLOUDMDE
2015,
OMawa,
Canada
christopherzolotas@issel.ee.auth.gr
asymeon@eng.auth.gr

2. Presentation
Outline
• Big
picture
–
Envisioning
an
ideal
MDE
engine
• Reference
model
of
REST
and
non-­‐CRUD
funcTonality
• Related
work
• ObjecTves
• The
meta-­‐model:
REST
aspects
• The
meta-­‐model:
beyond
REST
• IllustraTve
case
studies
• Conclusions
and
Future
Work
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
2

3. Envisioning
the
ideal
MDE
engine
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
3
The
coffee
machine
paradigm
–
Easy
handling,
ready
to
use
output
The
DOs
–
the
user
should:
• only
provide
minimal
informa;on
about
the
envisioned
outcome,
mostly
obvious
to
the
domain
expert
• not
need
to
know
how
the
machine
funcTons
• receive
an
outcome
that
is
as
complete
as
possible,
given
the
desired
input
• locate
and
perform
as
easily
as
possible
any
necessary
acTons
to
the
outcome
(such
as
adding,
sugar…)
The
DON’Ts
–
the
user
should
not
have
to:
• find
and
fix
mistakes
in
the
outcome
• configure
too
much
the
mechanism,
or
provide
too
much
input

4. Introduction
-­‐
Overview
of
REST
design
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
4
Richardson’s
Maturity
Model
as
a
“RESTfulness
metric”
Level
3:
Hypermedia
Links
(HATEOAS)
Level
2:
Proper
HTTP
Verbs
Use
Level
1:
Resource
Oriented
Design
Level
0:
The
swamp
POX
RESTful
Services

5. Introduction
–
Overview
of
REST
design
The
common
interface
of
REST
defines
what
should
be
done
with
respect
to
the
four
CRUD
verbs:
1.
Create:
Create
a
new
instance
of
a
resource
2.
Read:
Retrieve
an
exisTng
resource
3.
Update:
Update
the
content
of
an
exisTng
resource
4.
Delete:
Delete
an
exisTng
resource
However,
that
is
enough
only
for
basic
data
centric
applicaTons.
Any
other
acTons
(non-­‐CRUD
func;onality)
cannot
be
modeled
(and
thus
automated)
with
respect
to
CRUD
verbs.
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
5
Non-­‐CRUD
func;onality

6. Motivation
for
this
work
A
coffee
machine
like
MDE
engine
for
RESTful
services
should:
1. Require
minimal
input/configura;on
2. Produce
3rd
layer
RMM
services
3. ProacTvely
an;cipate
non-­‐CRUD
funcTonality
4. Allow
modeling
of
condi;onal
hypermedia
links
5. The
outcome
should
require
no
or
minimal
developer
interven;on.
6. Should
developer
intervenTon
is
needed,
it
ought
to
be
clear
where
it
is
needed,
what
has
to
be
done
and
how
the
MDE
engine
will
handle
it
at
subsequent
runs.
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
6
Envisioning
the
ideal
MDE
engine
for
RESTful
services
development.

7. State
of
the
art
of
RESTful
services
development
tools
There
exists
a
plethora
of
tools
and
approaches:
• Most
tools
do
not
produce
3rd
layer
RMM
services
e.g.
they
do
not
produce
hypermedia
links
or
require
developer
intervenTon
for
their
modeling
• Others
allow
3rd
layer
RMM
RESTful
services
modeling,
but
are
too
data-­‐centric,
hence
cannot
easily
anTcipate
non-­‐CRUD
funcTonality
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
7
Exis;ng
tools
shortcomings

8. State
of
the
art
of
RESTful
services
development
tools
Some
of
the
best
efforts
to
model
RESTful
services:
• EMF-­‐REST
• RESTfulie
• Rails
• Persevere
• Cloudfier
• Django-­‐REST
• Restlet
• RESTeasy
• …
and
many
many
others
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
8
Noteworthy
tools

9. Paper
Objectives
This
paper
introduces
a
PIM
meta-­‐model
that:
• Models
3rd
layer
RMM
RESTful
Services
• ProacTvely
anTcipates
non-­‐CRUD
func;onality
• Allows
modeling
of
condi;onal
hypermedia
in
order
to
automate
business
and
applicaTon
rules.
ComputaTonal
Independent
Model
(CIM)
PlaQorm
Independent
Model
(PIM)
Plakorm
Specific
Model
(PSM)
Code
GeneraTon
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
9

10. The
UML-­‐ProFile
Overview
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
10

11. SimpliFied
PIM
meta-­‐model
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
11
Meta-­‐model
overview

12. SimpliFied
PIM
meta-­‐model
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
12
Meta-­‐model
overview
Resource
is
modeled
using
an
MVC-­‐like
paMern:
Model:
resource
data
Representa;on:
media
format
Controller:
web
API

13. SimpliFied
PIM
meta-­‐model
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
13
Meta-­‐model
overview
Separate
API
from
its
implementaTon.
These
handlers
should
be
the
only
place
developers
writes
manual
code
in
most
cases

14. SimpliFied
PIM
meta-­‐model
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
14
Meta-­‐model
overview
Local
database
modeling
and
uniform
access
using
the
Repository
PaTern.

15. SimpliFied
PIM
meta-­‐model
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
15
RESTfulness
of
the
meta-­‐model
with
regard
to
Abstract
Resource
Model,
as
Resource
Oriented
building
block,
uniquely
addressable
with
a
URI
Only
CRUD-­‐verb
API
acTviTes
allowed
1
2
3
Resources
are
interconnected
with
hypermedia
links.

16. Going
beyond
REST
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
16
Modeling
Condi;onal
Hypermedia
Links
Hypermedia
links
are
build
on
top
of
the
“RelatedResource”
stereotype,
which
comprises:
1. the
URI
of
the
related
resource
2. and
a
set
of
Condi;on
Sets
3. Each
condiTon
set
has
one
ore
more
Condi;ons
CondiTons
Sets
are
related
to
each
other
with
logical
disjunc;on
and
condiTons
of
a
set
with
logical
conjunc;on.
With
such
condiTon
models,
several
business
or
applica;on
rules
can
be
automated
IllustraTve
example
of
a
set
of
condiTon
sets
the
related
resources
may
have.:
Condi;onSetA(
Condi;on1
&
Condi;on2
&
…)
V
Condi;onSetB(
Condi;on3
&
…)
V
…
Meta-­‐model
elements

17. Modeling
Conditional
Hypermedia
Consider
the
following
scenario:
-­‐ RESTful
E-­‐shop
sells
product
A
and
B
-­‐ Users
can
list
products
and
add
them
to
their
shopping
list.
-­‐ They
should
not
be
able
to
add
out
of
stock
products
to
their
list.
This
can
be
modeled
like
this
(assuming
proper
model):
addProductXtoListLink
Condi;onSet:
InStockCondi;onSet(Condi;on(productX.availability
>
0))
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
17
Case
Study:
E-­‐shop
business
rules
User
lists
products
User
receives
hypermedia
link
to
add
only
product
A
to
list
User
receives
hypermedia
links
to
add
product
A
or
B
to
list
B
is
out
of
Stock?
Yes
No

18. Modeling
Conditional
Hypermedia
Consider
a
scenario
where:
1. Users
are
categorized
to
groups
2. Only
selected
groups
should
access
some
resources
(hence
receive
corresponding
hypermedia
links
to
them)
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
18
Case
Study:
Authoriza;on
Rules
This
can
be
modeled
like
this
(assuming
proper
model):
getResourceXLink
Condi;onSet:
groupXAccessCondi;onSet(Condi;on(user.belongsTo(groupX)))
V
groupYAccessCondi;onSet(Condi;on(user.belongsTo(groupY)))
User
accesses
resource
Y,
related
resource
of
X
User
receives
hypermedia
link
to
access
X
User
does
not
receive
any
hypermedia
link
to
X
User
belongs
to
group
X
or
Y?
Yes
No

19. Going
beyond
REST
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
19
An;cipa;ng
Non-­‐CRUD
Func;onality
Resources
marked
as
“algorithmic”,
are
supposed
to
embed
an
algorithm
other
than
the
primiTve
Create,
Read,
Update,
Delete
ones.
With
this
type
of
resources,
non-­‐CRUD
funcTonality
is
anTcipated,
through
specializaTons,
in
a
specific
locaTon,
and
is
wrapped
around
a
3rd
layer
RMM
interface.
This
has
a
two-­‐fold
purpose:
1. guide
the
developer
to
add
non-­‐
automatable
code
to
a
specific
locaTon
2. guide
the
MDE
designer
to
specialize
such
resources
with
new
concepts
and
beMer
automate
a
sub-­‐domain.
Generic
Resource
Model

20. Anticipating
Non-­‐CRUD
Functionality
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
20
Case
Study:
Database
Keyword-­‐Searching
ExisTng
Concepts
New
concepts
to
tailor
the
MDA
engine
for
a
more
specific
domain
are
anTcipated
by
specializing
algorithmic
Resources.
1. The
new
concepts
are
specializa;ons
of
the
exisTng
infrastructure,
hence
remain
at
the
3rd
Layer
RMM
(e.g.
they
sTll
have
unique
URI,
HTTP
API
etc.)
2. Moreover,
the
new
concepts
allow
to
fully
automate
database
keyword-­‐searching
(e.g.
with
lucene
code),
hence
gepng
closer
to
the
coffee
machine
ideal.

21. Anticipating
Non-­‐CRUD
Functionality
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
21
Case
Study:
Interopera;ng
with
3rd
party
services
In
this
case,
the
new
concepts
model
(and
allow
automaTon)
of
the
interoperaTon
with
exisTng
3rd
party
RESTful
services.

22. Conclusions
This
paper
presented
a
core
meta-­‐model
that:
1) models
3rd
layer
RMM
RESTful
services
2) an;cipates
non-­‐CRUD
func;onality,
hence
it
can
be
further
tailored
to
a
specific
domain
and
get
closer
to
a
“coffee-­‐
machine”-­‐like
MDE
engine
3) models
condi;onal
hypermedia
to
allow
automaTon
of
business
and
applicaTon
rules.
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
22

23. Current
Status
There
exists
an
Eclipse
plugin
MDA
version
at:
hMps://github.com/s-­‐case/mde
It
is
capable
of:
1) producing
3rd
layer
RMM
services
2) that
embed
Basic
AuthenTcaTon
(non-­‐CRUD
func;onality)
3) automaTng
popular
database
keyword-­‐searching
funcTonality
(non-­‐
CRUD
func;onality)
4) automaTng
interoperaTon
with
exisTng
RESTful
services
(non-­‐CRUD
func;onality
-­‐
work
in
progress)
5) ABAC
authorizaTon
scheme
(condi;onal
hypermedia
-­‐
work
in
progress)
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
23

24. Future
Work
• Possibly
extend
the
exisTng
engine’s
modeling
capabiliTes
with
more
non-­‐CRUD
funcTonality
(e.g.
paying
systems)
• Automate
the
producTon
of
a
matching
RESTful
client,
given
the
RESTful
service
CIM,
as
well.
• BeMer
track
manual
changes
made
by
developer
to
the
produced
code.
29.09.15
CLOUDMDE
2015,
OMawa,
Canada
24

25. 29.09.15
CLOUDMDE
2015,
OMawa,
Canada
25
Thank
you!
christopherzolotas@issel.ee.auth.gr