the Write Side of the Web WS-REST 2011 1 Introduction Stuart - - PowerPoint PPT Presentation

▶
the write side of the web
SMART_READER_LITE
LIVE PREVIEW

the Write Side of the Web WS-REST 2011 1 Introduction Stuart - - PowerPoint PPT Presentation

May 12, 2023 309 likes •666 views

I'll See You on the 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

slide-1
SLIDE 1

the Write Side of the Web

WS-REST 2011 I'll See You on

1

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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

slide-4
SLIDE 4

The Read Side

  • GET
  • RDFa/Microformats
  • Browsing
  • Atom & RSS feeds
  • Search
  • Semantic Web

4

slide-5
SLIDE 5

The Write Side

  • POST
  • AtomPub
  • Integration
  • Facebook Status
  • Media Sharing
  • e-Commerce

5

slide-6
SLIDE 6

Why?

6

slide-7
SLIDE 7

Why?

  • Growth in Centralized Services
  • e.g. Facebook

7

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

Agreement

12

slide-13
SLIDE 13

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,
  • perationally 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

slide-14
SLIDE 14

Design for Serendipity

  • “Chance encounters”
  • Media types, link relations,

RDFa/microformats, URI templates, well-known URIs, host meta, etc.

14

slide-15
SLIDE 15

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

slide-16
SLIDE 16

Programming

16

slide-17
SLIDE 17

Client/Server Programming

Client Server Remote Procedure Handler New Message (optional) New Message Request Message Format Handler Response Message Format Create Application Logic & Exception Handling Invoke 17

slide-18
SLIDE 18

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

slide-19
SLIDE 19

Hypermedia Programming

Hypermedia Agent Environment (The Web) State of the application now Transfer Desired State Resource Resource Cached Representations Sensors HTTP GET Effectors Resource Representation Logic e.g. Link relations, Media type specifications, pre/post conditions Choose Desired State Resource Resource Goals & Preferences Exception Handlers Modify Goals Runtime Events HTTP POST

19

slide-20
SLIDE 20

Qualities of the Client

  • Goal-Directed
  • Reactive
  • Hypermedia workspace

(cached representations)

  • Sensing can be done to pick up on effects

20

slide-21
SLIDE 21

Agents

21

slide-22
SLIDE 22

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

slide-23
SLIDE 23

The AI approach to Agents

  • Automated Planning
  • A process to determine an order of actions to be

taken in pursuit of a goal

Current state of the world Description of actions Goals and constraints

Planner

Required actions (plan)

23

slide-24
SLIDE 24

Example of Planning

Download X Install X

Download package list

Install X Download Y Install Y Upgrade X Upgrade Y Download Z Install Z Upgrade Z

Download package list

Download X Download Y Install Y Install X

Set of all available actions Plan (selected and

  • rdered actions)

24

slide-25
SLIDE 25

An Alternative Approach

  • Subsumption Architecture;
  • aka. Hierarchical State Machines

15

Step 1 Step 2 Step n Result

…

/32

15

STAGE n STAGE 2 SYSTEM

time

Situation 1 Situation 2 Situation n STAGE 1 STAGE 1

STAGE 2

!" !" !" !" !" !"

Step 1 Step 2 Step n

………

Result

…

STAGE 1

…

/32

25

slide-26
SLIDE 26

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

slide-27
SLIDE 27

States in the Halo 2 Game Engine

27

slide-28
SLIDE 28

Agreements as a State Sandwich

Application State Machine Hypermedia Application State Machine HTTP State Machine Media State Machine

...

28

slide-29
SLIDE 29

Media Type

29

slide-30
SLIDE 30

Mapping Nested State Transitions to Restbucks

30

slide-31
SLIDE 31

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

slide-32
SLIDE 32

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

slide-33
SLIDE 33

Behave: A JavaScript State-Aware User Agent

  • Implemented in node.js
  • JSON-based linked state machines
  • First release in May 2011

33

slide-34
SLIDE 34

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