Building Flexible APIs for Web 2.x/Cloud Applications (JavaOne 2011 Session 25208)
Upcoming SlideShare
Loading in...5

Building Flexible APIs for Web 2.x/Cloud Applications (JavaOne 2011 Session 25208)



Building Flexible APIs for Web 2.x/Cloud Applications

Building Flexible APIs for Web 2.x/Cloud Applications

session 25208, JavaOne 2011



Total Views
Views on SlideShare
Embed Views



44 Embeds 10,261 6198 1055 438 311 267 240 238 163 162 121 78 78 75 74 72 59 53 50 45 43 39 37 36 36 34 34 30 30 29 28 19 16 16 13 12 9 8 6 3 2 1 1 1 1


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Building Flexible APIs for Web 2.x/Cloud Applications (JavaOne 2011 Session 25208) Building Flexible APIs for Web 2.x/Cloud Applications (JavaOne 2011 Session 25208) Presentation Transcript

  • Raymond  Feng  (    Luciano  Resende  (    
  • ¡  Raymond  Feng   §  Staff  Software  Engineer  –  Shutterfly,  Inc.   §  Member  –  Apache  Software  Foundation   §  Committer:  Apache  Tuscany,  Wink,  Nuvem   §  Co-­‐author  –  Tuscany  SCA  In  Action  ¡  Luciano  Resende   §  Staff  Software  Engineer  –  Shutterfly,  Inc.   §  Member  –  Apache  Software  Foundation   §  Committer:  Apache  Tuscany,  Wink,  Nuvem,  PhotoArk  
  • ¡  Why  open  and  simple  APIs  ¡  Sample  scenario  ¡  Service  design  ¡  Model  data  using  DSL    ¡  Define  the  service  interface  ¡  Bind  to  REST  and  JSONRPC  ¡  Implement,  deploy  and  test  ¡  Documentation  ¡  Q&A  
  • ¡  A  great  way  to  build  the  ecosystem   ¡  For  some  companies,  APIs  =  products   ¡  Proliferation  of  mobile  clients   ¡  Universal  access  for  internal  systems/web  or  mobile   fronts/third  party  apps  Top  APIs  for  Mashups  
  • ¡  Address  Book  Service   §  Provide  “web  scale”  contact  management   functionality   §  Consumers   ▪  Access  from  internal  applications  running  within  the   same  data  center   ▪  Java,  .NET   ▪  Access  from  browsers   ▪  Access  from  mobile  applications   ▪  Access  from  newly  acquired  company   ▪  Access  from  3rd  party  applications  
  • Coarse-­‐grained   Fine-­‐grained  Remotable  interface   Local  interface  (Possible  to  deploy  service  providers  and   (Must  be  in  the  same  class  loading  space  consumers  to  two  different  JVMs  that   within  the  same  JVM)  communicate  using  a  protocol  stack)    Data  by  value  in  documents   Data  by  reference  in  Java  programming  (Share  the  same  info  set)   (share  the  same  object  instances)  Data  in  documents  (hierarchical   Data  in  OO  graphs  (for  example,  circular  structures  such  as  XML  or  JSON,  ids  or   references  are  allowed)  links  are  required  to  reference  data  outside  the  document)  Stateless   Various  scopes  (stateless  or  stateful)  
  • ¡  Stateless  is  key  for  service  scalability   §  Services  are  designed  to  be  scalable  and  ready  for   deployment  into  high-­‐availability  infrastructures.  To   accomplish  this  they  should  not  rely  on  long-­‐lived   relationships  between  consumer  and  provider,  nor  should   an  operation  invocation  implicitly  rely  on  a  previous   invocation.  ¡  Loose  Coupling  is  the  key  for  coarse-­‐grained  services   §  Interface  and  implementation   §  Service  providers  and  consumers   §  Protocol  bindings   §  Data  representations  
  • ¡  Data  (what  info  to  flow  between  services)  ¡  Interface  (operations  defined  as  the  data   exchange  patterns)  ¡  Component/Service/Reference  (abstraction  of   business  logic  unit:  functions  it  provides  and   functions  it  consumes)  ¡  Implementation  (how  to  write  the  business   logic)  ¡  Communication  (access  protocols)  ¡  Composition  (wiring  services  together)  ¡  QoS  (cross-­‐cutting  concerns)  
  • •  Use  Data  Transfer  Objects  (DTO)  for  remotable   coarse-­‐grained  services     §  Be  marshal-­‐able  over  the  network  using  platform/ language  independent  encodings  such  as  XML,  JSON,  or   other  binary  ones   §  Be  document/resource  (hierarchical  structure)  oriented   rather  than  object-­‐oriented   §  Be  self-­‐contained  (using  links  or  ids  to  reference  other   data  outside  the  document)  •  Use  JAXB  as  canonical  DTO  representation  for  POJO.   §  If  possible,  generate  JAXB  classes  from  XSD   §  Or  write  “pure”  Java  Beans  and  add  JAXB  Annotations  if   necessary  
  • •  Don’t  mix  business  logic  into  the  data  objects  •  Do  not  use  interfaces  for  the  data  model  (interfaces  are  not  friendly  data   representations  for  many  Java  data  bindings  such  as  JAXB  and  JSON)   §  Upon  de-­‐serialization,  most  frameworks  use  the  default  no-­‐arg  constructor  to   instantiate  the  DTO  •  Object-­‐oriented  graph  is  not  remoting  friendly   §  The  relations  between  objects  need  to  be  maintained  by  IDs  or  links  instead  of   programming  language  specific  references/pointers   §  Distributed  object  model  (such  as  RMI  or  CORBA)  doesn’t  fit  into  SOA  •  Don’t  use  language  specific  serializations  such  as  Java  Serialization  •  Don’t  use  complex  Java  generics  and  collections  for  DTOs  •  Multiple-­‐inheritance  complicates  the  issues  •  Avoid  to  use  more  than  one  complex  type  for  the  parameters.  Use   wrapper  object  if  necessary   §  One  parameter  for  the  HTTP  entity   §  XML  documents  require  a  root  element  •  Strictly  follow  JavaBeans  patterns    if  we  need  to  use  POJOs  as  the  DTOs.    
  • 4 metadata   POJO   XSD   Protocol   Domain   1.  Persistence   Buffer/Thrift   2.  DTO   Model   JSON   Textual  DSL   3.  Mapping   Schema   (such  as   DDL   4.  Introspection   Sculptor)   5.  Validation   6.  MVC/UI   2 1 CRUD   DTO   DTO   DTO   REST   Root   Locate   3 RDB   REST   Entity   Resource   Sub-­‐ CRUD   Entity   Resource   Entity   REST   Sub-­‐ CRUD   MongoDB   Resource   Generated  artifacts   Java  code   Addressbook. Code   Configuration  files   uddl   generation   templates   Documents   (UML  diagrams,  HTML   docs)  October  3,  2011   14  
  • •  We  adopted  Tuscany  SCA,  which  separates  componentization,   composition,  communication  and  QoS  concerns  from  the  business  logic.   It  becomes  obviously  natural  to  abstract  the  data  modeling  now  (inspired   by  DDD).  •  (Annotated)  POJO  (JAXB,  JPA,  Morphia)  has  too  much  noises  and  is   abuse-­‐prone.  We  want  to  enforce  the  patterns.  •  XSD  is  too  complicated  and  it  doesn’t  fit  all  for  web  2.0  •  We  need  a  simple  human  (&  machine)  readable  language  to  describe  our   domain  model  to  provide/promote:   §  Service-­‐friendly  DTO,  Persistence  (RDB  and  NoSQL),  Governance,  Reuse,   Validation,  MVC,  Best  Practice,  Documentation  •  We  call  the  DSL  as  Universal  Data  Definition  Language  (UDDL).  
  • •  Derived  from  an  Apache  licensed  open  source  project  Sculptor   §    •  Easy  to  learn,  intuitive  syntax  of  the  textual  DSL,  based  on  the  concepts  from   DDD.    •  Textual  DSL  has  a  lot  of  productivity  benefits  over  graphical  tools  •  Quick  development  round  trip,  short  feedback  loop  •  Generation  of  complete  application  from  a  single  model,  not  only  fragments  that   are  hard  to  fit  in  to  the  overall  design  •  Supports  JPA  (oracle/mysql/postgresql)/MongoDB/JAXB/Spring/SpringMVC  •  Great  extensibility  and  customization  •  Based  on  Eclipse  Xtext/Xtend/Xpand  code  generation  framework  •  Can  be  used  with  text  editor  or  any  IDE,  but  DSL  editor  with  error  highlight,  code   completion,  and  outline  is  provided  for  Eclipse  users  •  Documentation  w/  diagrams  for  domain  model  •  No  runtime  magic  is  built  into  the  tools  (generated  code  can  be  used  without  the   tooling)   16  
  • Semantic   model   Generated  artifacts     Grammar   Language   Eclipse  Model   Load/save   (DSL)   Workflow  Engine   Java  code     (MWE)  Parse/validate   Eclipse   Xtext   UI   Configuration   files   Xpand   Documents   Parse  tree   Grammar   model   model   (UML   diagrams,   HTML  docs)   EMF  Ecore  model   Xtend/ Check   EMF  Ecore  model     Other  DSLs   (such  as  XSD,   GPB,  Thrift  or   Extend/ Avro)     transform/ validate  
  • ¡  DSL:  <  145  lines  including  blank  ones  ¡  Java  source  code:   §  13  files   §  >1,500  lines  in  total   §  We  get  setter/getter/fluent  APIs,  static  field   names,  equals/hasCode/toString,  JAXB/JPA/ Morphia  annotations    
  • ¡  Sculptor: fornax/Sculptor+%28CSC%29    ¡  Eclipse  Xtext:    
  • ¡  Clean  and  Flexible  Interface   §  Infrastructure  details  are  abstracted  away,  and   declaratively  attached  to  the  services  if  required  ¡  Remote  friendly  interfaces   §  Always  use  remote  friendly  data  objects  ¡  Identify  required  Data  Access  Patterns    ¡  Anti-­‐Patterns   §  Don’t  make  your  service  interfaces  dependent  of   protocol  specific  information  (e.g.  HTTP  Headers,  etc)  
  • public interface AddressBookService { PaginatedCollection<Contact> findContacts(StringuserId, ContactFilterContext filterContext, PageContextpageContext); Contact findContact(String userId, String contactId)throws NotFoundException; void updateContact(String userId, Contact contact)throws NotFoundException; void deleteContact(String userId, String contactId)throws NotFoundException; …  }  
  • ¡  We  build  the  resources  using  JAX-­‐RS  and   deploy  them  as  Tuscany  SCA  REST  binding  
  • public interface ContactResource{ @GET @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) PaginatedCollection<Contact> getAll( @QueryParam("startIndex") @DefaultValue("0") int startIndex, @QueryParam("pageSize") @DefaultValue("0") int pageSize, @QueryParam("sort") @DefaultValue("") String sort); @GET @Path("/{id}") @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML}) Contact get(@PathParam("id") String id); @POST Response create(Contact value); @PUT @Path("/{id}") void update(@PathParam("id") String id, Contact value); @DELETE @Path("/{id}") void delete(@PathParam("id") String id); }  
  • ¡  Plain  JSON/XML  with  certain  data  access   patterns  mixed  in   §  Simple   §  No  client  library  is  required  ¡  Open  Data  Protocol  (OData):     §    ¡  Google  Data  Protocol  (GData):   §    
  • ¡  Pagination  ¡  Filtering  ¡  Sorting  ¡  Hypermedia  
  • ¡  REST  has  a  resource  oriented  programming   model,  which  does  not  map  gracefully  into   RPC  languages  ¡  Use  the  Resource  layer  when  exposing  the   service  as  REST  ¡  Use  the  Service  Interface  when  exposing  the   services  to  other  RPC  style  protocols  (e.g.   JSONRPC,  RMI,  SOAP  WebServices,  etc)  
  • This  provides  a   JavaScrip RESTful  view  of  the   t  Object   resources.  One  Service   Monitoring   REST  w/  JSON   API  might  expose   multiple  resources.  Browser   Contacts   Id   Name   …   DTO   Mongo (JAXB)   DB   DOM   Flex   REST  w/  XML   Resource   Client   Collection     Oracle   .NET   Service  3rd  Party   API   SOAP/HTTP   App   JSON-­‐RPC   DTO   (JAXB)   Other  Internal   DTO   Client   (JAXB)   High  Performance   Security:   Binding   Authentication   oAuth   and   Authorization   authorization  
  • ¡  Apache  Tuscany’s  REST  binding   §    ¡  Apache  Wink  JAX-­‐RS  runtime   §    
  • ¡  Two  Java  components  +  One  Spring   component  
  • ¡  Start  a  MongoDB  ¡  Start  Tuscany  with  embedded  Jetty  (within   Eclipse)  ¡  Start  a  browser  to  test  REST  and  JSONRPC  
  • ¡  Composition  diagram   §  Describe  the  service  and  the  assembly  ¡  Data  Model   §  Describe  data  and  the  relationships  ¡  Service  Documentation   §  Describe  service  interfaces  and  resources  
  • SCA  domain   Interface   (SCA,  JAX-­‐ WS,  JAX-­‐RS,   etc.)   Component   Component   Tabular   Enunciate   view  of   POJO   Interface   POJO   (Javadoc/ Interface   description   data   description     APT)   description   UDDL  (xtext/xpand)   POJO   UML-­‐like   diagrams  
  • ¡  Apache  Tuscany  SCA  composite  diagram   generator   §­‐java-­‐2.x/ trunk/maven/tuscany-­‐diagram-­‐plugin/    ¡  Enunciate  (Generating  documents  and  client   code)   §    ¡  Google  API  explorer   §   §­‐apis-­‐explorer/      
  • ¡  Data  access  layer  ¡  Service  externalization   §  Security   §  Monitoring   §  Quota