Oopsla 2007 - The Web: Distributed Objects Realized!


Published on

Mark Baker & Stuart Charlton's tutorial on RESTful web services

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Oopsla 2007 - The Web: Distributed Objects Realized!

  1. 1. The Web: Distributed Objects Realized! Mark Baker, Coactus Consulting Stuart Charlton, BEA Systems
  2. 2. About Us <ul><li>Mark Baker Coactus Consulting </li></ul><ul><li>CTO-level consulting and large-scale distributed systems architect </li></ul><ul><li>Leading proponent of “REST style web services” for over seven years </li></ul><ul><li>Prior work at Nortel, Sun Microsystems, and several startups </li></ul><ul><li>Co-developed internet, mobile, and web standards through the IETF , W3C , and OMA </li></ul><ul><li>Mark’s Blog http://www.markbaker.ca/blog/ </li></ul><ul><li>mailto:mark@coactus.com </li></ul><ul><li>Stuart Charlton BEA Systems </li></ul><ul><li>Enterprise architect in BEA’s Consulting practice </li></ul><ul><li>Co-develops BEA’s global consulting strategy and service offerings </li></ul><ul><li>Specialized in distributed systems architecture, data warehousing, and object technology </li></ul><ul><li>Prior work in EA, consulting, and mentoring both the financial services & telecommunications industries </li></ul><ul><li>Stu Says Stuff http://stucharlton.com/blog/ </li></ul><ul><li>mailto:stuart.charlton@bea.com </li></ul>
  3. 3. Agenda <ul><li>Part 1 </li></ul><ul><li>How We Got Here </li></ul><ul><li>Understanding Distributed Object Interoperability </li></ul><ul><li>Exploring the Design of REST </li></ul><ul><ul><li>Identity and Reference </li></ul></ul><ul><ul><li>Handling Evolution </li></ul></ul><ul><ul><li>Multi-Organizational Interoperability </li></ul></ul><ul><ul><li>Control Flow through Hypermedia </li></ul></ul><ul><li>Part 2 </li></ul><ul><li>RESTful Web Services in Action </li></ul><ul><li>Exploring the Web’s Architecture </li></ul><ul><li>Applied Techniques for RESTful Web Services </li></ul><ul><ul><li>Resources-Oriented Architecture </li></ul></ul><ul><ul><li>Security Approaches </li></ul></ul><ul><ul><li>Transactions & Reliability </li></ul></ul>
  4. 4. How We Got Here The Rise of the Object Web
  5. 5. Where we’ve come from… <ul><li>“ The next shift catalyzed by the Web will be the adoption of enterprise systems based on distributed objects and IIOP (Internet Inter-ORB Protocol). IIOP will manage the communication between the object components that power the system. Users will be pointing and clicking at objects available on IIOP-enabled servers.” </li></ul><ul><li>- Marc Andressen, Netscape Cofounder (October, 1996) </li></ul>
  6. 6. The Object Web Shall Arise! <ul><li>“To move to the next step, the Web needs distributed objects. We call this next wave of Internet innovation the &quot;Object Web.“ </li></ul><ul><li>The HTTP form you submit is still the basic unit of client/server interaction. This clumsy work-around is not suitable for full-blown client/server applications that require highly interactive conversations between components. It also does not scale well.” </li></ul><ul><li>- CORBA, Java, and the Object Web BYTE Magazine (October 1997) </li></ul>
  7. 8. By 1999…. XML Web Services Shall Arise! <ul><li>…Over the past decade, component technology has been the cause of many arguments, disagreements, and debates . This component-induced friction can be traced to two primary factors: </li></ul><ul><li>1. “My Glue is Better than Your Glue” </li></ul><ul><li>2. “I Can’t Believe You Program In That Language” </li></ul><ul><ul><ul><ul><ul><li>- Don Box Lessons from the Component Wars: An XML Manifesto (September 1999) </li></ul></ul></ul></ul></ul>
  8. 9. By the mid-2000s…. what about “just” the Web?
  9. 10. Our Claims: <ul><li>The dream of the “Object Web” is largely here: it’s the Web! </li></ul><ul><li>Constraints in a systems architecture lead to emergent properties . </li></ul><ul><li>The Representational State Transfer (REST) architectural style defines constraints which helped guide the web towards a globally scalable, interoperable, and extensible system. </li></ul><ul><li>The REST architectural style is both an evolution of past approaches to networked computing, and a radical departure . </li></ul><ul><li>More work remains to be done! </li></ul>
  10. 11. Understanding Distributed Object Interoperability
  11. 12. The Distributed Object Request Broker (ORB) <ul><li>The Goals of an ORB: </li></ul><ul><li>Encapsulate all of the mechanisms to: </li></ul><ul><ul><ul><li>Find the object for the request </li></ul></ul></ul><ul><ul><ul><li>Prepare the implementation to receive the request </li></ul></ul></ul><ul><ul><ul><li>Communicate the data making up the request </li></ul></ul></ul><ul><li>Ensure complete transparency of object location and implementation </li></ul>
  12. 13. Inside an Object Request Broker <ul><li>Source: OMG CORBA 2.3 Architecture & Specification </li></ul>
  13. 14. How can a web of distributed objects span organizations?
  14. 15. Interoperability Domains <ul><li>A distributed system, even if the goal is transparency, has several co-existing domains of interoperability </li></ul><ul><li>A domain is a set of objects sharing a common characteristic or abiding by common rules. </li></ul><ul><li>Source: OMG CORBA 2.3 Architecture & Specification </li></ul>
  15. 16. Types of Interoperability Domains <ul><li>Referencing </li></ul><ul><ul><li>The scope of a distributed object reference </li></ul></ul><ul><li>Representation </li></ul><ul><ul><li>The scope of a message transfer syntax & protocol </li></ul></ul><ul><li>Network Connectivity </li></ul><ul><ul><li>Potential scope of a network message </li></ul></ul><ul><li>Network Addressing </li></ul><ul><ul><li>Potential scope of a network address </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>The extent of a particular security policy </li></ul></ul><ul><li>Others… </li></ul><ul><li>Source: OMG CORBA 2.3 Architecture & Specification </li></ul>
  16. 17. Solutions to Multiple Interoperability Domains <ul><li>Canonicalization </li></ul><ul><li>Simple and scalable, at the cost of reduced runtime performance </li></ul><ul><li>Low barrier to entry for new clients , high barrier for new servers </li></ul><ul><li>Point-to-Point Adaptation </li></ul><ul><li>Good runtime performance, not as scalable, increasing complexity </li></ul><ul><li>Low barrier to entry for new servers , high entry for new clients </li></ul>Canonical Domain Domain A Domain B Domain A Domain C Domain B
  17. 18. Solutions for a “Global Object Web”? <ul><li>Goal seems to be primarily about use and reuse: more consumption </li></ul><ul><ul><li>Thus, lower the barriers to new clients! </li></ul></ul><ul><li>Scope of Object References: Global </li></ul><ul><li>Scope of Representation: Global (but extensible) </li></ul><ul><li>Scope of Network Connectivity: Global </li></ul><ul><li>Scope of Security: Shared Agreement </li></ul><ul><ul><li>Requires at least some level of Global Canonicalization </li></ul></ul>
  18. 19. Solutions for a “Global Object Web”? <ul><li>Further Concerns: </li></ul><ul><li>Unpredictable type, usage, and volume of information </li></ul><ul><ul><li>Thus, shaped around extensible, streamable, cacheable, identifiable information </li></ul></ul><ul><li>Both Human and Automated actors </li></ul><ul><ul><li>Thus, simple, reusable, and extensible interfaces, appropriate for either </li></ul></ul><ul><li>… How would you architect such a system? </li></ul><ul><ul><li>This is atypical of most distributed object systems architectures in practice </li></ul></ul>
  19. 20. Two Very Different Types of Architectural Domains <ul><li>Client or Builder-focused </li></ul><ul><ul><li>Identifiable Client or Customer(s) </li></ul></ul><ul><ul><li>Clearly identifiable builders </li></ul></ul><ul><ul><li>Clearly identifiable users </li></ul></ul><ul><ul><li>Control governance & control </li></ul></ul><ul><ul><li>Overall architectural control </li></ul></ul><ul><ul><li>System is a result of deliberate value judgement by the client </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Most IT projects, software products, civil structures, etc. </li></ul></ul><ul><li>Collaborative Systems </li></ul><ul><ul><li>No identifiable client </li></ul></ul><ul><ul><li>Many builders </li></ul></ul><ul><ul><li>Many (unpredictable) users </li></ul></ul><ul><ul><li>No central control in terms of development, or operation </li></ul></ul><ul><ul><li>System is a result of the voluntary choices of the participants </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Internet and WWW, electrical power systems, joint military operations, etc. </li></ul></ul><ul><li>Source: Eberherdt Rechtin, The Art of Systems Architecting </li></ul>
  20. 21. Building Emergent Capability into an Architecture <ul><li>Collaborative systems are about creating emergent capability </li></ul><ul><li>The architecture of the system is the constraints on interfaces </li></ul><ul><ul><li>Components & implementations are out of scope and out of control </li></ul></ul><ul><li>An example style of such constraints: </li></ul><ul><ul><li>Client/Server Architecture </li></ul></ul><ul><ul><li>Constraints: </li></ul></ul><ul><ul><ul><li>Active client, Reactive server, client initiates communication </li></ul></ul></ul><ul><ul><li>Emergent properties: </li></ul></ul><ul><ul><ul><li>Simplifies server, enables multiple organizational domains </li></ul></ul></ul>Client Server
  21. 22. Composing Constraints into an Architectural Style <ul><li>Constraints both enable and detract from emergent properties, and may be combined together </li></ul><ul><li>Example: </li></ul><ul><ul><li>Client/Server + Layered System + Caching + Stateless Interaction </li></ul></ul><ul><li>Enables: </li></ul><ul><ul><li>Simplified Clients and Servers (due to statelessness & C/S) </li></ul></ul><ul><ul><li>Shared Caching (due to layering) </li></ul></ul><ul><ul><li>Improved Visibility & Reliability (due to statelessness) </li></ul></ul><ul><li>Add in: </li></ul><ul><ul><li>Code on Demand (COD) </li></ul></ul><ul><li>Result: </li></ul><ul><ul><li>Simplifies clients, Improves Extensibility, but Reduces Visibility </li></ul></ul><ul><li>Source: Roy Fielding, Architectural Styles and the Design of Network-Based Software Architectures </li></ul>
  22. 23. The Representational State Transfer (REST) Style <ul><li>Originally referred to as “The HTTP Object Model” </li></ul><ul><li>Source: Roy Fielding, Architectural Styles and the Design of Network-Based Software Architectures </li></ul>
  23. 24. Some Major Differences between REST and Distributed Objects <ul><li>1. Most distributed architectures do not assume application requirements </li></ul><ul><ul><li>Yet, the Web is an application with goals & requirements! </li></ul></ul><ul><ul><li>The overall goal: sharing information and capabilities at a global scale </li></ul></ul><ul><ul><li>REST assumes the requirement is to provide an architecture of participation for a globally networked information space </li></ul></ul><ul><li>2. Most distributed architectures do not require globally scoped interoperability domains </li></ul><ul><ul><li>REST insists on a uniform interface to ensure global scope interoperability </li></ul></ul><ul><ul><li>The uniform interface is what we explore next! </li></ul></ul><ul><li>These differences apply elsewhere: SOAP Web Services, RPC, etc. are also just general toolkits </li></ul>
  24. 25. RESTful Distributed Objects in contrast to SOAP Web Services <ul><li>Perceived advantages: </li></ul><ul><li>Communication occurs through XML document exchange </li></ul><ul><ul><li>Agreement occurs in the network protocol </li></ul></ul><ul><li>The XML InfoSet is the basis of interoperability </li></ul><ul><ul><li>No worrying about object-oriented purity / language-oriented bindings </li></ul></ul><ul><li>Disadvantages: </li></ul><ul><ul><li>Prefers interface descriptions for specific (non-uniform) interfaces </li></ul></ul><ul><ul><li>All data must flow through the XML InfoSet, other types are secondary </li></ul></ul><ul><ul><li>Nearly eliminates the notions of: </li></ul></ul><ul><ul><ul><li>Object lifecycle (creation, removal, activation) </li></ul></ul></ul><ul><ul><ul><li>Object identification & references (i.e. linking) </li></ul></ul></ul><ul><ul><li>Assumes transfer protocol independence is possible and desirable </li></ul></ul><ul><ul><ul><li>In practice, transfer protocol semantics leak into message exchanges </li></ul></ul></ul>
  25. 26. A Word on REST vs. The World Wide Web <ul><li>Consider three levels of abstraction: </li></ul><ul><ul><li>Architectural Styles : Representation State Transfer (REST) </li></ul></ul><ul><ul><li>Architecture : The World Wide Web </li></ul></ul><ul><ul><li>Implementation : “User Agents, Web Servers, Proxies, etc.” </li></ul></ul><ul><li>REST is a model of constraints and emergent properties </li></ul><ul><li>The Web is the most widely used and understood implementation </li></ul>
  26. 27. Exploring the Design of REST
  27. 28. A Global, Networked, Shared Information Space
  28. 29. Users Consume & Manipulate Information via Agents
  29. 30. Information Objects Must Be Identifiable
  30. 31. An Object’s Interface is separated from Implementation
  31. 32. State is exchanged in a stateless, self-describing manner
  32. 33. Handling Evolution
  33. 34. Meaning is Determined by the Context of Relationships
  34. 35. Content & Relationships May Change Over Time...
  35. 36. ...But the Identity of Information Must Remain Stable
  36. 37. The Information Space consists of Identifiable Conceptual Mappings State (at a point in time) Object
  37. 38. Instead of Objects & State, REST calls these Resources & Representations Representation (at a point in time) Resource
  38. 39. The conceptual mapping should remain consistent over time! Concept Representation (at a point in time) Resource “ Customer 31319” Concept “ The state of Customer 31319 at a point in time” Server Client (stable)
  39. 40. Example: Different Representations Concept XML Document Resource “ Customer 31319” Concept “ The state of Customer 31319 at a point in time” Server Client (stable) CSV File
  40. 41. Multi-Organization Interoperability
  41. 42. An Organization Manages Information
  42. 43. Information Spans Organization Boundaries
  43. 44. Clients Span Organizational Boundaries
  44. 45. Clients & Infrastructure Evolve Independently
  45. 46. So, representations must be uniformly specified
  46. 47. What Domains are in a Representation? <ul><li>The means and intent of communication </li></ul><ul><ul><li>All clients and servers should at least be able to communicate, regardless of the particular resource </li></ul></ul><ul><ul><li>Thus, communication must be very generic and uniformly applicable to all resources </li></ul></ul><ul><li>The information bits themselves, along with their self-descriptive interpretation </li></ul><ul><ul><li>Information can be represented in many ways, even if it’s the same concept </li></ul></ul><ul><li>The references for the requested or related resources </li></ul><ul><ul><li>Relationships between a medium identifiers can denote the meaning of information </li></ul></ul>
  47. 48. How Stable Should the Domains of a Representation Be? Data Element Level of Stability Authority over Change Means & Intent of Communication Extremely Stable Global Representation of Information Very Stable Widely Shared Agreement Information Resource Identifier Stable Organization
  48. 49. Control Flow
  49. 50. Embed Control Flow Inside the Representation Itself
  50. 51. As Information is Manipulated or Conveyed, So Are The References for “Next Steps”
  51. 52. Hyperlinks Define the Possibilities for Communication
  52. 53. Application State is Held By the Agent
  53. 54. Summary of the REST Uniform Interface <ul><li>All valuable resources are identified by a globally scoped, uniform, resource identifier </li></ul><ul><ul><li>Simple, consistent ability to (de)reference both information & services </li></ul></ul><ul><li>Resources are manipulated through the exchange of representations </li></ul><ul><ul><li>Stateless, visible communication to encapsulated resources </li></ul></ul><ul><li>All exchanges are self-descriptive </li></ul><ul><ul><li>Enables visibility and extensibility </li></ul></ul><ul><li>All access methods mean the same for all resources </li></ul><ul><ul><li>Communication semantics are universal </li></ul></ul><ul><li>Hypermedia is the engine of application state </li></ul><ul><ul><li>Information and controls are intertwingled </li></ul></ul>
  54. 55. Agenda <ul><li>Part 1 </li></ul><ul><li>How We Got Here </li></ul><ul><li>Understanding Distributed Object Interoperability </li></ul><ul><li>Exploring the Design of REST </li></ul><ul><ul><li>Identity and Reference </li></ul></ul><ul><ul><li>Handling Evolution </li></ul></ul><ul><ul><li>Multi-Organizational Interoperability </li></ul></ul><ul><ul><li>Control Flow through Hypermedia </li></ul></ul><ul><li>Part 2 </li></ul><ul><li>RESTful Web Services in Action </li></ul><ul><li>Exploring the Web’s Architecture </li></ul><ul><li>Applied Techniques for RESTful Web Services </li></ul><ul><ul><li>Resources-Oriented Architecture </li></ul></ul><ul><ul><li>Security Approaches </li></ul></ul><ul><ul><li>Transactions & Reliability </li></ul></ul>
  55. 56. RESTful Web Services in Action
  56. 57. RESTful Light Bulbs <ul><li>Imagine any lightbulb, anywhere, is an HTTP-supported resource </li></ul><ul><li>Multiple representations might be supported </li></ul><ul><ul><li>Application/lightbulb+xml </li></ul></ul><ul><ul><li>An HTML form </li></ul></ul><ul><li>E.g. Turning on a lightbulb: </li></ul><ul><li>PUT http://example.com/kitchen/main HTTP/1.1 </li></ul><ul><li>Content-Type: application/ lightbulb +xml </li></ul><ul><li>< lightbulb > </li></ul><ul><li><state>on</state> </li></ul><ul><li></ lightbulb > </li></ul><ul><li>How does this impact the scale of our lightbulb system? </li></ul>
  57. 58. A Hypermedia Purchase Order <ul><li>Without URIs and Links </li></ul><ul><li>POST /purchaseOrders HTTP/1.1 </li></ul><ul><li><?xml version=&quot;1.0&quot;?> </li></ul><ul><li><updatePurchaseOrder> </li></ul><ul><li><purchaseOrder id=“31811” orderDate=&quot;1999-10-20&quot;> </li></ul><ul><li><shipTo country=&quot;US&quot;> </li></ul><ul><li><name>Alice Smith</name> </li></ul><ul><li><street>123 Maple Street</street> </li></ul><ul><li><city>Mill Valley</city> </li></ul><ul><li><state>CA</state> </li></ul><ul><li><zip>90952</zip> </li></ul><ul><li></shipTo> </li></ul><ul><li><items> </li></ul><ul><li><item partNum=&quot;872-AA&quot;> <quantity>1</quantity> </li></ul><ul><li><USPrice>148.95</USPrice> </li></ul><ul><li><comment>Confirm this is electric </li></ul><ul><li></comment> </li></ul><ul><li></item> </li></ul><ul><li></items> </li></ul><ul><li></purchaseOrder> </li></ul><ul><li></updatePurchaseOrder> </li></ul><ul><li>With URIs Hyperlinks </li></ul><ul><li>PUT /purchaseOrder/31811 HTTP/1.1 </li></ul><ul><li><?xml version=&quot;1.0&quot;?> </li></ul><ul><li><purchaseOrder orderDate=&quot;1999-10-20&quot;> </li></ul><ul><li><shipTo </li></ul><ul><li> href=“ http:// alice.com /address ”/> </li></ul><ul><li><items> </li></ul><ul><li><item href=“ http://lawnsrus.com/872-AA ”> </li></ul><ul><li><quantity>1</quantity> </li></ul><ul><li><comment>Confirm this is electric </li></ul><ul><li></comment> </li></ul><ul><li></item> </li></ul><ul><li></items> </li></ul><ul><li></purchaseOrder> </li></ul>How do either of these impact evolution over time?
  58. 59. Exposing Legacy Information as Resources <ul><li>Reusing web Infrastructure to support the legacy </li></ul><ul><li>E.g. Cacheable, Searchable, Composable Customer Data </li></ul>RESTful Web Service Gateway Legacy Customer Information System Composite App DB Web Cache Web Crawler http://company.com/customer/30133 Other Resources
  59. 60. Exploring the Web Architecture Highlights
  60. 61. A View of the Current Web Architecture BEA Confidential | Web Architecture Foundation Internet Protocol Foundation Hypertext Transfer Protocol (HTTP) Security & Authentication Management & Caching BGP Application Protocol Standards ARP DNS IP TCP Multipurpose Internet Mail Extensions (MIME) Media Types HTML XML RSS / Atom URI/IRI Unicode JavaScript Images Video JSON Form data Interoperability Crawlers User Agents Semantic Web Microformats Web Sites Resource-Oriented System Interfaces Content Syndication
  61. 62. Inside an Object Request Broker <ul><li>Source: OMG CORBA 2.3 Architecture & Specification </li></ul>
  62. 63. The New ORB: A Web Server
  63. 64. Hypertext Transfer Protocol <ul><ul><li>GET /docs/2.2/ HTTP/1.1 </li></ul></ul><ul><ul><li>Host: httpd.apache.org </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, 31 Jul 2007 15:40:09 GMT </li></ul></ul><ul><ul><li>Server: Apache/2.2.4 </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: “b381faa81c” </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>
  64. 65. Highlights of the HTTP Interface <ul><li>Methods </li></ul><ul><li>GET </li></ul><ul><ul><li>Retrieve a resource’s state </li></ul></ul><ul><li>PUT </li></ul><ul><ul><li>Store/replace a resource’s state </li></ul></ul><ul><li>POST </li></ul><ul><ul><li>Create/append to a resource’s state </li></ul></ul><ul><li>DELETE </li></ul><ul><ul><li>Remove a resource’s state </li></ul></ul><ul><li>HEAD </li></ul><ul><ul><li>Retrieve resource & control metadata </li></ul></ul><ul><li>OPTIONS </li></ul><ul><ul><li>Retrieve what methods are supported </li></ul></ul><ul><li>TRACE </li></ul><ul><ul><li>Retrieve a loop-back of the request </li></ul></ul><ul><li>CONNECT </li></ul><ul><ul><li>Request that a proxy tunnel the request </li></ul></ul><ul><li>Response Code Ranges </li></ul><ul><li>100…Informational </li></ul><ul><li>200…Success indicators </li></ul><ul><ul><li>Request has succeeded </li></ul></ul><ul><ul><li>New resource created </li></ul></ul><ul><li>300…Redirection </li></ul><ul><ul><li>Content negotiation </li></ul></ul><ul><ul><li>Resources that have moved permanently or temporarily </li></ul></ul><ul><ul><li>Cacheable resources that have not changed </li></ul></ul><ul><li>400…Bad Requests </li></ul><ul><ul><li>Method not supported </li></ul></ul><ul><ul><li>Unauthorized access </li></ul></ul><ul><ul><li>Resource not found currently or permanently </li></ul></ul><ul><li>500…Server Errors </li></ul><ul><ul><li>Feature not implemented </li></ul></ul><ul><ul><li>Service temporarily unavailable </li></ul></ul><ul><ul><li>Internal server errors </li></ul></ul>
  65. 66. How Stable Should a Web Representation Be? Data Element Level of Stability Authority over Change Means & Intent of Communication (e.g. identifiers, operations & metadata) Extremely Stable Global (HTTP & URI Syntax) Representation of Information Very Stable Widely Shared Agreement (MIME Types) Information Resource Identifier Stable Organization (Allocated URIs)
  66. 67. How does a Client Understand its Information? <ul><li>Stable , standardized, streaming media formats </li></ul><ul><ul><li>Multipurpose Internet Mail Extensions (MIME) Types </li></ul></ul><ul><ul><li>Generic containers for more specific information </li></ul></ul><ul><li>The context of relationships to other identifiers </li></ul><ul><ul><li>Information may embed links within a document </li></ul></ul><ul><ul><li>E.g. an HTML tag <IMG SRC=“http://images/customer/31319...”> implies: </li></ul></ul><ul><ul><ul><li>A link is to an associated resource </li></ul></ul></ul><ul><ul><ul><li>This resource should respond to HTTP GET </li></ul></ul></ul><ul><ul><ul><li>This resource will be an image of some type </li></ul></ul></ul><ul><li>Code-on-demand that can interpret the information for the client </li></ul><ul><ul><li>E.g. Java Applets, ActiveX Controls, Flash Plug-ins, JavaScript, AJAX </li></ul></ul>
  67. 68. Intermediaries <ul><li>Proxies are client-determined intermediaries </li></ul><ul><li>Gateways are server-determined intermediaries </li></ul><ul><li>Caching with HTTP Conditional GET </li></ul><ul><ul><li>GET /docs/2.2/ HTTP/1.1 </li></ul></ul><ul><ul><li>Host: httpd.apache.org </li></ul></ul><ul><ul><li>Accept: text/html, text/*, */* </li></ul></ul><ul><ul><li>If-None-Match: “38d8af8210bb” </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>HTTP/1.1 304 Not Modified </li></ul></ul><ul><ul><li>Content-Type: text/html </li></ul></ul><ul><ul><li>Content-Length: 0 </li></ul></ul><ul><ul><li>ETag: “38d8af8210bb” </li></ul></ul><ul><ul><li> </li></ul></ul>Proxy User Agent (Browser) Gateway Server
  68. 69. Some flaws in the Deployed Web Architecture <ul><li>MIME Types </li></ul><ul><ul><li>Benefit: reuse most of the metadata and media descriptions for email </li></ul></ul><ul><ul><li>But, designed for Email, not the web </li></ul></ul><ul><ul><li>Focus on packaging lots of information into a single package </li></ul></ul><ul><ul><ul><li>Hypermedia prefers linking to subsets </li></ul></ul></ul><ul><ul><li>Workarounds for layered content </li></ul></ul><ul><ul><ul><li>e.g. GZIP transfer encoding of a text/html document </li></ul></ul></ul><ul><ul><li>Assumes a lossy transport </li></ul></ul><ul><ul><li>Centralized type registry </li></ul></ul><ul><li>Cookies </li></ul><ul><ul><li>Site-wide opaque data </li></ul></ul><ul><ul><ul><li>Reduced visibility, privacy, and security </li></ul></ul></ul><ul><ul><li>Can lead to counter-intuitive behaviour </li></ul></ul><ul><ul><ul><li>Some sites do not handle the browser’s back button </li></ul></ul></ul><ul><ul><li>Persistent data should be a resource </li></ul></ul><ul><ul><ul><li>Eg. A Shopping Cart URI </li></ul></ul></ul><ul><ul><ul><li>But, requires browser extensibility </li></ul></ul></ul><ul><ul><ul><li>Alternatives are emerging with the popularity of AJAX-like techniques to store & retrieve preferences </li></ul></ul></ul>
  69. 70. Applied Techniques for RESTful Web Services
  70. 71. A Design Method for Resource-Oriented Architecture <ul><li>Figure out the data set </li></ul><ul><li>Split the data set into resources </li></ul><ul><li>For each resource: </li></ul><ul><ul><li>Name the resources with URIs </li></ul></ul><ul><ul><li>Expose a subset of the HTTP interface </li></ul></ul><ul><ul><li>Design the representation(s) accepted from the client </li></ul></ul><ul><ul><li>Design the representation(s) served to the client </li></ul></ul><ul><ul><li>Integrate this resource to others, using hypermedia links and forms </li></ul></ul><ul><li>Consider use cases </li></ul><ul><ul><li>Apply standard hypermedia types (e.g. HTML, Atom), where applicable </li></ul></ul><ul><li>Consider error conditions </li></ul><ul><ul><li>Apply standard hypermedia types (e.g. HTML, Atom), where applicable </li></ul></ul>
  71. 72. Common & Emerging Hypermedia Types <ul><li>The big six: </li></ul><ul><li>XHTML, HTML, Flash, PDF, RSS, and Atom </li></ul><ul><li>Emerging: </li></ul><ul><li>Atom Publishing Protocol, HTML Microformats </li></ul><ul><li>On the horizon : </li></ul><ul><li>HTML 5 </li></ul><ul><li>RDF, GRDDL and Semantic Web standards </li></ul><ul><li>Media types usually define a general purpose control flow: </li></ul>
  72. 73. RESTful Security Approaches <ul><li>Identity Assertion </li></ul><ul><ul><li>OpenID </li></ul></ul><ul><ul><ul><li>URI-based digital identity </li></ul></ul></ul><ul><ul><ul><li>Open ID 2.0 is adding attributes, secure messages </li></ul></ul></ul><ul><ul><li>Kerberos / SPNEGO </li></ul></ul><ul><ul><ul><li>Popular on intranets, requires a server </li></ul></ul></ul><ul><ul><ul><li>Not likely internet scalable </li></ul></ul></ul><ul><ul><ul><li>Current implementations require excessive round-trips </li></ul></ul></ul>
  73. 74. RESTful Message Confidentiality & Integrity <ul><li>Mutual SSL </li></ul><ul><ul><li>Robust, widely supported </li></ul></ul><ul><ul><li>Does not enable intermediary visibility or persistent signatures </li></ul></ul><ul><li>XML Signature & Encryption </li></ul><ul><ul><li>But XML Canonicalization is extremely complicated </li></ul></ul><ul><li>S/MIME or PGP </li></ul><ul><ul><li>Key negotiation is usually out of band </li></ul></ul><ul><ul><ul><li>OpenID 2.0 may help </li></ul></ul></ul><ul><ul><li>Widely deployed within the email system (perhaps not as widely used ) </li></ul></ul><ul><ul><li>Fits within existing HTTP infrastructure </li></ul></ul><ul><ul><li>Not widely deployed within HTTP </li></ul></ul><ul><ul><li>Limitations: http://blog.jclark.com/2007/10/why-not-smime.html </li></ul></ul>Image: Mark Wahl, ldap.com
  74. 75. Transactions & Lost Updates <ul><li>Conditional PUT </li></ul><ul><ul><li>A RESTful approach to optimistic locking </li></ul></ul><ul><ul><li>PUT /test_resource HTTP/1.1 </li></ul></ul><ul><ul><li>Host: bea.com </li></ul></ul><ul><ul><li>Accept: */* </li></ul></ul><ul><ul><li>Expect: 100-continue </li></ul></ul><ul><ul><li>If-None-Match: “381fa9311bc” </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li>HTTP/1.1 412 Precondition Failed </li></ul></ul><ul><ul><li>Date: Thu, 31 Jul 2007 15:40:09 GMT </li></ul></ul><ul><ul><li>Server: Apache/2.2.4 </li></ul></ul><ul><ul><li>Content-Type: text/html </li></ul></ul>
  75. 76. RESTful Distributed Transactions <ul><li>Design Sketch: Resource-Oriented Units of Work </li></ul><ul><ul><li>Resource for the Transaction Manager & each Transaction </li></ul></ul><ul><ul><li>A new resource is created for each registered resource, enabling isolation </li></ul></ul><ul><ul><li>Transaction manager acts as an agent to register resources, prepare & commit </li></ul></ul>
  76. 77. Reliable Messaging <ul><li>Ordered messaging </li></ul><ul><ul><li>Assumes a protocol will order stateful, asynchronous application exchange patterns </li></ul></ul><ul><ul><li>Whereas, REST assumes stateless, synchronous application exchange patterns </li></ul></ul><ul><ul><ul><li>Each request requires a response </li></ul></ul></ul><ul><ul><ul><li>Requests may be pipelined, will be responded to in-order </li></ul></ul></ul><ul><li>Exactly-once processing </li></ul><ul><ul><li>Legitimate need for resource state changes, </li></ul></ul><ul><ul><li>e.g. In HTML forms, eliminating the “double form submit” button </li></ul></ul><ul><ul><li>Two possible solutions: </li></ul></ul><ul><ul><ul><li>Application-level check (e.g. unique ID in HTML hidden form field) </li></ul></ul></ul><ul><ul><ul><li>POST Exactly Once: http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt </li></ul></ul></ul>
  77. 78. Summary
  78. 79. Summary <ul><li>The “Global Object Web” is largely here: it’s the Web! </li></ul><ul><li>The Web is similar to a Distributed Object System </li></ul><ul><ul><li>Objects ~= Resources </li></ul></ul><ul><ul><li>Resources may be referenced, created, updated and/or deleted </li></ul></ul><ul><li>Global-scale interoperability requires constraints on communication </li></ul><ul><ul><li>Unpredictable evolution & configurations are the norm </li></ul></ul><ul><ul><li>Serendipitous reuse is more common than planned reuse </li></ul></ul><ul><ul><li>Must depend on a stable, but extensible, uniform interface to communicate </li></ul></ul><ul><li>Many traditional distributed systems challenges can be solved in a RESTful manner </li></ul><ul><ul><li>Reliability, optimistic locking, security, transactions </li></ul></ul><ul><li>More work remains to be done – “Learn to love the Web”! </li></ul>
  79. 80. Thank you!
  80. 81. Alternative Architectures When is REST not appropriate?
  81. 82. Alternative Architectures <ul><li>Transparent Remote Access </li></ul><ul><ul><li>Developer transparency is paramount </li></ul></ul><ul><ul><li>Information sharing is unimportant </li></ul></ul><ul><ul><li>Evolution is federally controlled (e.g. producers & consumers are under the same control ) </li></ul></ul><ul><ul><li>Distributed Objects or XML Web Services can be appropriate </li></ul></ul><ul><li>Globally Consistent Transaction System </li></ul><ul><ul><li>Tightly Coupled Single-System Image (e.g. a cluster) </li></ul></ul><ul><ul><li>Consistency trumps High Availability </li></ul></ul><ul><ul><li>Accomplished through language-level bindings (e.g. Java XA, MSDTC) or distributed object network protocols (e.g. TIP or IIOP) </li></ul></ul>
  82. 83. Alternative Architectures <ul><li>Stateful, In-Order, Reliable Messaging </li></ul><ul><ul><li>When you don’t have the time or inclination to share data </li></ul></ul><ul><ul><li>Most interactions are not safe or idempotent </li></ul></ul><ul><ul><li>The application does not lend itself well to statelessness </li></ul></ul><ul><ul><li>The physical scale (number of servers) is relatively small at each layer </li></ul></ul><ul><ul><li>Clients are trusted & controlled in the same federation as the servers </li></ul></ul><ul><ul><li>The network is controlled & predictable </li></ul></ul><ul><li>Structured Data Analysis, Manipulation and Reporting </li></ul><ul><ul><li>Remote Data Access (SQL, SPARQL) interfaces use general-purpose connectors </li></ul></ul><ul><ul><li>Requires extensive knowledge of the schema </li></ul></ul><ul><ul><li>Often requires per-client state maintenance </li></ul></ul>
  83. 84. Alternative Architectures <ul><li>Stateful, real-time two-way communication </li></ul><ul><ul><li>E.g. voice or video communication / conferencing, P2P file transfer </li></ul></ul><ul><ul><li>Requires a synchronous two-way streaming architecture </li></ul></ul><ul><ul><li>However, stream signaling and negotiation arguably can be RESTful </li></ul></ul><ul><ul><ul><li>E.g. BitTorrent registries & trackers require the Web to function </li></ul></ul></ul>
  84. 85. Alternative Architectures <ul><li>High-speed Publish/Subscribe Event Notification </li></ul><ul><ul><li>HTTP is limited to request/response semantics </li></ul></ul><ul><ul><li>May be significant protocol overhead </li></ul></ul><ul><ul><li>Arguably a limitation of HTTP 1.1, not REST </li></ul></ul><ul><li>Examples of fitting publish/subscribe into HTTP: </li></ul><ul><ul><li>Simulating an Event Stream as a long HTTP GET Request </li></ul></ul><ul><ul><li>Installing an HTTP Server on the Agent side </li></ul></ul><ul><ul><ul><li>No obvious message correlation, hindering visibility </li></ul></ul></ul>
  85. 86. Events on the Web: Comet-Style AJAX Applications <ul><li>Examples include: </li></ul><ul><ul><li>Google Mail’s GTalk integration </li></ul></ul><ul><ul><li>Meebo instant messaging </li></ul></ul><ul><ul><li>Renkoo </li></ul></ul><ul><ul><li>Jot Live </li></ul></ul><ul><li>Simulate events through long HTTP GET requests </li></ul>
  86. 87. References
  87. 88. Further Reading <ul><li>Andreessen, Mark. IIOP and the Distributed Objects Model </li></ul><ul><ul><li>http://web.archive.org/web/19961026035558/http://www3.netscape.com/comprod/columns/techvision/iiop.html </li></ul></ul><ul><li>Box, Don. Lessons from the Component Wars: An XML Manifesto </li></ul><ul><ul><li>http://msdn2.microsoft.com/en-us/library/aa468562.aspx </li></ul></ul><ul><li>Fielding, Roy. Architectural Styles and the Design of Network-Based Software Architectures </li></ul><ul><ul><li>http:// www.ics.uci.edu/~fielding/pubs/dissertation/top.htm </li></ul></ul><ul><li>Fielding, Roy. ApacheCon 2007 Presentation: The Rest of REST </li></ul><ul><ul><li>http://roy.gbiv.com/talks/200709_fielding_rest.pdf </li></ul></ul><ul><li>The Object Management Group, The Common Object Request Broker: Architecture and Specification </li></ul><ul><ul><li>http://www.omg.org/docs/formal/99-10-07.pdf </li></ul></ul><ul><li>The OpenID Foundation </li></ul><ul><ul><li>http:// openid.net </li></ul></ul><ul><li>Orfali, Harkey, and Edwards. BYTE Magazine (October 1997), CORBA, Java, and the Object Web </li></ul><ul><ul><li>http://www.byte.com/art/9710/sec6/art3.htm </li></ul></ul><ul><li>Maier & Rechtin. The Art of Systems Architecting. CRC Press, ISBN 0849304407 </li></ul><ul><li>Nieslen & LaLiberte. Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout </li></ul><ul><ul><li>http://www.w3.org/1999/04/Editing/ </li></ul></ul><ul><li>Nottingham, Mark. Post Once Exactly (POE) Internet Draft </li></ul><ul><ul><li>http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt </li></ul></ul><ul><li>Richardson & Ruby. RESTful Web Services. O’Reilly Media, ISBN 0596529260 </li></ul><ul><li>Russell, Alex. Comet: Low Latency Data for the Browser </li></ul><ul><ul><li>http:// alex.dojotoolkit.org/?p =545 </li></ul></ul><ul><li>World Wide Web Consortium, Architecture of the World Wide Web, Volume One </li></ul><ul><ul><li>http://www.w3.org/TR/webarch/ </li></ul></ul>