3/18/2001, Pervasive Service Infrastructure 1 Pervasive Services Infrastructure (Ψ) Dejan S....

3/18/2001 , Pervasive Service Infrastructure 1

Pervasive Services Infrastructure Pervasive Services Infrastructure (Ψ)(Ψ)Dejan S. MilojicicDejan S. Milojicic

HP Labs, Palo AltoHP Labs, Palo Alto3/15 20013/15 2001

http://www.hpl.hp.com/research/itc/csl/pss/psihttp://www.hpl.hp.com/research/itc/csl/pss/psi


ΨΨ’s Strategic Direction’s Strategic Direction

Internet Wireless

ServiceProviders

Global eCommerce to reach $6.8 trillion by 2004 (Forrester Research)

Internet Service Gateway market to reach 25M US homes by 2005, worth $5B (Parks Assoc.)

Commerce over mobile phones in W. Europe rise to $37.7B in 2004 ($51.2M in 1999, IDC)

Worldwide shipments of handheld computers will surpass 5.7M, 47% increase (Dataquest)


What is Disruptive in this SpaceWhat is Disruptive in this Space

General pervasive (ubiquitous, invisible) deployment of computers, smart spaces scale: large number of devices (localized) & services

User perspective user interfaces, user intent context awareness diversity of services and clients connectivity

Developer perspective versioning and maintaining products (scale thereof) variation in network speed (wireless → wired; wired → memory) the price of each component (reduced cost) service interoperability (everything available on the Internet)


Tough Problems TodayTough Problems Today

Wireless speed (need higher bandwidth, lower latency) Unreliable connections (missing disconnected support) Lack of apps and app development tools Lack of solid infrastructure (database, synchronization) Non-scalable solutions Non-trusted solutions (lack of end-to-end security) Lack of quality displays & U/I Few users (innovators and early adopters) Protocols evolving (WAP, XML implementations, APIs) User experience (clumsy handheld, poor I/F) Viability (fractured embedded OS space)


Relaxing Assumptions for 2004Relaxing Assumptions for 2004(not all problems are (not all problems are ’s) ’s)

Ubiquitous connectivity (3G+) End-to-end security (Wireless VPN) Device interoperability (Lucent & Novell, Motorola & Lucent, etc) Better battery lifetimes (piezoelectric, solar, bioelectric, etc.) Handheld, phones, others,… converged Billing, customer care → commodity services Voice U/I (many already work on) Higher quality color displays New Web apps built from ground up Middleware solutions adapt access to existing apps Wireless Web crosses the chasm Consolidation of embedded OS space


What are Remaining ProblemsWhat are Remaining Problems

Scalability (localized) Service access and adaptivity in dynamic environments Administration (automatic, transparent, dependency aware) One-size fits all (embedded system software solutions) Interoperability (APIs, service brokers, etc.) Performance e.g. load, latency, caching Maintaining true end-to-end security guarantees


ScenarioScenario

Scene: Helsinki airport, year 2004. Jane and Dave are on a business trip to present a new product to overseas customers. Dave worked the whole weekend at home on an updated presentation. They are stepping off of the plane.

Jane: Relax Dave, everything is going to be fine. Your presentation is in good shape. Just fix the typo in the CTO’s name and tune the figures,

Dave: Fix the title! Tune the figures! Are you out of your mind?! I only have the presentation on my phone. I’d need to download and fix it on my laptop. We don’t have time for that before the meeting.

Jane: Yes, you can. I can do it on my new phonDA.Dave: You never told me you got a new, more powerful phonDAJane: No, it’s the same as yours, NK234yP, but I’ve updated the software.Dave: No way, my presentation is 4G. It can’t fit on any phonDAJane: Look, I download your presentation ... Here’s the slide you want, … ok…

the CTO’s title is fixed, … now let’s see the figures… it’ll take longer… ok, here are figures, move the 2003 forecast up a little, .. perfect.


Scenario, cont.Scenario, cont.

Dave: How did you do it?!! Look, I’m downloading it on my phonDA and it takes forever… even worse, now it won’t start.

Jane: You see those small bumps on the walls, ceiling, and floor. These are embedded servers. Software on my phonDA offloads networking, memory, processing, storage - you name it - to these servers.

Dave: Sigh…Jane: It is called Psi; it’s very simple. Now with respect to these bumps

on walls, … hold on a second… my daughter is paging me, first things first…. Yes honey, … I forgot to sign your homework … ooops …

Dave: Can your magic Psi help with this too?Jane: Sure it can, see, here it will download her application from her

school – it adapts to my phonDA since the app is designed for desktops– it’s really downloaded on a server there. Looks correct, ok signed!


Scenario, cont.Scenario, cont.

Dave: Wow, you are a wizard, installing all these applications, adapting them to your small phonDA. How long did it take you?

