Mais conteúdo relacionado
Semelhante a Www2008 Restws Pautasso Talk (20)
Www2008 Restws Pautasso Talk
- 1. RESTful Web Services vs. Big Web Services:
Making the Right Architectural Decision
Cesare Pautasso Olaf Zimmermann Frank Leymann
University of Lugano IBM Zurich Research Lab University of Stuttgart
Switzerland Switzerland Germany
c.pautasso@ieee.org
http://www.pautasso.info http://soadecisions.org
25.4.2008 WWW2008 1
©2008 Cesare Pautasso
- 2. The only religious quote
http://www.loudthinking.com/arc/000585.html
25.4.2008 WWW2008 2
©2008 Cesare Pautasso
- 3. Can we really compare
WS-* vs. REST?
WS-* REST
25.4.2008 WWW2008 3
©2008 Cesare Pautasso
- 4. Can we really compare
WS-* vs. REST?
WS-* REST
Middleware Architectural
Interoperability style for
Standards the Web
25.4.2008 WWW2008 4
©2008 Cesare Pautasso
- 5. How to compare?
Arch itectural
Decision Modeling REST
WS-* Architectural
style for
Middleware the Web
Interoperability
Standards
25.4.2008 WWW2008 5
©2008 Cesare Pautasso
- 6. Architectural Decisions
• Architectural decisions Architectural Decision:
capture the main design Communication Protocol
issues and the rationale
behind a chosen technical Architecture Alternatives:
solution 1. TCP
• The choice between 2. SMTP
REST vs. WS-* is an 3. HTTP
important architectural 4. MQ
decision for 5. BEEP
integration projects
6. CORBA IIOP
• Architectural decisions 7. …
affect one another
Rationale
25.4.2008 WWW2008 6
©2008 Cesare Pautasso
- 7. Application Integration Styles
Shared Remote Message Bus File
Database Procedure Transfer
Call
REST WS-*
Integration Technology Platform
25.4.2008 WWW2008 7
©2008 Cesare Pautasso
- 8. Related Decisions (WS-*)
Shared Remote Message Bus File
Database Procedure Transfer
Call
REST WS-*
25.4.2008 WWW2008 8
©2008 Cesare Pautasso
- 9. Related Decisions (RPC)
Shared Remote Message Bus File
Database Procedure Transfer
Call
REST WS-*
25.4.2008 WWW2008 9
©2008 Cesare Pautasso
- 11. Outline
21 Decisions and 64 alternatives
Classified by level of abstraction:
• 3 Architectural Principles
• 9 Conceptual Decisions
• 9 Technology-level Decisions
Decisions help us to measure the
complexity implied by the choice of
REST or WS-*
25.4.2008 WWW2008 11
©2008 Cesare Pautasso
- 12. Architectural Principles
1. Protocol Layering
• HTTP = Application-level Protocol (REST)
• HTTP = Transport-level Protocol (WS-*)
2. Dealing with Heterogeneity
3. Loose Coupling
25.4.2008 WWW2008 12
©2008 Cesare Pautasso
- 13. RESTful Web Service Example
HTTP Client Web Server Database
(Web Browser)
SELECT *
GET /book?ISBN=222 FROM books
WHERE isbn=222
POST /order INSERT
INTO orders
301 Location: /order/612
POST /order/612 UPDATE orders
WHERE id=612
25.4.2008 WWW2008 13
©2008 Cesare Pautasso
- 14. Big Web Service Example
(from REST perspective)
Web Service
HTTP Client Web Server
Implementation
(Stub Object)
POST /soap/endpoint
return getBook(222)
POST /soap/endpoint
return new Order()
POST /soap/endpoint
order.setCustomer(x)
25.4.2008 WWW2008 14
©2008 Cesare Pautasso
- 15. Protocol Layering
• “The Web is the universe of globally • “The Web is the universal
accessible information” (tunneling) transport for messages”
(Tim Berners Lee) – Applications get a chance to
– Applications should publish their interact but they remain
data on the Web (through URI) “outside of the Web”
POX RSS JSON … SOAP (WS-*)
HTTP HTTP HTTP HTTP HTTP
SMTP MQ…
GET POST PUT DEL POST
Resource URI Endpoint URI
Application Application
25.4.2008 WWW2008 15
©2008 Cesare Pautasso
- 16. Dealing with Heterogeneity
• Web Applications • Enterprise Computing
Picture from Eric Newcomer, IONA
HTTP
CICS
IMS
25.4.2008 WWW2008 16
©2008 Cesare Pautasso
- 19. Measuring Complexity
• Architectural Decisions give a
quantitative measure of the complexity
of an architectural design space:
– Total number of decisions
– For each decision, number of alternative options
– For each alternative option, estimate the effort
REST WS-*
Decisions 17 14
Alternatives 27 35
Decisions with 1 or more alternative options
25.4.2008 WWW2008 19
©2008 Cesare Pautasso
- 20. Measuring Complexity
REST WS-*
Decisions 5 12
Alternatives 16 32
Decisions with more than 1 alternative options
REST WS-*
Decisions 17 14
Alternatives 27 35
Decisions with 1 or more alternative options
25.4.2008 WWW2008 20
©2008 Cesare Pautasso
- 21. Measuring Complexity
REST WS-*
Decisions 5 12
Alternatives 16 32
Decisions with more than 1 alternative options
• URI Design
• Resource Interaction Semantics
• Payload Format
• Service Description
• Service Composition
25.4.2008 WWW2008 21
©2008 Cesare Pautasso
- 22. Measuring Complexity
REST WS-*
Decisions 5 12
Alternatives 16 32
Decisions with more than 1 alternative options
REST WS-*
Decisions 12 2
Decisions with only 1 alternative option
25.4.2008 WWW2008 22
©2008 Cesare Pautasso
- 23. Measuring Complexity
• Payload Format
• Data Representation Modeling
REST WS-*
Decisions 12 2
Decisions with only 1 alternative option
25.4.2008 WWW2008 23
©2008 Cesare Pautasso
- 24. Measuring Effort
REST WS-*
Do-it-yourself 5 0
Alternatives
Decisions with only do-it-yourself alternatives
REST WS-*
Decisions 12 2
Decisions with only 1 alternative option
25.4.2008 WWW2008 24
©2008 Cesare Pautasso
- 25. Measuring Effort
REST WS-*
Do-it-yourself 5 0
Alternatives
Decisions with only do-it-yourself alternatives
• Resource Identification
• Resource Relationship
• Reliability
• Transactions
• Service Discovery
25.4.2008 WWW2008 25
©2008 Cesare Pautasso
- 27. Comparison Summary
• Architectural Decisions measure complexity
implied by alternative technologies
• REST simplicity = freedom from choice
– 5 decisions require to choose among 16 alternatives
– 12 decisions are already taken (but 5 are do-it-yourself)
• WS-* complexity = freedom of choice
– 12 decisions require to choose among 32 alternatives
– 2 decisions are already taken (SOAP, WSDL+XSD)
25.4.2008 WWW2008 27
©2008 Cesare Pautasso
- 28. Conclusion
• You should focus on whatever solution gets the
job done and try to avoid being religious about
any specific architectures or technologies.
• WS-* has strengths and weaknesses and will be
highly suitable to some applications and positively
terrible for others. Likewise with REST.
• The decision of which to use depends entirely on
the application requirements and constraints.
• We hope this comparison will help you make the
right choice.
25.4.2008 WWW2008 28
©2008 Cesare Pautasso
- 29. PhD positions available!
Cesare Pautasso
University of Lugano, Switzerland
c.pautasso@ieee.org
http://www.pautasso.info
25.4.2008 WWW2008 29
©2008 Cesare Pautasso
- 30. What is a “nice” URI?
Prefer Nouns to Verbs
http://map.search.ch/lugano Keep them Short
http://maps.google.com/lugano
http://maps.google.com/maps?f=q&hl=en&q=lugano,
+switzerland&layer=&ie=UTF8&z=12&om=1&iwloc=addr
25.4.2008 WWW2008 30
©2008 Cesare Pautasso