Techniques for Composing REST services - SOA Symposium 2009

3,681 views
3,455 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,681
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Techniques for Composing REST services - SOA Symposium 2009

  1. 1. Techniques for Composing REST services Cesare Pautasso Faculty of Informatics University of Lugano, Switzerland c.pautasso@ieee.org http://www.pautasso.info
  2. 2. Abstract  Novel trends in Web services technology challenge the assumptions made by current standards for process-based service composition. For example, most existing RESTful Web service APIs (which do not rely on the Web Service Description Language), cannot natively be composed using the WS-BPEL language.  In this talk we introduce the problem of composing RESTful services and compare it to Web 2.0 service mashups. We cover several real-world examples demonstrating how existing composition languages can be evolved to cope with REST. We conclude by showing that the uniform interface and hyper- linking capabilities of RESTful services provides an excellent abstraction for exposing in a controlled way the state of business process as a resource. ©2009 - Cesare Pautasso 2
  3. 3. About Cesare Pautasso  Assistant Professor at the Faculty of Informatics, University of Lugano, Switzerland (since Sept 2007) Research Projects:  SOSOA – Self Organizing Service Oriented Architectures -  CLAVOS – Continuous Lifelong Analysis and Verification of Open Services  BPEL for REST  Researcher at IBM Zurich Research Lab (2007)  Post Doc at ETH Zürich -  Software: JOpera: Process Support for more than Web services http://www.jopera.org/  Ph.D. at ETH Zürich, Switzerland (2004)  Representations: http://www.pautasso.info/ (Web) http://twitter.com/pautasso/ (Twitter Feed) ©2009 - Cesare Pautasso 3
  4. 4. Why Composition?  Composition is the key SOA principle with the goal of enabling service reuse ©2009 - Cesare Pautasso 4
  5. 5. REST and Reuse  Uniform Interface (Reuse Contract)  Status Codes (Reuse Metadata)  Representations (Reuse Media Types)  Middleware (Reuse caching, security, load balancing, proxies components) ©2009 - Cesare Pautasso 5
  6. 6. REST in one slide  Web Services expose their data and functionality trough PUT resources identified by URI R  Uniform Interface Principle: GET Clients interact with resources POST through a fix set of verbs. DELETE Example HTTP: GET (read), POST (create), PUT (update), DELETE  Multiple representations for the same resource  Hyperlinks model resource relationships and valid state transitions for dynamic protocol description and discovery ©2009 - Cesare Pautasso 6
  7. 7. REST and Reuse  Uniform Interface (Reuse Contract)  Status Codes (Reuse Metadata)  Representations (Reuse Media Types)  Middleware (Reuse caching, security, load balancing, proxies components)  Yes, but what about reusing entire RESTful services? ©2009 - Cesare Pautasso 7
  8. 8. RESTful Composition Techniques 1. Defining RESTful service composition 2. Example: DoodleMap 3. What about mashups? 4. BPM and REST ©2009 - Cesare Pautasso 8
  9. 9. REST Architectural Elements Client/Server Layered Stateless Communication Cache Proxy User Agent Origin Server Gateway Connector (HTTP) Cache ©2009 - Cesare Pautasso 9
  10. 10. Basic Setup HTTP User Agent Origin Server Adding Caching HTTP HTTP Caching Origin Server User Agent Caching User Agent Origin Server HTTP Caching Caching User Agent Origin Server ©2009 - Cesare Pautasso 10
  11. 11. Proxy or Gateway? Intermediaries forward (and may translate) requests and responses HTTP HTTP Client Proxy Origin Server A proxy is chosen by the Client (for caching, or access control) HTTP HTTP Client Gateway Origin Server The use of a gateway (or reverse proxy) is imposed by the server ©2009 - Cesare Pautasso 11
  12. 12. REST Middleware for Scalability Cache Proxy/Gateway Origin Server Clients  One example of REST middleware is to help with the scalability of a server, which may need to service a very large number of clients ©2009 - Cesare Pautasso 12
  13. 13. REST Middleware for Composition Proxy/Gateway Origin Server Clients  Composition shifts the attention to the client which should consume and aggregate from many servers ©2009 - Cesare Pautasso 13
  14. 14. REST Middleware for Composition Client Composite Origin RESTful Servers service  The “proxy” intermediate element which aggregates the resources provided by multiple servers plays the role of the composition controller of a composite RESTful service ©2009 - Cesare Pautasso 14
  15. 15. Composite Resources DELETE PUT GET C DELETE DELETE POST PUT PUT GET R GET S POST POST ©2009 - Cesare Pautasso 15
  16. 16. Composite Resources  The composite resource only aggregates the state of its component resources C R S State R State S ©2009 - Cesare Pautasso 16
  17. 17. Composite Resources  The composite resource augments (or caches) the state of its component resources C State C R S State R State S ©2009 - Cesare Pautasso 17
  18. 18. Enter HATEOAS  Web Services expose their data and functionality trough PUT resources identified by URI R  Uniform Interface Principle: GET Clients interact with resources POST through a fix set of verbs. DELETE Example HTTP: GET (read), POST (create), PUT (update), DELETE  Multiple representations for the same resource  Hyperlinks model resource relationships and valid state transitions for dynamic protocol description and discovery ©2009 - Cesare Pautasso 18
  19. 19. Composite Representations DELETE PUT DELETE Composite GET R PUT Representation POST GET S C POST LinkR LinkS ©2009 - Cesare Pautasso 19
  20. 20. Composite Representation Pattern Composite Representation Origin Server Client Origin Servers  A composite representation is interpreted by the client that follows its hyperlinks and aggregates the state of the referenced component resources ©2009 - Cesare Pautasso 20
  21. 21. Bringing it all together Composite Representation Composite Origin RESTful Servers service Client Origin Servers  A composite representation can be produced by a composite service too ©2009 - Cesare Pautasso 21
  22. 22. Doodle Map Example Composite Representation Composite Origin RESTful Servers service Client Origin Servers  Vote on a meeting place based on its geographic location ©2009 - Cesare Pautasso 22
  23. 23. 1. Composite Resource DELETE PUT GET C DELETE DELETE POST PUT PUT GET R GET S POST POST ©2009 - Cesare Pautasso 23
  24. 24. 1. Composite Resource DELETE GET C DELETE POST PUT GET R GET S POST ©2009 - Cesare Pautasso 24
  25. 25. 2. Composite Representation DM DELETE GET G LinkG GET C LinkC DELETE POST PUT LinkD GET R GET S POST ©2009 - Cesare Pautasso 25
  26. 26. Demo ©2009 - Cesare Pautasso 26
  27. 27. Was it just a Mashup? Mashup REST Composition (It depends on the definition of Mashup) ©2009 - Cesare Pautasso 27
  28. 28. Moving state around  Read-only vs. Read/Write DELETE PUT GET C DELETE DELETE POST PUT PUT GET R GET S POST POST ©2009 - Cesare Pautasso 28
  29. 29. Simply aggregating data (feeds)  Read-only vs. Read/write GET C GET R GET S ©2009 - Cesare Pautasso 29
  30. 30. Is your composition reusable?  UI vs. API Composition Composite API Representation Composite Origin RESTful Servers UI service  Reusable Client Origin services vs. Servers Reusable Widgets ©2009 - Cesare Pautasso 30
  31. 31. Single-Origin Sandbox  Can you always do this from a web browser? Composite Representation Composite Origin RESTful Servers service Client Origin Servers ©2009 - Cesare Pautasso 31
  32. 32. Single-Origin Sandbox  Security Policies on the client may not always allow it to aggregate data from multiple different sources Composite Representation Composite N Origin RESTful Servers service Client 1 Origin Server ©2009 - Cesare Pautasso 32
  33. 33. Complementary Read-Only Read/Write UI Mashup REST API Composition Reusable Situational Service Sandboxed ©2009 - Cesare Pautasso 33
  34. 34. RESTful Composition Techniques 1. Defining RESTful service composition 2. Example: DoodleMap 3. What about mashups? 4. BPM and REST ©2009 - Cesare Pautasso 34
  35. 35. Web Service Composition Today The WS-BPEL process model is layered on top of WS-BPEL 2.0 the service model defined by WSDL 1.1. […] WSDL 1.1 Both the process and its partners are exposed as WSDL services [BPEL 2.0 Standard, Section 3] ©2009 - Cesare Pautasso 35
  36. 36. RESTful Web Services APIs… WSDL 1.1 …do not use WSDL 1.1 ©2009 - Cesare Pautasso 36
  37. 37. BPEL/WSDL 2.0 WSDL 2.0 HTTP Binding can wrap RESTful Web Services (WS-BPEL 2.0 does not support WSDL 2.0) BPEL WSDL 2.0 PUT Operations ... Op_1 <Invoke Op_1> Op_2 Op_3 GET R <Invoke Op_2> Op_4 ... HTTP Binding POST DELETE <Invoke Op_3> Op URI Method Op_1 R PUT PUT <Invoke Op_4> Op_2 R GET GET Op_3 R POST POST ... Op_4 R DELETE DELETE ©2009 - Cesare Pautasso 37
  38. 38. BPM RESTful Workflow Web Service Languages Composition ©2009 - Cesare Pautasso 38
  39. 39. Solutions BPM RESTful Workflow Web Service 1. Abstract Workflow Languages Composition  Service invocation technology does not matter 2. Concrete Workflow  Expose service invocation BPM RESTful Workflow Web Service LanguagesComposition technologies as explicit constructs in the workflow language 3. RESTful Workflow BPM RESTful  Workflow as one kind of resource Workflow Web Service Languages Composition exposed by a RESTful service ©2009 - Cesare Pautasso 39
  40. 40. BPEL/WSDL 2.0 WSDL 2.0 HTTP Binding can wrap RESTful Web Services (WS-BPEL 2.0 does not support WSDL 2.0) BPEL WSDL 2.0 PUT Operations ... Op_1 <Invoke Op_1> Op_2 Op_3 GET R <Invoke Op_2> Op_4 ... HTTP Binding POST DELETE <Invoke Op_3> Op URI Method Op_1 R PUT PUT <Invoke Op_4> Op_2 R GET GET Op_3 R POST POST ... Op_4 R DELETE DELETE ©2009 - Cesare Pautasso 40
  41. 41. BPEL for REST Make REST interaction primitives first-class language constructs BPEL for REST PUT ... <Put R> GET R <Get R> ... POST DELETE R> <Post R> <Delete R> <Delete R> ... ©2009 - Cesare Pautasso 41
  42. 42. BPEL for REST  Dynamically publish resources from BPEL processes and handle client requests BPEL for REST PUT <Resource P> PUT <onGet> <Put R> GET R <Get S> POST GET P </onGet> DELETE <onDelete> PUT POST DELETE <Post R> <Delete S> GET S </onDelete> </Resource> POST DELETE ©2009 - Cesare Pautasso 42
  43. 43. RESTful Workflows PUT P GET R POST DELETE Use the resource interface abstraction to publish the state of the workflow ©2009 - Cesare Pautasso 43
  44. 44. DoodleMap as RESTful workflow ©2009 - Cesare Pautasso 44
  45. 45. Conclusion  Applying the SOA composition principle to REST gives interesting results  Thanks to hyperlinks, REST brings a new (more dynamic and loosely coupled) twist to SOA composition  Composing RESTful services helps to build mashups, but is different  A RESTful API is the perfect abstraction for publishing the state of a workflow ©2009 - Cesare Pautasso 45
  46. 46. References  R. Fielding, Architectural Styles and the Design of Network- based Software Architectures, PhD Thesis, University of California, Irvine, 2000  C. Pautasso, O. Zimmermann, F. Leymann, RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision, Proc. of the 17th International World Wide Web Conference (WWW2008), Bejing, China, April 2008  C. Pautasso, BPEL for REST, Proc. of the 7th International Conference on Business Process Management (BPM 2008), Milano, Italy, September 2008  C. Pautasso, Composing RESTful Services with JOpera, In: Proc. of the International Conference on Software Composition (SC2009), July 2009, Zurich, Switzerland. © 46
  47. 47. Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso, SOA with REST, Prentice Hall, to appear in 2010 ©2009 - Cesare Pautasso 47

×