Pervasive Services Infrastructure (Ψ) Dejan S. Milojicic HP Labs, Palo Alto 3/15 2001 http://www.hpl.hp.com/research/it

1. Pervasive Services Infrastructure (Ψ)Dejan S. MilojicicHP Labs, Palo Alto3/15 2001http://www.hpl.hp.com/research/itc/csl/pss/psi

2. Internet Wireless Service Providers Ψ’s Strategic Direction • 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)

3. What 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)

4. Tough 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)

5. Relaxing Assumptions for 2004(not all problems are Y ’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

6. What 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

7. Scenario 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 phonDA Jane: 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 phonDA Jane: 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.

8. 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!

9. Sigh Ψ 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.

10. Pervasive Servers & Clients ..servers… IDCs ..intermediate servers… infrastructure Ψ ..clients… embedded ..embedded devices and sensors…

11. Middleware Layers E-Speak, Jini, CORBA, ACL Conceptual Layers Services and Applications Ψ platform: match service requirements to client resources Local OSes & JVMs Client Handheld Device (and Infrastructure Servers)

12. Ψ Vision 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 Y assumptions: • service adaptivity required • three-tier model • service splitting

13. Ψ, Important 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

14. Adaptive 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

15. 010101 111010 IDC 010101 111010 0 Internet 1110 0101 1110 0101 Adaptive Offloaded Services Illustration 1110 0101 DSL 1110 0101 Phone 1110 0101 Embedded server dependent execution 1110 0101 Which? Back-end service execution Home, office, shop, etc.

16. 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)

17. The Java Heap Page Working Set of Embedded Caffeine Mark

18. Services 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

19. Internet Secured Storage Provider ASP ASP Service broker Services on Demand Illustration Day 1, John in Sydney User data/profile/registry Service Lookup Service download Day 2, John in Montreal Back-end service execution Home, office, shop, etc.

20. Loading Overheads

21. 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

22. Architectural 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

23. Implementation 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.

24. Technical Approach • Develop a Y 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

25. 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

26. Current 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

27. Team 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)

28. Competition • 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, WirelessKnowledgeMany universities, government • Numerous competition, but huge business & innovation opportunity

29. Related 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

30. What Ψ is Not 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

31. Summary • 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

32. Pervasive Computing Landscape user studies information architecture XML UDDI VML … security mgmt pricing/ charging development adaptivity user/agent model (intelligence) application model (information access & presentation) nomadic task mobility global data placement location transparency context management Y internet com (IP) mobile com. (non IP) service connectivity device connectivity Y