Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards an MDA Mechanism for RESTful Services Development


Published on

"Towards an MDA Mechanism for RESTful Services Development"
The 18th International Conference on Model Driven Engineering Languages and Systems, Ottawa, Canada, 2015 Oct

Published in: Software
  • Be the first to comment

  • Be the first to like this

Towards an MDA Mechanism for RESTful Services Development

  1. 1. Towardsan MDAMechanismfor RESTful ServicesDevelopment 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 CLOUDMDE2015,Ottawa,Canada
  2. 2. 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.15CLOUDMDE2015,Ottawa,Canada 2
  3. 3. Envisioning the ideal MDE engine 29.09.15CLOUDMDE2015,Ottawa,Canada 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
  4. 4. Introduction - Overview of REST design 29.09.15CLOUDMDE2015,Ottawa,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 RESTfulServices
  5. 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 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.15CLOUDMDE2015,Ottawa,Canada 5 Non-CRUD functionality
  6. 6. 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.15CLOUDMDE2015,Ottawa,Canada 6 Envisioning the ideal MDE engine for RESTful services development.
  7. 7. State of the art of RESTfulservices developmenttools 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.15CLOUDMDE2015,Ottawa,Canada 7 Existing tools shortcomings
  8. 8. State of the art of RESTfulservices developmenttools 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.15CLOUDMDE2015,Ottawa,Canada 8 Noteworthy tools
  9. 9. Paper Objectives This paper introduces a PIM meta-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.15CLOUDMDE2015,Ottawa,Canada 9
  10. 10. The UML-Profile Overview 29.09.15CLOUDMDE2015,Ottawa,Canada 10
  11. 11. Simplified PIM meta-model 29.09.15CLOUDMDE2015,Ottawa,Canada 11 Meta-model overview
  12. 12. Simplified PIM meta-model 29.09.15CLOUDMDE2015,Ottawa,Canada 12 Meta-model overview Resource is modeled using an MVC-like pattern: Model: resource data Representation: media format Controller: web API
  13. 13. Simplified PIM meta-model 29.09.15CLOUDMDE2015,Ottawa,Canada 13 Meta-model overview Separate API from its implementation. These handlers should be the only place developers writes manual code in most cases
  14. 14. Simplified PIM meta-model 29.09.15CLOUDMDE2015,Ottawa,Canada 14 Meta-model overview Local database modeling and uniform access using the Repository Pattern.
  15. 15. Simplified PIM meta-model 29.09.15CLOUDMDE2015,Ottawa,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 activities allowed 1 2 3 Resources are interconnected with hypermedia links.
  16. 16. Going beyond REST 29.09.15CLOUDMDE2015,Ottawa,Canada 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 business or 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
  17. 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 ConditionSet: InStockConditionSet(Condition(productX.availability > 0)) 29.09.15CLOUDMDE2015,Ottawa,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. 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.15CLOUDMDE2015,Ottawa,Canada 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
  19. 19. Going beyond REST 29.09.15CLOUDMDE2015,Ottawa,Canada 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 location 2. guide the MDE designer to specialize such resources with new concepts and better automate a sub-domain. Generic Resource Model
  20. 20. Anticipating Non-CRUD Functionality 29.09.15CLOUDMDE2015,Ottawa,Canada 20 Case Study: Database Keyword-Searching Existing Concepts New concepts to tailor the MDA engine for a more specific domain are anticipated by specializing algorithmic 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.
  21. 21. Anticipating Non-CRUD Functionality 29.09.15CLOUDMDE2015,Ottawa,Canada 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.
  22. 22. 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.15CLOUDMDE2015,Ottawa,Canada 22
  23. 23. Current Status There exists an Eclipse plugin MDA version at: 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.15CLOUDMDE2015,Ottawa,Canada 23
  24. 24. 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 RESTful client, given the RESTful service CIM, as well. • Better track manual changes made by developer to the produced code. 29.09.15CLOUDMDE2015,Ottawa,Canada 24
  25. 25. 29.09.15CLOUDMDE2015,Ottawa,Canada 25 Thank you!