Embed Size (px)
Citation preview
Towards an MDA Mechanism for RESTfulServices Development
Chistoforos Zolotas, Andreas L. Symeonidis,Intelligent Systems & Software Engineering Labgroup,Department of Electrical and Computer Engineering,Aristotle University of Thessaloniki, Greece
29
.09
.15
1
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
[email protected]@eng.auth.gr
Presentation Outline
• Big picture – Envisioning an ideal MDE engine
• Reference model of REST and non-CRUD functionality
• Related work
• Objectives
• The meta-model: REST aspects
• The meta-model: beyond REST
• Illustrative case studies
• Conclusions and Future Work
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
2
Envisioning the ideal MDE engine
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
3
The coffee machine paradigm – Easy handling, ready to use output
The DOs – the user should:
• only provide minimal information about the envisioned outcome, mostly obvious to the domain expert
• not need to know how the machine functions• receive an outcome that is as complete as
possible, given the desired input• locate and perform as easily as possible any
necessary actions 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
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
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
RES
Tfu
lSer
vice
s
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 existing resource
3. Update: Update the content of an existing resource
4. Delete: Delete an existing resource
However, that is enough only for basic data centric applications. Any other actions (non-CRUD functionality) cannot be modeled (and thus automated) with respect to CRUD verbs.
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
5
Non-CRUD functionality
Motivation for this work
A coffee machine like MDE engine for RESTful services should:
1. Require minimal input/configuration
2. Produce 3rd layer RMM services
3. Proactively anticipate non-CRUD functionality
4. Allow modeling of conditional hypermedia links
5. The outcome should require no or minimal developer intervention.
6. Should developer intervention 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
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
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 intervention for their modeling
• Others allow 3rd layer RMM RESTful services modeling, but are too data-centric, hence cannot easily anticipate non-CRUD functionality
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
7
Existing 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
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
8
Noteworthy tools
Paper Objectives
This paper introduces a PIMmeta-model that:
• Models 3rd layer RMM RESTful Services
• Proactively anticipates non-CRUD functionality
• Allows modeling of conditional hypermedia in order to automate business and application rules.
Computational Independent Model
(CIM)
Platform Independent Model (PIM)
Platform Specific Model
(PSM)
Code Generation
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
9
The UML-Profile Overview
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
10
Simplified PIM meta-model
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
11
Meta-model overview
Simplified PIM meta-model
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
12
Meta-model overviewResource is modeled using an MVC-like pattern:Model: resource dataRepresentation: media formatController: web API
Simplified PIM meta-model
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
13
Meta-model overview
Separate API from its implementation.These handlers should be the only placedevelopers writes manual code in most cases
Simplified PIM meta-model
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
14
Meta-model overview Local database modeling and uniform access using the Repository Pattern.
Simplified PIM meta-model
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
15
RESTfulness of the meta-model with regard to
Abstract ResourceModel, as Resource Oriented building block, uniquely addressable with a URI
Only CRUD-verbAPI activities allowed
1
2
3
Resources are interconnected with hypermedia links.
Going beyond REST
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
16
Modeling Conditional 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 Condition Sets
3. Each condition set has one ore more Conditions
Conditions Sets are related to each other with logical disjunction and conditions of a set with logical conjunction.
With such condition models, several businessor application rules can be automated
Illustrative example of a set of condition sets the related resources may have.: ConditionSetA( Condition1 & Condition2 & …) V ConditionSetB( Condition3 & …) 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 ConditionSet:
InStockConditionSet(Condition(productX.availability > 0))
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
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
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
18
Case Study: Authorization Rules
This can be modeled like this (assuming proper model):
getResourceXLink ConditionSet:groupXAccessConditionSet(Condition(user.belongsTo(groupX))) V
groupYAccessConditionSet(Condition(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
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
19
Anticipating Non-CRUD Functionality
Resources marked as “algorithmic”, are supposed to embed an algorithm other than the primitive Create, Read, Update, Delete ones. With this type of resources, non-CRUD functionality is anticipated, through specializations, in a specific location, 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 location2. guide the MDE designer to specialize such
resources with new concepts and better automate a sub-domain.
Generic Resource Model
Anticipating Non-CRUD Functionality
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
20
Case Study: Database Keyword-Searching
Existing Concepts
New concepts to tailor the MDA engine for a more specific domain are anticipated by specializingalgorithmic Resources.
1. The new concepts are specializations of the existing infrastructure, hence remain at the 3rd Layer RMM (e.g. they still have unique URI, HTTP API etc.)
2. Moreover, the new concepts allow to fully automate database keyword-searching (e.g. with lucene code), hence getting closer to the coffee machine ideal.
Anticipating Non-CRUD Functionality
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
21
Case Study: Interoperating with 3rd party services
In this case, the new concepts model (and allow automation) of the interoperation with existing 3rd party RESTful services.
Conclusions
This paper presented a core meta-model that:
1) models 3rd layer RMM RESTful services
2) anticipates non-CRUD functionality, hence it can be further tailored to a specific domain and get closer to a “coffee-machine”-like MDE engine
3) models conditional hypermedia to allow automation of business and application rules.
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
22
Current Status
There exists an Eclipse plugin MDA version at:
https://github.com/s-case/mde
It is capable of:
1) producing 3rd layer RMM services
2) that embed Basic Authentication (non-CRUD functionality)
3) automating popular database keyword-searching functionality (non-CRUD functionality)
4) automating interoperation with existing RESTful services (non-CRUD functionality - work in progress)
5) ABAC authorization scheme (conditional hypermedia - work in progress)
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
23
Future Work
• Possibly extend the existing engine’s modeling capabilities with more non-CRUD functionality (e.g. paying systems)
• Automate the production of a matching RESTfulclient, given the RESTful service CIM, as well.
• Better track manual changes made by developer to the produced code.
29
.09
.15
CLO
UD
MD
E 2
01
5, O
ttaw
a, C
anad
a
24
