1O2S

Distributed Pervasive Applications:easing the pain

A framework for dynamic assembly of Oxygen applications

Steve Ward

LCS, MIT

27 January, 2003

L C S

2O2S

Some local history.

“Connect meTo Steve”

Goal-oriented Software Architecture:

Achieving goals by pursuit of sub-goals

Standardized GOALS as commodities

Audio

VideoRoom?

H21?

Phone?

TeleConference(Anant, Steve)

Anant Distributed database of TECHNIQUES

Steve

3O2S

4O2S

Steps toward Goals…

We’ve built a (more) real version…… but that’s not today’s topic.

4O2S

Challenge:

Connecting our GOALS system to reality!

• Diversity of devices, hosts, failure modes

• Lack of notification guarantees to drive planning process

• Unbearable debugging environment

• Maze of platform, OS, language dependencies

• NEEDED:

• Coherent target model for planning

• Robust, platform- and language-independent implementations

5O2S

Building distributed applications…

… a notoriously hard problem!

A few of the reasons:• Distributed state.

• System “state” may not be a well-founded notion!

• Failures of remote resources, communications…• User turns off his iPAQ… or

• Gets into steel-shielded elevator

• Symptom: silence.

• Lack of process hierarchy

Goal: provide a model that addresses these issues• Illusion: “circuit” of interconnected modules, assembled by

application.

• Simulate localized state, serialized stream of application-related events.

6O2S

StrongAbstraction

Architectural PlanPlanning level: GOALS

Component level: Pebbles

H21

Server

H21V.R.

Spkr

GUI

MIKE

Shell

APP

SLSServer

Intermediate “machine language” model:

• Coherent, easily monitored application (goal) state

• Guaranteed failure notification

Spkr

GUI

MIKE

POLICY:

• Location/platform/language independence

• Sequential

• “cerebral”

MECHANISM:

• Distributed

• Highly parallel

• “reflexive”

7O2S

Levels? Who wants Levels?

Research issue: do we want a strong abstraction between planning & component levels?• Alternative component models intermingle these functions, to good

effect…

• Some O2 projects – e.g., INS – represent opposite extreme

Pros:

• POLICY centralized, scriptable

• Ideal target for Goals layer

• Don’t buy Goals? Can do planning in C/Java/… code

Issues:

• Planning depends on low-level resources, capabilities

• Efficiency: constrains optimizaton

Research Questions:• What is the range of applications that

fit well into this paradigm?• What are the costs of this abstraction,

in real applications?

8O2S

The O2S Application Model

Application code:• Assembles a “circuit diagram” of

pebbles, connections; then

• Monitors serialized stream of related events

• Interacts with centralized, coherent, synthesized “application state”

O2S System: presents coherent illusion…• Common system code in each host (device,

server, …):

• Hosts sandboxed ‘pebbles’

• Reflects pebble state, errors, debugging spew to central app

• Minimalist mechanism, not Policy

• Application Framework:

• manages “circuit” model;

• Hides administrative interactions

H21

Server

What happens if…

•Some component crashes?

•Someone reboots their iPAQ?

•Loses network connectivity?

•Hits QUIT?

9O2S

Liveness monitoringRequirements:

• App notified on every pebble failure (recovery, cleanup)

• Pebble hosts notified of failed apps (cleanup)

• Approach: KeepAlive connections

App1

App2

TRUSTED: Registry, O2S Host system

UNTRUSTED: Pebbles, Apps

Registry:• Monitors liveness of registrants

• Provides notification service

• Registrants include: Hosts, Apps, Host Proxies, User Proxies

Improvements:•Trusted PebbleHost infrastructure:

only Host failures need KeepAlives

•Registry as hub: A+H, not A*HApp1

App2

R

10O2S

Services vs. PebblesExtensible Universe of Services:

• Abstract: platform independent, immutable

• Unique URI: points to spec

• Pebbles identify specs they satisfy

• Service: find pebble from service, parameters (eg host). A pebble!

Services(specifications)

Pebbles(implementations)

audiosink

Voicerecog

SLS

IBM

Voicerecog2

