Distributed Pervasive Applications: easing the pain A framework for dynamic assembly of Oxygen applications Dick Lampman, HP 27 January, 2003 Steve Ward O 2 S 1
Some local history. “Connect me To Steve” Goal-oriented Software Architecture: Standardized GOALS as commodities Distributed database of TECHNIQUES Anant Tele. Conference(Anant, Steve) Achieving goals by pursuit of sub -goals Room? Video Audio H 21? Phone? Steve O 2 S 2
O 2 S 3
Steps toward Goals… We’ve built a (more) real version… … but that’s not today’s topic. 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 languageindependent implementations O 2 S 4
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 i. PAQ… 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 applicationrelated events. O 2 S 5
Architectural Planning level: GOALS POLICY: Strong Abstraction • Location/platform/language independence • Sequential SLS Server • “cerebral” Shell V. R. APP H 21 MIKE GUI Spkr MECHANISM: • Distributed Intermediate “machine language” model: • Coherent, easily monitored application (goal) state • Guaranteed failure notification • Highly parallel GUI Spkr • “reflexive” MIKE Component level: Pebbles O 2 S 6
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 O 2 projects – e. g. , INS – represent opposite extreme Issues: • Planning depends on low-level resources, capabilities • Efficiency: constrains optimizaton Pros: Research Questions: • What is the range of applications that fit well into this paradigm? • What are the costs of this abstraction, in real applications? • POLICY centralized, scriptable • Ideal target for Goals layer • Don’t buy Goals? Can do planning in C/Java/… code O 2 S 7
The O 2 S Application Model Server Application code: • Assembles a “circuit diagram” of pebbles, connections; then • Monitors serialized stream of related events • Interacts with centralized, coherent, synthesized “application state” H 21 O 2 S System: presents coherent illusion… What happens if… • Some component crashes? • Someone reboots their i. PAQ? • Loses network connectivity? • Hits QUIT? • 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 O 2 S 8
Liveness monitoring Requirements: • App notified on every pebble failure (recovery, cleanup) • Pebble hosts notified of failed apps (cleanup) • Approach: Keep. Alive connections App 1 R App 1 App 2 Improvements: • Trusted Pebble. Host infrastructure: only Host failures need Keep. Alives • Registry as hub: A+H, not A*H App 2 Registry: • Monitors liveness of registrants • Provides notification service • Registrants include: Hosts, Apps, Host Proxies, User Proxies TRUSTED: Registry, O 2 S Host system UNTRUSTED: Pebbles, Apps O 2 S 9
Services vs. Pebbles Extensible Universe of Services: Services Voice recog • Abstract: platform independent, immutable (specifications) • Unique URI: points to spec Voice recog 2 • Pebbles identify specs they satisfy audio sink • Service: find pebble from service, parameters (eg host). A pebble! Pebbles SLS (implementations) Tool: Feature Sets WAV-MP 3 converter: {inputs={name=‘input’, connection= {mode=push, type=WAV}} outputs={name=‘output’, connection= {mode=push, type=WAV}}} IBM i. PAQ Win 32 O 2 S 10
O 2 S Proxy Structure Registry • Creates Host Proxy App 1 Request(Audio. Sink) Host Proxy Audio. Sink Request(Audio. Sink) Install Audio. Sink Allocate Connector • Starts Pebble. Host • Contacts Registry • Requests Host Proxy API: Pebbles/Connectors • Manages host resources • Installs & monitors pebbles • Fields app-level requests App 2 Audio. Sink O 2 S 11
Proxies Galore… Room Proxy App Proxies for Room resources… User Proxy Host Proxy Registry • Host Proxy (mediates host resources) • User Proxy (mediates user resources) – same request API? Host Proxy • Room Proxy, Lab Proxy, … • Registry – host connections O 2 S 12
Our (Fetal) Code Base Python-based prototype: • XMLRPC interfaces; apps, planning in JAVA • Portable host code: • O 2 S Listener (server) • Registration/keep-alive • Hosting of sandboxed pebbles, specified via URIs • Runs on i. PAQ, LINUX Servers, Windows(**), … • Several trivial apps O 2 S Registry Start at Pebble library: Spkr GUI Mike • Several primitive pebbles for i. PAQ (audio in/out, tiny GUIs) • Placeholder server pebbles (voice recognition, email) O 2 S 13
Server-side pebbles O 2 S System runs on handhelds, desktops, servers, … • Common framework: Registrant, O 2 S Server, Pebble. Host • Shared by devices, apps, host/user proxies, services Example: Voice Recognition Easy, modular, programmatic access to functions of SLS Galaxy System O 2 S SLS Galaxy V. R. MIKE Shell • SLS Galaxy System • Add O 2 S code, wrap it in a pebble interface: then • App request (incl. grammar) instantiates voice_recognizer pebble • Waveform input, text output connected to pebbles elsewhere O 2 S 14
Primitive “Voice Shell” af = App. Framework() # 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(O 2 S_CLIENT_NET_ADDRESS, 'audio_source‘) <command> = {vsh} {quotes} show me my stocks # Make the apropriate | connections: how is my portfolio doing {vsh} {quotes} ; af. connect(recognizer. output, shell. input) <command> af. connect(voice_in. output, recognizer. input) = {vsh} {connect-me-to} connect me to <person> ; # Instantiate a simple GUI gui = af. request(O 2 S_CLIENT_NET_ADDRESS, 'vsh_gui') <person> = Cornelia {colyer} = Chris Terman {cjt} # Then, simply monitor events: = Umar Saif {umar} while af. status == 'running': = Steve Ward {steve} = David Saff {saff} event = af. next_event() = Eric Brittain {ericb} if event. name == 'button_clicked': break ; O 2 S 15
Tinkertoy-set modularity O 2 S SLS Galaxy O 2 S V. R. Shell Application O 2 S MIKE Registry Synth Spkr O 2 S COM (PPT) • i. PAQ (Audio I/O, Synth) here • SLS Galaxy at LCS • Apps on O 2 S Server at LCS • Windows laptop: COM/PPT pebble here • O 2 S Registry at LCS O 2 S 16
Should HP be interested? The dawning age of pervasive computing… … invading corporations, hospitals, universities, homes, … POTENTIAL: Revolution, ala digital HW during 60 s-80 s 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? O 2 S 17
Скачать презентацию Distributed Pervasive Applications easing the pain A framework
0012e6bc3cba3a84c353b5c5494aa906.ppt