25
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 [email protected] [email protected]

Christoforos zolotas cloudmde2015 presentation - camera ready

  • Upload
    issel

  • View
    873

  • Download
    2

Embed Size (px)

Citation preview

Page 1: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

[email protected]    [email protected]    

Page 2: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 3: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 4: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 5: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 6: Christoforos zolotas  cloudmde2015 presentation - camera ready

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.  

Page 7: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 8: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 9: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 10: Christoforos zolotas  cloudmde2015 presentation - camera ready

The  UML-­‐ProFile  Overview  

29.09.15  

CLOUDM

DE  2015,  OMaw

a,  Canada  

10  

Page 11: Christoforos zolotas  cloudmde2015 presentation - camera ready

SimpliFied  PIM  meta-­‐model  

29.09.15  

CLOUDM

DE  2015,  OMaw

a,  Canada  

11  

Meta-­‐model  overview  

Page 12: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 13: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 14: Christoforos zolotas  cloudmde2015 presentation - camera ready

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.  

Page 15: Christoforos zolotas  cloudmde2015 presentation - camera ready

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.  

Page 16: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 17: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 18: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 19: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 20: Christoforos zolotas  cloudmde2015 presentation - camera ready

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.  

Page 21: Christoforos zolotas  cloudmde2015 presentation - camera ready

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.  

Page 22: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 23: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 24: Christoforos zolotas  cloudmde2015 presentation - camera ready

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  

Page 25: Christoforos zolotas  cloudmde2015 presentation - camera ready

29.09.15  

CLOUDM

DE  2015,  OMaw

a,  Canada  

25  

Thank  you!  [email protected]