• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
I'll See You On the Write Side of the Web
 

I'll See You On the Write Side of the Web

on

  • 1,348 views

WS-REST 2011 Workshop Keynote at WWW 2011 Hyderabad India

WS-REST 2011 Workshop Keynote at WWW 2011 Hyderabad India

Statistics

Views

Total Views
1,348
Views on SlideShare
1,344
Embed Views
4

Actions

Likes
0
Downloads
16
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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

    I'll See You On the Write Side of the Web I'll See You On the Write Side of the Web Presentation Transcript

    • Ill See You onthe Write Side of the Web WS-REST 2011 1
    • Introduction• Stuart Charlton (@svrc)• Director at Canadian Pacific Railway• Formerly CTO of Elastra, a cloud computing product based on semantic web technology• Weblog: Stu Says Stuff http://www.stucharlton.com/blog• Many thanks to commenters and twitterers on this topic 2
    • Theme• The Web Architecture has been an immense success... • ... and yet, we can do better.• There’s a need to design the software for the write side of the web to scale and become nearly as serendipitous as the read side • Is this even possible? Let’s find out. 3
    • The Read Side• GET • Atom & RSS feeds• RDFa/Microformats • Search• Browsing • Semantic Web 4
    • The Write Side• POST • Facebook Status• AtomPub • Media Sharing• Integration • e-Commerce 5
    • Why? 6
    • Why?• Growth in Centralized Services • e.g. Facebook 7
    • Why?• Systems Integration • Custom media types are the current approach... • ... but that can only be a transitory solution • Many “RESTful” design thrashing due to lack of prescriptive guidance • Would be reduced with more generic media types (e.g. as with HTML, AtomPub) 8
    • Why?• REST is not CRUD (create, read, update, delete) • Neither is HTTP • POST does not map directly to ‘create’ • CRUD leads to complexity at scale 9
    • Why?• Programming models matter • In particular, the clientʼs model of how it interacts with the server • Process-driven? Or something else? • Lots of innovation in this space... 10
    • Theses• The Web architecture’s core strength is in encouraging small pieces of independent agreement to be linked together and shared; we’re missing some agreements for writes• The Web architecture encourages clients to be designed as agents in a dynamic information space• There are practical approaches to programming agents in a dynamic environment• It should be possible to create a general purpose media type for systems to manipulate state on the web, in lieu of more specific media types. 11
    • Agreement 12
    • Collaborative Systems Architecture• “The greatest leverage in system architecting is at the interfaces. The greatest dangers are also at the interfaces.”• “When the components of a system are highly independent, operationally and managerially, the architecture of the system is the interfaces.” (Maier & Rechtin, The Art of Systems Architecting)• In Roy Speak....• “[REST’s goals are] achieved by placing constraints on connector semantics where other styles have focused on components semantics.” 13
    • Design for Serendipity• “Chance encounters”• Media types, link relations, RDFa/microformats, URI templates, well-known URIs, host meta, etc. 14
    • What agreements could be helpful? • Link relations for POST resources • The effects of a POST • cache invalidation • pre/post conditions • The contents of a POST • e.g. RDF Forms 15
    • Programming 16
    • Client/Server Programming Invoke Remote Procedure Create Application Request Logic & Message Exception Format Handling New Message Handler (optional) Handler New Message Response Message Format Client Server 17
    • REST Raises the Level of Abstraction• The message vs. the resource/representation• Traditional Client/Server: Client is a program sending/receiving messages• REST: Client is an agent acting in an information space 18
    • Hypermedia Programming Cached HTTP GET Representations Sensors Resource Goals & State of the Preferences application now Resource Resource Representation Logic Modify Choose Resource e.g. Link relations, Goals Desired State Media type specifications, pre/post conditions Exception Transfer Desired Handlers State Runtime Events Effectors Resource HTTP POST Environment Hypermedia Agent (The Web) 19
    • Qualities of the Client• Goal-Directed• Reactive• Hypermedia workspace (cached representations)• Sensing can be done to pick up on effects 20
    • Agents 21
    • Agent• Traditional agents are distinguished from mere programs via... • The existence of an environment it needs to react to • The autonomy for the agent to make detailed decisions for the user so long as it is seeking to achieve a goal 22
    • The AI approach to Agents• Automated Planning • A process to determine an order of actions to be taken in pursuit of a goalCurrent state of the worldDescription of actions Planner Required actions (plan)Goals and constraints 23
    • Example of Planning Download package list Install Z Download X Upgrade Z Install X Download Y Download X Download Z Upgrade X Download package list Install YDownload Y Install X Install Y Upgrade Y Install X Plan Set of all available actions (selected and ordered actions) 24
    • Step 1 Step 2 Step n Result 15 /32 An Alternative Approach• Subsumption Architecture; aka. Hierarchical State Machines Development by subsumption Situation n STAGE n !" ……… … SYSTEM Situation 2 STAGE 2 !" STAGE 2 !" Situation 1 STAGE 1 !" STAGE 1 !" STAGE 1 !" 0 time Step 1 Step 2 … Step n Result 15 /32 25
    • Programming by Difference• Coined by Miro Samek• State nesting lets you define a new state rapidly in terms of an old one, by reusing semantics from the parent• Reuse what is common, override what is not 26
    • States in the Halo 2 Game Engine 27
    • Agreements as a State Sandwich Application State Machine! Hypermedia Application State Machine! HTTP State Machine! Media State Machine! ...! 28
    • Media Type 29
    • Mapping Nested State Transitions to Restbucks 30
    • State Chart XML• Promising W3C Draft; Hierarchical FSMs; JavaScript Code-on-Demand, Expressions (Pre/Post Conditions), Event Model• Weaknesses: Lacks Hyperlinks, Mandates Heavyweight Message Format <state id="S" initial="s1"> <state id="s1" initial="s11"> <onexit> <log expr="leaving s1"/> </onexit> <state id="s11"> <onexit> <log expr="leaving s11"/> </onexit> </state> <transition event="e" target="s21"> <log expr="executing transition"/> </transition> </state> </state> 31
    • Possible Characteristics• JSON-based (and/or JS code on demand)• Link relations for states, events, and transitions• Events become identifiable elements of some representations 32
    • Behave: A JavaScriptState-Aware User Agent• Implemented in node.js• JSON-based linked state machines• First release in May 2011 33
    • Revisiting the Theses• Agreements: The effects of a POST in context to other representations• Programming: Instead of a RESTful client library, aim for an agent runtime• Agents: Hierarchical state machines are promising today; hierarchical planning with sensing is a promising thread for research• Media Type: Link relations for states and their transitions; the ability to nest states & transitions via hyperlinks 34