Director,  Solu-ons  Architecture,  WSO2  

Mifan  Careem  

SOA  Pa+erns:  

En)ty  Linking  and  REST  pa5erns  in  SOA  

Agenda  ๏  About  WSO2  

๏  Of  rela)onships  and  what  not!  

๏  Rela)onships  between  services  

๏  En)ty  Linking  in  prac)ce  

๏  What  SOA  can  learn  from  the  RESTful  pa5erns  

๏  RESTful  APIs  

๏  HATEOAS  

๏  Lightweight  Endpoints  

๏  Dynamic  Endpoints  

๏  The  API  Façade  

๏  Bringing  it  all  together  

๏  References  

2  

3  

Mifan  Careem  -­‐  BIO  

๏  Mifan  Careem,  Director  of  Solu)ons  Architecture  at  WSO2  

๏  Mifan  AT  WSO2.com  

๏  Works  closely  with  clients  and  WSO2  engineering  and  sales  teams,  in  defining  domain  specific  solu)ons  architectures  

4  

About  WSO2  ๏  Global  enterprise,  founded  in  2005  

by  acknowledged  leaders  in  XML,  web  services    technologies,  standards    and  open  source  

๏  Provides  only  open  source  plaWorm-­‐as-­‐a-­‐service  for  private,  public  and  hybrid  cloud  deployments  

๏  All  WSO2  products  are  100%  open  source  and  released  under  the  Apache  License  Version  2.0.  

๏  Is  an  Ac)ve  Member  of  OASIS,  Cloud  Security  Alliance,  OSGi  Alliance,  AMQP  Working  Group,  OpenID  Founda)on  and  W3C.  

๏  Driven  by  Innova)on  

๏  Launched  first  open  source  API  Management  solu)on  in  2012  

๏  Launched  App  Factory  in  2Q  2013  

๏  Launched  Enterprise  Store  and  first  open  source  Mobile  solu)on  in  4Q  2013  

5  

What  WSO2  delivers  

6  

Business  Model  

An  Enterprise  Requirement  ๏  Build  a  set  of  Business  APIs  in  a  simple,  understandable  

manner  based  on  a  complex,  evolving  plaWorm  –  these  APIs  should  stand  the  test  of  )me,  should  be  self-­‐describable  and  should  allow  both  the  plaWorm  and  client  to  evolve  on  their  own.  

7  

An  Enterprise  Requirement  

8  

An  Enterprise  Requirement…  

9  

A  typical  service  with  rela)onships  

10  

๏  A  service  chaining  example  below,  where  the  rela)onship  logic  would  be  ‘hard-­‐coded’  in  the  calling  service  

<definitions xmlns="http://ws.apache.org/ns/synapse"> <proxy name="StockQuoteProxy"> <target> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService"/> </endpoint> <outSequence> <send/> </outSequence> </target> <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/> </proxy> </definitions>

Problems  

๏  Service  interfaces  are  ‘fixed’  

๏  Service  interfaces  are  not  ‘meaningful’  or  ‘intui)ve’  

๏  Rela)onships  cannot  be  dynamic,  and  are  pre-­‐defined  in  the  calling  service  

๏  Services  cannot  be  interchanged  at  run)me  

11  

REST  –  a  SOA  design  summary  

๏  Everything  is  a  resource  –  iden)fy  resources  that  are  exposed  as  services  

๏  Model  rela)onships  and  define  resource  friendly  URLs  

๏  Map  HTTP  CRUD  to  obtain  and  modify  resources  –  map  GET,  PUT,  POST  and  DELETE  

๏  Document  resource  representa)ons  (JSON,  XML,  micro-­‐formats)  

๏  Pa5erns  and  an)-­‐pa5erns  

12  

Example  

๏  PersonInfoService  

๏  /person  –  GET,  POST  

๏  /person/{id}  –  GET,  PUT,  DELETE  

๏  /person/{id}/account–  GET,  POST  

๏  /person/{id}/account/id  –  GET,  PUT,  DELETE  

๏  POST  to  create  Person  

๏  POST  /person  

๏  200  OK  

๏  Loca)on:  /person/1423  

๏  GET  Person  Account  

๏  GET  /person/1423/account  

๏  200  OK  

๏  <account>A,  B,  C</account>  

๏  <credit  href=“/credit”/>  

13  

REST  and  Associated  Pa5erns  

๏  Uniform  Contract  

๏  Using  fixed  methods  

๏  En)ty  Linking  

๏  Discoverable  rela)onships  in  en))es  

๏  En)ty  Endpoints  

๏  Naming    

๏  En)ty  Re-­‐direc)on  

๏  Load  balancing  

