200211 Fielding Apachecon

773 views
728 views

Published on

Roy Fielding's powerpoint for his presentation at Apachecon in 2002.

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

  • Be the first to like this

No Downloads
Views
Total views
773
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

200211 Fielding Apachecon

  1. 1. waka: A replacement for HTTP Roy T. Fielding, Ph.D. Chief Scientist, Day Software Director, The Apache Software Foundation Co-founder, Apache HTTP Server Project Elected member, W3C Technical Architecture Group http://www.apache.org/~fielding/
  2. 2. How should we design a new application protocol? <ul><li>Define the architectural style </li></ul><ul><ul><li>Even a generic protocol must choose one model for evaluation of efficiency, or choose to be inefficient for all applications </li></ul></ul><ul><ul><li>Document desired architectural properties </li></ul></ul><ul><li>Identify the architectural elements </li></ul><ul><ul><li>Components, connectors, data </li></ul></ul><ul><ul><li>Interfaces, transports, media types </li></ul></ul><ul><li>Specify protocol </li></ul><ul><ul><li>Semantics = component interaction </li></ul></ul><ul><ul><li>Syntax = efficiency/extensibility </li></ul></ul>
  3. 3. But what about Web Services? <ul><li>ONC / DCE RPC </li></ul><ul><li>COM / DCOM </li></ul><ul><li>CORBA </li></ul><ul><li>J2EE </li></ul><ul><li>Web Services </li></ul><ul><li>.NET </li></ul><ul><ul><li>They have all tried to solve the same problem … </li></ul></ul>
  4. 4. EAI - the hard way 4 applications = 6 integrations 5 applications = 10 integrations 6 applications = 15 integrations app5 app1 app2 app3 app4
  5. 5. EAI - the Web way
  6. 6. High-level Web Requirements <ul><li>Low entry-barrier </li></ul><ul><ul><li>Hypermedia User Interface </li></ul></ul><ul><ul><li>Simple protocols for authoring and data transfer </li></ul></ul><ul><ul><li>Extensibility </li></ul></ul><ul><li>Multiple organizational boundaries </li></ul><ul><ul><li>Anarchic scalability </li></ul></ul><ul><ul><li>Heterogeneous platforms </li></ul></ul><ul><ul><li>Gradual and fragmented change (deployment) </li></ul></ul><ul><li>Distributed Hypermedia System </li></ul><ul><ul><li>Efficient for large data transfers </li></ul></ul><ul><ul><li>Sensitive to user-perceived latency </li></ul></ul><ul><ul><li>Capable of disconnected operation </li></ul></ul>
  7. 7. REST Architectural Style <ul><li>My dissertation work at UC Irvine </li></ul><ul><ul><li>available on Web [Fielding 2000] </li></ul></ul><ul><ul><li>independent discussion on RESTWiki [Baker et al.] </li></ul></ul><ul><li>An architectural style can be used to define the principles behind the Web architecture such that they are visible to future architects </li></ul><ul><ul><li>A style is a named set of constraints on architectural elements </li></ul></ul><ul><li>REST was used to guide definition and implementation of modern Web architecture </li></ul><ul><ul><li>modifications to HTTP and URI </li></ul></ul><ul><ul><li>implementations in Apache, libwww-perl, … </li></ul></ul>
  8. 8. REST Style Derivation Graph Virtual Machine Code-On-Demand LCS Layered System Stateless Client Server Cache Replicated Repository REST Uniform Interface
  9. 9. REST Process View <ul><li>Layered Client-Server </li></ul><ul><li>Uniform Interface (like Pipe and Filter) </li></ul><ul><li>Stateless, Cacheable Communication </li></ul><ul><li>Optional Code-on-Demand </li></ul>$ $ $ $ $ $ $ $
  10. 10. REST Uniform Interface <ul><li>Pictures are not sufficient </li></ul><ul><ul><li>We must define constraints that enforce a uniform interface </li></ul></ul><ul><li>Five primary interface constraints </li></ul><ul><ul><li>Resource is unit of identification </li></ul></ul><ul><ul><li>Resource is manipulated through exchange of representations </li></ul></ul><ul><ul><li>Resource-generic interaction semantics </li></ul></ul><ul><ul><li>Self-descriptive messaging </li></ul></ul><ul><ul><li>Hypermedia is engine of application state </li></ul></ul>
  11. 11. Hypertext Transfer Protocol <ul><li>The role of HTTP in Web Architecture </li></ul><ul><ul><li>Extend uniform interface across the net </li></ul></ul><ul><ul><li>Minimize user-perceived latency </li></ul></ul><ul><ul><li>Enable layered processing </li></ul></ul><ul><ul><li>Enable caching </li></ul></ul><ul><ul><li>Enable extension and evolution </li></ul></ul><ul><li>Already survived a decade of evolution </li></ul><ul><ul><li>1991-93: HTTP/0.9 [Berners-Lee] </li></ul></ul><ul><ul><li>1993-97: HTTP/1.0 [RFC 1945] </li></ul></ul><ul><ul><li>1996-now: HTTP/1.1 [RFC 2068/2616] </li></ul></ul>
  12. 12. HTTP Message Syntax <ul><ul><li>GET /Test/hello.html HTTP/1.1 </li></ul></ul><ul><ul><li>Host: kiwi.ics.uci.edu:8080 </li></ul></ul><ul><ul><li>Accept: text/html, text/*, */* </li></ul></ul><ul><ul><li>User-Agent: GET/7 libwww-perl/5.40 </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>HTTP/1.1 200 OK </li></ul></ul><ul><ul><li>Date: Thu, 09 Mar 2000 15:40:09 GMT </li></ul></ul><ul><ul><li>Server: Apache/1.3.12 </li></ul></ul><ul><ul><li>Content-Type: text/html </li></ul></ul><ul><ul><li>Content-Language: en </li></ul></ul><ul><ul><li>Transfer-Encoding: chunked </li></ul></ul><ul><ul><li>Etag: “a797cd-465af” </li></ul></ul><ul><ul><li>Cache-control: max-age=3600 </li></ul></ul><ul><ul><li>Vary: Accept-Language </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>4090 </li></ul></ul><ul><ul><li><HTML><HEAD> </li></ul></ul><ul><ul><li>… </li></ul></ul>
  13. 13. HTTP Current Problems <ul><li>HTTP/1.1 was limited by pre-existing syntax </li></ul><ul><ul><li>Overhead of MIME-style message syntax </li></ul></ul><ul><ul><li>Head-of-line blocking on interactions </li></ul></ul><ul><ul><li>Metadata unable to come after data </li></ul></ul><ul><ul><li>Server can’t send unsolicited responses </li></ul></ul><ul><li>Messages are not fully self-descriptive </li></ul><ul><ul><li>Extensions don’t indicate scope, mandatory/optional </li></ul></ul><ul><ul><li>Response messages don’t indicate request </li></ul></ul><ul><li>Low-power and bandwidth-sensitive devices </li></ul><ul><ul><li>More severely impacted than desktop browsers </li></ul></ul><ul><ul><li>Typical solution: impose a gateway </li></ul></ul><ul><ul><ul><li>device-specific, proprietary protocol </li></ul></ul></ul><ul><ul><ul><li>loss of fidelity in communication due to evolution </li></ul></ul></ul><ul><ul><ul><li>fails when devices roam across networks </li></ul></ul></ul>
  14. 14. It’s time for a new standard <ul><li>A new protocol standard could solve HTTP’s current problems in a generic way </li></ul><ul><li>However, building consensus around a new protocol isn't easy </li></ul><ul><ul><li>How do we differentiate from existing protocols, particularly those that are supposedly generic? </li></ul></ul><ul><ul><li>How do we decide among conflicting design alternatives for a new protocol? </li></ul></ul><ul><ul><li>How do we design such that the protocol can be deployed in a heterogeneous environment? </li></ul></ul><ul><li>I use the REST architectural style as a guide </li></ul>
  15. 15. Waka <ul><li>A new protocol designed to match efficiency of REST architectural style </li></ul><ul><li>Why “waka”? </li></ul><ul><ul><li>Mäori word (pronounced “wah-kah”) for the outrigger canoes used to travel safely on the Pacific Ocean, across hundreds of islands, to Aotearoa (New Zealand) </li></ul></ul><ul><ul><li>One of the few four-letter words suitable for a protocol name </li></ul></ul><ul><li>Deployable within an HTTP connection </li></ul><ul><ul><li>via the HTTP/1.1 Upgrade header field </li></ul></ul><ul><ul><li>defined mapping to HTTP/1.1 for proxies </li></ul></ul>
  16. 16. New Request Semantics <ul><li>RENDER method </li></ul><ul><ul><li>display/print/speak this representation </li></ul></ul><ul><li>MONITOR method </li></ul><ul><ul><li>notify me when resource state changes </li></ul></ul><ul><li>Authoring methods (DAV simplified) </li></ul><ul><ul><li>elimination of non-resource identifiers </li></ul></ul><ul><ul><li>reintroduction of PATCH </li></ul></ul><ul><li>Request control data </li></ul><ul><ul><li>request identifier </li></ul></ul><ul><ul><li>transaction identifier </li></ul></ul><ul><ul><li>relative priority </li></ul></ul>
  17. 17. New Response Semantics <ul><li>Self-descriptive binding to the request </li></ul><ul><ul><li>Echo of request id, method, target URI </li></ul></ul><ul><ul><li>Cache key explicitly described </li></ul></ul><ul><ul><ul><li>Caches no longer need to save request fields </li></ul></ul></ul><ul><ul><ul><li>Caches don’t have to guess about Vary info </li></ul></ul></ul><ul><ul><li>Enables asynchronous transport </li></ul></ul><ul><li>Response indicates authoritative or not </li></ul><ul><ul><li>Semantics formerly in status code </li></ul></ul><ul><li>Unsolicited Responses </li></ul><ul><ul><li>Cache invalidation messages </li></ul></ul><ul><ul><li>Multicast event notices </li></ul></ul>
  18. 18. Waka Syntax <ul><li>Uniform syntax </li></ul><ul><ul><li>Regardless of message type, direction </li></ul></ul><ul><ul><li>Padding allowed for 32/64bit alignment </li></ul></ul><ul><li>Self-descriptive </li></ul><ul><ul><li>Explicit typing for message structure, fields </li></ul></ul><ul><ul><li>Indication of mandate and scope of fields </li></ul></ul><ul><ul><li>Association of metadata (control, resource, rep.) </li></ul></ul><ul><ul><li>Premature termination of request or response </li></ul></ul><ul><li>Efficient and Extensible </li></ul><ul><ul><li>Tokens for all standard elements </li></ul></ul><ul><ul><li>A URI reference can be used in place of any token </li></ul></ul><ul><ul><li>Macros (client-defined syntax short-hand) </li></ul></ul><ul><ul><li>Interleaved data and metadata delivery </li></ul></ul>
  19. 19. A work just beginning <ul><li>waka </li></ul><ul><ul><li>Has not yet been fully specified </li></ul></ul><ul><ul><li>Has not yet been implemented </li></ul></ul><ul><ul><li>Has not yet been deployed </li></ul></ul><ul><ul><li>Will eventually be proposed as ASF project </li></ul></ul><ul><ul><li>Will eventually be submitted to IETF </li></ul></ul><ul><ul><li>Will have its progress tracked: </li></ul></ul><ul><li>http://www.apache.org/~fielding/waka/ </li></ul>
  20. 21. Web Architecture <ul><li>Understanding the Web’s Success </li></ul><ul><ul><li>Design Notes of Tim Berners-Lee </li></ul></ul><ul><ul><li>Representational State Transfer (REST) </li></ul></ul><ul><ul><li>W3C Technical Architecture Group </li></ul></ul><ul><li>Goals </li></ul><ul><ul><li>Document existing design principles </li></ul></ul><ul><ul><li>Identify methods for evaluating </li></ul></ul><ul><ul><ul><li>existing identifiers, formats, protocols </li></ul></ul></ul><ul><ul><ul><li>proposals for new features </li></ul></ul></ul><ul><ul><ul><li>proposals for new interaction styles </li></ul></ul></ul><ul><ul><li>Define new design principles </li></ul></ul>
  21. 22. Principled Architecture Design <ul><li>Iterating over: </li></ul><ul><ul><li>Analyze system </li></ul></ul><ul><ul><ul><li>Focus on one phase of operation </li></ul></ul></ul><ul><ul><ul><li>Choose a level of abstraction </li></ul></ul></ul><ul><ul><ul><li>Identify components, connectors, data </li></ul></ul></ul><ul><ul><li>Establish requirements </li></ul></ul><ul><ul><ul><li>What must be true across phase of operation </li></ul></ul></ul><ul><ul><li>Select design principles </li></ul></ul><ul><ul><ul><li>Principles motivate architectural constraint </li></ul></ul></ul><ul><ul><li>Constrain the architecture </li></ul></ul><ul><ul><ul><li>Constraints induce architectural properties </li></ul></ul></ul>
  22. 23. Example Requirements <ul><li>Web as a system must exist at the operational scale of entire societies </li></ul><ul><ul><li>no &quot;on&quot; or &quot;off&quot; switch </li></ul></ul><ul><ul><li>system must evolve while in use </li></ul></ul><ul><li>Change is inevitable </li></ul><ul><ul><li>requires planning for evolution </li></ul></ul><ul><li>Spans multiple organizations </li></ul><ul><ul><li>changes cannot be deployed all at once </li></ul></ul><ul><ul><li>requires gradual and fragmented change </li></ul></ul>
  23. 24. Example Principles <ul><li>Information hiding </li></ul><ul><ul><li>a component's visibility into the implementation of another component should be limited to what is necessary to interoperate with its interface </li></ul></ul><ul><ul><li>prevents unintended assumptions about component behavior that may not hold true in the future </li></ul></ul><ul><ul><li>applied to improve property of evolvability -- independent evolution of technology over time </li></ul></ul><ul><li>Separation of concerns </li></ul><ul><ul><li>a component that performs two or more separate activities is better implemented as two or more components if doing so increases cohesion and reduces coupling </li></ul></ul><ul><ul><li>applied to improve properties of simplicity and evolvability </li></ul></ul>
  24. 25. Example Constraint <ul><li>Orthogonal protocols deserve orthogonal specifications </li></ul><ul><ul><li>If one protocol uses another as data, it must not restrict the content of that data other than as defined by that protocol, including future compatible revisions of that protocol. </li></ul></ul><ul><ul><li>A specification that defines two orthogonal protocols (including data formats) must be split into two specifications, since otherwise the independent evolution of those protocols will be hindered. </li></ul></ul><ul><li>Result is simpler protocols </li></ul><ul><ul><li>able to evolve independently over time </li></ul></ul><ul><ul><li>enables system to continue operation through gradual and fragmented change </li></ul></ul>

×