Upload
joan-gross
View
20
Download
0
Embed Size (px)
DESCRIPTION
Distributed Pervasive Applications: easing the pain. A framework for dynamic assembly of Oxygen applications. 27 January, 2003. Steve Ward LCS, MIT. L C S. “Connect me To Steve”. Some local history. Goal-oriented Software Architecture:. Standardized GOALS as commodities. - PowerPoint PPT Presentation
Citation preview
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
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?