๏  Content  Nego)a)on  

๏  Mul)ple  clients  

๏  Lightweight  Endpoints  

๏  Web  API  

๏  API  Façade  

๏  HATEOAS  

๏  Explicity  handle  state  

14  

Example  extended  

15  

RELATIONSHIPS  BETWEEN  SERVICES  

"Assump)ons  are  the  termites  of  rela)onships”  -­‐  Henry  Winkler  

16  

A  typical  service  with  rela)onships  

17  

๏  A  service  chaining  example  below,  where  the  rela)onship  logic  would  be  ‘hard-­‐coded’  in  the  calling  service  

<definitions xmlns="http://ws.apache.org/ns/synapse"> <proxy name="StockQuoteProxy"> <target> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService"/> </endpoint> <outSequence> <send/> </outSequence> </target> <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/> </proxy> </definitions>

En)ty  Linking  Defined  ๏  Problem:  Pre-­‐defined  

rela)onships  

๏  Business  en))es  have  natural  rela)onships,  yet  en)ty  services  are  commonly  designed  autonomously  with  no  indica)on  of  these  rela)onships.    

๏  Service  consumers  ac)ng  as  composi)on  controllers  are  commonly  required  to  have  en)ty  linking  logic  hard-­‐coded  in  order  to  work  with  en)ty  rela)onships.    

๏  This  limits  the  composi)on  controller  to  any  addi)onal  links  that  may  become  relevant  and  further  adds  a  governance  burden  to  ensure  that  hard-­‐coded  en)ty  linking  logic  is  kept  in  synch  with  the  business.  

๏  Solu)on:  En)ty  Linking  

๏  Services  inform  their  consumers  about  the  existence  of  related  en))es  as  part  of  the  consumer's  interac)ons  with  the  services.  

๏  Applica)on  

๏  Links  are  included  in  relevant  response  messages  from  the  service.    

๏  Service  consumers  are  able  to  navigate  from  en)ty  to  en)ty  by  following  these  links,  and  accumulate  further  business  knowledge  along  the  way.    

๏  This  allows  service  consumers  with  li5le  up-­‐front  en)ty  linking  logic  to  correctly  compose  en)ty  services  based  on  their  rela)onships.  

18  

source: http://SOAPatterns.org

En)ty  Linking  in  Prac)ce  

๏  Wikipedia  –  the  mother  of  all  rela)onships  

๏  Linked  Data  

๏  DBPedia  

19  

Example  extended  

๏  GET  Person  Account  

๏  GET  /person/1423/account  

๏  200  OK  

๏  <account>A,  B,  C</account>  

๏  <credit  href=“/credit”/>  

๏  GET  Account  from  CreditService  

๏  GET  /person/1423/account/credit/14  

20  

Focus  on  your  priori)es!  

21  

API  Façade  

๏  A  design  pa5ern  where  a  simpler  business  API  interface  is  exposed,  hiding  the  underlying  complex  services  layer  

๏  External  clients  communicate  with  the  business  API  layer  –  hence  it  is  important  to  keep  business  APIs  constant  and  re-­‐usable  even  when  the  underlying  plaWorm  evolves  

22  

HATEOAS  

๏  Hypertext  As  The  Engine  Of  Applica)on  State  

๏  It  means  that  hypertext  should  be  used  to  find  your  way  through  the  API  

๏  Loose  coupling  between  client  and  server  

23  

GET /person/1234/account <account> <balance>USD 120</balance> <link rel=“withdraw” href=“/withdraw”/> <link rel=“deposit” href=“/deposit”/> <link rel=“close” href=“/close”/> </account>

<account> <balance>USD 3</balance>

<link rel=“deposit” href=“/deposit”/> <link rel=“close” href=“/close”/>

</account>

Endpoint  Registry  

๏  Endpoints  can  differ  based  on  the  environment,  context,  business  case  

๏  A  smart  endpoint  registry  can  pick  up  endpoints  dynamically  at  run)me  

24  

Source: Asanka Abeysinghe – WSO2 Solutions Architecture Blog

Bringing  it  all  together  

25  

The  bigger  picture  

26  

Research  

๏  En)ty  Linking  and  Retrieval  

๏  En)ty  Linking  for  Seman)c  Search  

๏  Linked  Open  Data  Project  

27  

28  

References  

๏  SOAPa5erns:  h5p://soapa5erns.org/  

๏  REST:  Roy  Fielding  

๏  REST  Cookbook:  h5p://restcookbook.com  

๏  Linked  Open  Data  Project:  h5p://lod-­‐cloud.net/  

๏  WSO2:  h5p://wso2.com/  

 

Contact  us  !