Oopsla 2007 - The Web: Distributed Objects Realized!
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Oopsla 2007 - The Web: Distributed Objects Realized!

on

  • 9,758 views

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

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

Statistics

Views

Total Views
9,758
Views on SlideShare
9,747
Embed Views
11

Actions

Likes
7
Downloads
240
Comments
0

6 Embeds 11

http://www.linkedin.com 6
http://livebackgammon.info 1
http://www.geoffblake.com 1
http://www.mvyx.com 1
http://www.o53.net 1
http://localhost 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Oopsla 2007 - The Web: Distributed Objects Realized! Presentation Transcript

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