0
Raymond	  Feng	  (rfeng@apache.org)	  	  Luciano	  Resende	  (lresende@apache.org)	  	  
¡    Raymond	  Feng	        §  Staff	  Software	  Engineer	  –	  Shutterfly,	  Inc.	        §  Member	  –	  Apache	  Soft...
¡  Why	  open	  and	  simple	  APIs	  ¡  Sample	  scenario	  ¡  Service	  design	  ¡  Model	  data	  using	  DSL	  	  ...
¡    A	  great	  way	  to	  build	  the	  ecosystem	   ¡    For	  some	  companies,	  APIs	  =	  products	   ¡    Proli...
¡  Address	  Book	  Service	      §  Provide	  “web	  scale”	  contact	  management	         functionality	     §  Cons...
Coarse-­‐grained	                                                Fine-­‐grained	  Remotable	  interface	                  ...
¡    Stateless	  is	  key	  for	  service	  scalability	        §  Services	  are	  designed	  to	  be	  scalable	  and	...
¡  Data	  (what	  info	  to	  flow	  between	  services)	  ¡  Interface	  (operations	  defined	  as	  the	  data	      ex...
•    Use	  Data	  Transfer	  Objects	  (DTO)	  for	  remotable	       coarse-­‐grained	  services	  	       §  Be	  marsh...
•    Don’t	  mix	  business	  logic	  into	  the	  data	  objects	  •    Do	  not	  use	  interfaces	  for	  the	  data	  ...
4                                                                                                                         ...
•  We	  adopted	  Tuscany	  SCA,	  which	  separates	  componentization,	     composition,	  communication	  and	  QoS	  c...
•    Derived	  from	  an	  Apache	  licensed	  open	  source	  project	  Sculptor	       §  http://fornax.itemis.de/conflu...
Semantic	                                                    model	                                                       ...
¡  DSL:	  <	  145	  lines	  including	  blank	  ones	  ¡  Java	  source	  code:	     §  13	  files	     §  >1,500	  lin...
¡  Sculptor:	      http://fornax.itemis.de/confluence/display/    fornax/Sculptor+%28CSC%29	  	  ¡  Eclipse	  Xtext:	  ht...
¡    Clean	  and	  Flexible	  Interface	        §  Infrastructure	  details	  are	  abstracted	  away,	  and	           ...
public interface AddressBookService {		      PaginatedCollection<Contact> findContacts(StringuserId, ContactFilterContext ...
¡  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})	  Paginated...
¡  Plain	  JSON/XML	  with	  certain	  data	  access	    patterns	  mixed	  in	     §  Simple	     §  No	  client	  lib...
¡  Pagination	  ¡  Filtering	  ¡  Sorting	  ¡  Hypermedia	  
¡  REST	  has	  a	  resource	  oriented	  programming	      model,	  which	  does	  not	  map	  gracefully	  into	      R...
This	  provides	  a	                     JavaScrip                                                                        ...
¡  Apache	  Tuscany’s	  REST	  binding	    §  http://tuscany.apache.org	  	  ¡  Apache	  Wink	  JAX-­‐RS	  runtime	    ...
¡  Two	  Java	  components	  +	  One	  Spring	    component	  
¡  Start	  a	  MongoDB	  ¡  Start	  Tuscany	  with	  embedded	  Jetty	  (within	      Eclipse)	  ¡  Start	  a	  browser...
¡  Composition	  diagram	     §  Describe	  the	  service	  and	  the	  assembly	  ¡  Data	  Model	     §  Describe	  ...
SCA	  domain	         Interface	        (SCA,	  JAX-­‐      WS,	  JAX-­‐RS,	           etc.)	                             ...
¡    Apache	  Tuscany	  SCA	  composite	  diagram	        generator	        §  https://svn.apache.org/repos/asf/tuscany/...
¡  Data	  access	  layer	  ¡  Service	  externalization	    §  Security	    §  Monitoring	    §  Quota	  
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)
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)
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)
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)
Upcoming SlideShare
Loading in...5
×

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

13,805

Published on

Building Flexible APIs for Web 2.x/Cloud Applications

session 25208, JavaOne 2011

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
13,805
On Slideshare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
26
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. Raymond  Feng  (rfeng@apache.org)    Luciano  Resende  (lresende@apache.org)    
  2. 2. ¡  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  
  3. 3. ¡  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  
  4. 4. ¡  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  
  5. 5. ¡  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  
  6. 6. 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)  
  7. 7. ¡  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  
  8. 8. ¡  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)  
  9. 9. •  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  
  10. 10. •  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.    
  11. 11. 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  
  12. 12. •  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).  
  13. 13. •  Derived  from  an  Apache  licensed  open  source  project  Sculptor   §  http://fornax.itemis.de/confluence/display/fornax/Sculptor+%28CSC%29    •  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  
  14. 14. 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  
  15. 15. ¡  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    
  16. 16. ¡  Sculptor:   http://fornax.itemis.de/confluence/display/ fornax/Sculptor+%28CSC%29    ¡  Eclipse  Xtext:  http://www.eclipse.org/Xtext/    
  17. 17. ¡  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)  
  18. 18. 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; …  }  
  19. 19. ¡  We  build  the  resources  using  JAX-­‐RS  and   deploy  them  as  Tuscany  SCA  REST  binding  
  20. 20. 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); }  
  21. 21. ¡  Plain  JSON/XML  with  certain  data  access   patterns  mixed  in   §  Simple   §  No  client  library  is  required  ¡  Open  Data  Protocol  (OData):     §  http://www.odata.org/    ¡  Google  Data  Protocol  (GData):   §  http://code.google.com/apis/gdata/    
  22. 22. ¡  Pagination  ¡  Filtering  ¡  Sorting  ¡  Hypermedia  
  23. 23. ¡  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)  
  24. 24. 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  
  25. 25. ¡  Apache  Tuscany’s  REST  binding   §  http://tuscany.apache.org    ¡  Apache  Wink  JAX-­‐RS  runtime   §  http://incubator.apache.org/wink    
  26. 26. ¡  Two  Java  components  +  One  Spring   component  
  27. 27. ¡  Start  a  MongoDB  ¡  Start  Tuscany  with  embedded  Jetty  (within   Eclipse)  ¡  Start  a  browser  to  test  REST  and  JSONRPC  
  28. 28. ¡  Composition  diagram   §  Describe  the  service  and  the  assembly  ¡  Data  Model   §  Describe  data  and  the  relationships  ¡  Service  Documentation   §  Describe  service  interfaces  and  resources  
  29. 29. 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  
  30. 30. ¡  Apache  Tuscany  SCA  composite  diagram   generator   §  https://svn.apache.org/repos/asf/tuscany/sca-­‐java-­‐2.x/ trunk/maven/tuscany-­‐diagram-­‐plugin/    ¡  Enunciate  (Generating  documents  and  client   code)   §  http://enunciate.codehaus.org/    ¡  Google  API  explorer   §  http://code.google.com/apis/explorer/   §  http://code.google.com/p/google-­‐apis-­‐explorer/      
  31. 31. ¡  Data  access  layer  ¡  Service  externalization   §  Security   §  Monitoring   §  Quota  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×