iPAQ

Win32

Tool: Feature Sets

WAV-MP3 converter: {inputs={name=‘input’,

connection= {mode=push, type=WAV}}

outputs={name=‘output’, connection= {mode=push, type=WAV}}}

11O2S

O2S Proxy Structure

Registry

HostProxy

• Starts PebbleHost• Contacts Registry• Requests Host Proxy

• Creates Host Proxy

• Manages host resources• Installs & monitors

pebbles• Fields app-level requests

App 1Request(AudioSink)

AudioSink

App 2

Request(AudioSink)

AudioSink

Install AudioSink

Allocate Connector

API:Pebbles/Connectors

12O2S

Proxies Galore…

HostProxy

HostProxy

UserProxy

App

Registry

RoomProxy

Proxies forRoom resources…

• Host Proxy (mediates host resources)

• User Proxy (mediates user resources) – same request API?

• Room Proxy, Lab Proxy, …

• Registry – host connections

13O2S

Our (Fetal) Code BasePython-based prototype:

• XMLRPC interfaces; apps, planning in JAVA

• Portable host code:• O2S Listener (server)

• Registration/keep-alive

• Hosting of sandboxed pebbles, specified via URIs

• Runs on iPAQ, LINUX Servers, Windows(**), …

• Several trivial apps

Start at Pebble library:• Several primitive pebbles for iPAQ

(audio in/out, tiny GUIs)

• Placeholder server pebbles (voice recognition, email)

Registry

O2S

O2SO2S

Registry

O2S

SpkrGUI

Mike

14O2S

O2S

• Add O2S code, wrap it in a pebble interface: then

Server-side pebbles

O2S System runs on handhelds, desktops, servers, …• Common framework: Registrant, O2S Server, PebbleHost

• Shared by devices, apps, host/user proxies, services

Example: Voice RecognitionEasy, modular, programmatic access

to functions of SLS Galaxy System

• SLS Galaxy SystemSLSGalaxy

V.R.

• App request (incl. grammar) instantiates voice_recognizer pebbleMIKE

Shell

• Waveform input, text output connected to pebbles elsewhere

15O2S

Primitive “Voice Shell” af = AppFramework()

# Instantiate our required pebbles. By default, any failure

# shuts down (cleanly) the application:

shell = af.request(af.localhost, 'shell‘)

grammar = shell.request(‘grammar’)

recognizer = af.request(SPEECH_SERVER, 'voice_recognizer', grammar)

voice_in = af.request(O2S_CLIENT_NET_ADDRESS, 'audio_source‘)

# Make the apropriate connections:

af.connect(recognizer.output, shell.input)

af.connect(voice_in.output, recognizer.input)

# Instantiate a simple GUI

gui = af.request(O2S_CLIENT_NET_ADDRESS, 'vsh_gui')

# Then, simply monitor events:

while af.status == 'running':

event = af.next_event()

if event.name == 'button_clicked': break

<command> = {vsh} {quotes} show me my stocks | {vsh} {quotes} how is my portfolio doing ;

<command> = {vsh} {connect-me-to} connect me to <person> ; <person> = Cornelia {colyer} = Chris Terman {cjt} = Umar Saif {umar} = Steve Ward {steve} = David Saff {saff} = Eric Brittain {ericb} ;

16O2S

Application

O2S

Application

Shell

Tinkertoy-set modularity

Registry

O2SMIKE

O2S

Spkr

Synth

O2S COM(PPT)

SLSGalaxy

V.R.

O2S

• iPAQ (Audio I/O, Synth) here• SLS Galaxy at LCS• Apps on O2S Server at LCS• Windows laptop: COM/PPT pebble here• O2S Registry at LCS

17O2S

Should HP be interested?

The dawning age of pervasive computing…… invading corporations, hospitals, universities, homes, …POTENTIAL: Revolution, ala digital HW during 60s-80s

Hardware building blocks:•Handhelds•Desktop machines•Printers & Peripherals•Instruments… things HP makes!

Software building blocks:????

COMING: a “glue” technology…The TTL Data Book for pervasive computing!

What will HP’s role be?