Jane: Not a second, Psi does it all, it adapts, it downloads services on demand.

ΨΨSigh Sigh


Pervasive Servers & ClientsPervasive Servers & Clients

..servers…

..clients…..i

nter

med

iate

serv

ers…

ΨΨ

IDCsIDCs

..embedded devices and sensors…

infrastructureinfrastructure

embeddedembedded


Conceptual LayersConceptual Layers

Local OSes & JVMsLocal OSes & JVMs

Ψ platform:Ψ platform:match service requirements to client resourcesmatch service requirements to client resources

Middleware LayersMiddleware LayersE-Speak, Jini, CORBA, ACLE-Speak, Jini, CORBA, ACL

Services and ApplicationsServices and Applications

Client Handheld Device (and Infrastructure Servers)


Ψ Ψ VisionVision

Adapt any service to any client (anywhere, anytime)

General assumptions clients will always be diverse clients will always be less powerful than desktops there will be a large scale of devices in the future services will be accessible on demand from anywhere

Underlying assumptions: service adaptivity required three-tier model service splitting


Ψ, Ψ, Important Research QuestionsImportant Research Questions

How to enable users to exploit the new pervasive computer infrastructure How to seamlessly offer more services to more clients anytime anywhere? How to avoid installing and administering increasing number of computers in a

pervasive infrastructure? What are new abstractions and algorithms for computation, communication,

storage, user interface → how to write and run new apps?

It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change - Charles Darwin


Adaptive Offloaded ServicesAdaptive Offloaded Services

Goal: increase scalability & performance of (mobile) service deliveryto resource-poor devices and enable where not currently possible

Key research questions Splitting service between client and mid-point (intermediate) servers Dynamic adjustment of services: device size, load, roaming Masking performance implications of splitting

Required infrastructure topics Distributed run-time support - mid-point(s) and client Sharing, administration, and security at mid-points


Adaptive Offloaded Services Adaptive Offloaded Services IllustrationIllustration

IDC

010101

010101

111010

0

111010

Back-end service execution

Embedded server dependent execution

0101

01011110

1110

0101

01011110

1110

Which?

0101

01011110

1110

Internet

DSLPhone

Home, office, shop, etc.


Adaptive Offloaded Services, Cont.Adaptive Offloaded Services, Cont.

Splitting services Monitoring (resources, execution, objects) Offloading (migration mechanisms, trigger & placement policies) Service splitting (interaction metrics, graph partitioning, 3-v. 2-tier)

Adaptive Offloading Adapting to devices (very constrained, different resources) Adapting to load (multiple services, scalability) Adapting to mobility (roaming, migration of offloaded state)

Performance Policies (account for overhead, interaction metric, stability) Mechanisms (offloading overhead, disruption of offloading - lazy)


The Java Heap Page Working Set The Java Heap Page Working Set of Embedded Caffeine Markof Embedded Caffeine Mark

0

50

100

150

200

250

0k 50k 100k 150k 200k 250k 300k 350k

Time (Instructions Executed)

Acc

um. M

emor

y U

sage

(4k

Pag

es)

Untouched LiveObjects

Thread StackTouched

Heap ObjectsTouched


Services on DemandServices on Demand

Goal: zero-administration and -installation of mobile clients Key research questions

dynamic service composition and deployment on zero-installed devices

de/re-coupling of user’s service context between devices tolerance to disconnection of services

Required infrastructure topics service brokers and infrastructure device encapsulation APIs


Services on Demand IllustrationServices on Demand Illustration

Back-end service execution

Internet

Home, office, shop, etc.

Secured Storage Provider

Service broker

ASP

ASP

Day 1, John in Sydney

Day 2, John in Montreal


Loading OverheadsLoading Overheads

ServiceLocal

Load (s)

SoD Loading (s) Loaded URLs Java Class

Intranet Wave Dialup Cnt Size (B) Cnt Size (B)

calculator 0.1 ~0 +0.1 +4.7 2 9520 2 9520

calendar 0.2 ~0 +0.4 +4.7 4 12952 4 12952

editor 0.2 ~0 +0.3 +5.2 7 15885 7 15885

game 0.2 ~0 +0.3 +6.1 9 18739 9 18739

agenda 0.2 +0.1 +0.7 +8.4 1 35360 12 59846

ftp 0.6 +2.1 +3.2 +20.9 3 107725 22 142155

mail 2.5 +2.7 +15.1 +129.4 1 675046 138 365574


Services on Demand, Cont.Services on Demand, Cont.

