christoforos zolotas cloudmde2015 presentation - camera ready
TRANSCRIPT
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
CLOUDM
DE 2015, OMaw
a, Canada
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
CLOUDM
DE 2015, OMaw
a, Canada
2
Envisioning the ideal MDE engine
29.09.15
CLOUDM
DE 2015, OMaw
a, 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
Introduction -‐ Overview of REST design
29.09.15
CLOUDM
DE 2015, OMaw
a, 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
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
CLOUDM
DE 2015, OMaw
a, Canada
5
Non-‐CRUD func;onality
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
CLOUDM
DE 2015, OMaw
a, Canada
6
Envisioning the ideal MDE engine for RESTful services development.
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
CLOUDM
DE 2015, OMaw
a, Canada
7
Exis;ng tools shortcomings
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
CLOUDM
DE 2015, OMaw
a, Canada
8
Noteworthy tools
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
CLOUDM
DE 2015, OMaw
a, Canada
9
The UML-‐ProFile Overview
29.09.15
CLOUDM
DE 2015, OMaw
a, Canada
10
SimpliFied PIM meta-‐model
29.09.15
CLOUDM
DE 2015, OMaw
a, Canada
11
Meta-‐model overview
SimpliFied PIM meta-‐model
29.09.15
CLOUDM
DE 2015, OMaw
a, Canada
12
Meta-‐model overview Resource is modeled using an MVC-‐like paMern: Model: resource data Representa;on: media format Controller: web API
SimpliFied PIM meta-‐model
29.09.15
CLOUDM
DE 2015, OMaw
a, Canada
13
Meta-‐model overview
Separate API from its implementaTon. These handlers should be the only place developers writes manual code in most cases
SimpliFied PIM meta-‐model
29.09.15
CLOUDM
DE 2015, OMaw
a, Canada
14
Meta-‐model overview Local database modeling and uniform access using the Repository PaTern.
SimpliFied PIM meta-‐model
29.09.15
CLOUDM
DE 2015, OMaw
a, 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.
Going beyond REST
29.09.15
CLOUDM
DE 2015, OMaw
a, 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
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
CLOUDM
DE 2015, OMaw
a, 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
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
CLOUDM
DE 2015, OMaw
a, 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
Going beyond REST
29.09.15
CLOUDM
DE 2015, OMaw
a, 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
Anticipating Non-‐CRUD Functionality
29.09.15
CLOUDM
DE 2015, OMaw
a, 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.
Anticipating Non-‐CRUD Functionality
29.09.15
CLOUDM
DE 2015, OMaw
a, 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.
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
CLOUDM
DE 2015, OMaw
a, Canada
22
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
CLOUDM
DE 2015, OMaw
a, Canada
23
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
CLOUDM
DE 2015, OMaw
a, Canada
24