Service Composition/Deployment on Zero-Installed Devices service characterization (naming, keyword, extension, requirements) service discovery (brokers, resource matching, scalability) deployment (transparent downloading & caching, sandboxing for service inter-

communication De/re-Coupling of Service Context Between Devices

remote storage (clients are volatile, access any time anywhere, user/service transparency, stackable client RFS, synchronization/encryption)

context information (per service state, preferences, expressed as files) Adaptation to different client (resource re-evaluation, select service)

Tolerance to Disconnection of Services client side cache (static content: URLs, classes; user files/data; user/service network

interactions reconnection (pluggable reconciliation per service/file, client-initiated


Architectural PrinciplesArchitectural Principles

Minimal changes (extensions) to the underlying client sys SW Minimal changes to services (mainly splitting) Use existing mid-point servers in the infrastructure Psi will rely on standard communication protocols (IP, WAP, etc)

however, it will have the ability to support extension to new ones Heterogeneity of underlying OSes and implementation of JVMs

The primary metric will be enabling new services and better use of resource-constrained devices


Implementation DetailsImplementation Details

Prototype environment Jornada Pocket PC Java VM, Chai VM wireless 802.11 Linux PCs for infrastructure servers

Services tools: editors (text/image) visualization PIM: calendars, mail, calculators, stock analysis interactive games etc.


Technical ApproachTechnical Approach

Develop a architecture & prototype implementation Experimental, quick prototyping, 3-month increments Spiral approach

Incrementally demonstrate new functionality Uncover new key questions

Engage partners at incremental 3-month phases HPL, HP, university, industry (external)

Patent/publish as we progress


Showcases Showcases

Adaptive offloaded servicesinitial mobile app splitting, evaluate split advantage (scale/perf/power)

app which is too resource intensive for existing devices app which is interactive → mobile editing and interactive gaming app which is data intensive → mobile multimedia and visualization

Service-on-Demand service broker lookup, automatic download, disconnected mode (cache/remote)

app that can work disconnected (runs part of the service locally) app that accesses user data from a server app in two different flavors, to adapt to Palm constrained resources


Current InsightsCurrent Insights

Opportunity for memory offloading Complex interactions in Java objects Transparent remote storage: class interposition, bytecode editing Disconnection: caching of some class client/service interactions Reconciliation through plugins


Team MembersTeam Members

Resource-Constrained Devices, team leadOS, JVM, consumer products (Sony)

Team memberHA, distributed systems (SRI, Informix, Oracle)

Services-on-Demand, team leadOS, JVM (Bull, OSF RI)

Dejan Milojicic, (myself) Psi PMOS, distributed systems & agents (Belgrade RI, OSF RI)


CompetitionCompetition Telcos

AT&T, Motorola, Ericsson Consumer electronics companies

Sony, Philips, etc. (HAVI) Traditional computer systems companies

Sun (Jini, embedded/real-time Java); Microsoft (.NET, Windows CE)IBM (pervasive computing, embedded tools)

Data base companies Oracle, Sybase

Many startups StreamTheory, OmniShift, Transvirtual, M2Verticom, WirelessKnowledge

Many universities, government Numerous competition, but huge business & innovation opportunity


Related WorkRelated Work Adaptability & Offloading

UW (Portolano) Active Fabrics + service infrastructure Berkeley’s (Endeavor) Ninja + general service offloading Palm, WinCE + offloading to shared mid-points OSGi + general purpose + distributed; UW Kimera + dynamic service split CMU Odyssey, UIUC Active Spaces + service splitting MIT Oxygen SW environment + resource awareness

Data storage & resource management CMU Coda & Odyssey + reconciliation framework UCLA File mobility + trust for services; WebFS + more than web browsing OSGI + mobility; Java OS JDI & JPI + API signatures

Java platform JavaOS + service infrastructure; PocketLinux + disconnected + other OSes JNT, but not just a terminal; WebOS + service brokers & trust


What What ΨΨ is is NotNot About About

Client HW HW (re)configuration Service design & implementation New protocols New programming languages General purpose wireless Device location technologies General purpose OS development Fault-tolerance Hard real-time


SummarySummary

Intersection of services, the Internet, and wireless: adapt services to existing client resources automate service deployment reason about new, disruptive technologies in pervasive computing

Potential long-term area of research, ties in servers (IDCs) & client pervasive infrastructures academia, government, big & small companies different markets

A lot of opportunities for contribution; risk-aware, leverage potential It is fun to do these things! Immediate benefit obvious


Pervasive Computing LandscapePervasive Computing Landscape

deviceconnectivity

serviceconnectivity

internet com(IP)

mobile com.(non IP)

nomadic locationtransparency

contextmanagement

user/agent model(intelligence)

application model(information access

& presentation)

information architecture

XMLUDDIVML

…

securitymgmt

pricing/charging

developmentadaptivity

taskmobility

globaldata

placement

userstudies

3/18/2001, Pervasive Service Infrastructure 1 Pervasive Services Infrastructure (Ψ) Dejan S....

Documents

Transcript of 3/18/2001, Pervasive Service Infrastructure 1 Pervasive Services Infrastructure (Ψ) Dejan S....