Dynamic Component Composition for Functionality Adaptation in Pervasive Environments

1. Dynamic Component Composition for Functionality Adaptation in Pervasive Environments N. Belaramani, C.L. Wang, and F.C.M. Lau The Systems Research Group Department of Computer Science & Information Systems The University of Hong Kong

2. Overview • Mobile & Pervasive Environments • Undeniable emerging trend • Main Requirement in Mobile & Pervasive Computing: • Software must be able to adapt dynamically • Functionality Adaptation • One of the most versatile adaptation techniques • Makes software very dynamic • Our Solution: • Dynamic Component Composition • Software is assembled at run-time • Facet Model & Sparkle System • Illustrates the feasibility of dynamic component composition in a mobile pervasive environment

3. Pervasive Environments • Advances in Wireless technology Wireless Lans 54Mbps GPRS 114kbps Bluetooth 1-2Mpbs

4. Pervasive Environments • Gadgets with wireless connectivity

5. Pervasive Environments • Lots of mobile devices

6. Pervasive Environments • Lots of Users Worldwide Mobile Terminal Sales 2001 – 412 Million 2002 – 425 Million 2003 – 475 Million 2004 – 501 Million 2005 – 545 Miliion (Source: Gartner Dataquest Jan 2003) Worldwide PDA Shipments 2001 – 13 Million 2002 – 14 Million 2003 – 17 Million (Source: Gartner Dataquest July 2002)

7. Pervasive Environments • The Dream: • Pervasive Computing should enable uses to carry out Computing Anytime Anywhere from Any Device

8. Pervasive Environments • Still not Completely a Reality • Why? • Software architecture is not yet ready • Main Characteristic • Heterogeneity and Run-time Change • Device Configurations • Network Infrastructure • Environmental Factors • User Preferences • Main focus for software: • Ability to ADAPT

9. Adaptation • It is the means to change a run-time characteristic in response to a trigger • Change a certain property, parameter or metric • Data Adaptation • Network Level Adaptation • Energy Adaptation • Migration Adaptation • Functionality Adaptation

10. Functionality Adaptation • Computing provides users means to carry out certain tasks • Applications are essentially groups of functionalities which enable users fulfill these tasks. • Functionality Adaptation • Adapting the way these functionalities are carried out • Changing the execution of the application • Most versatile adaptation technique • Example, • In cases of bad network conditions, only subject of emails are downloaded, rather than the whole messages when viewing inbox • If less memory is available, a more memory efficient, but requiring more processing time, algorithm can be used.

11. Components Dynamic Component Composition • Applications are made of Components • Brought in from the network, and linked at run-time when they are required • Unlinked and discarded after use. • “GET-USE-THROW” Application

12. Dynamic Component Composition • Applications are made of Components • Brought in from the network, and linked at run-time when they are required • Unlinked and discarded after use. • “GET-USE-THROW” Components

13. Dynamic Component Composition • Applications are made of Components • Brought in from the network, and linked at run-time when they are required • Unlinked and discarded after use. • “GET-USE-THROW” Components

14. Dynamic Component Composition • “Unlimited” Functionality • Discarding unwanted components frees up resources to bring in other components • Size of the application is not a concern • Intuitive support for functionality adaptation • Components suitable for the run-time environment are brought in • Applications are dynamically extensible and adaptable

15. Facet Retreival Co-operative Caching Execution Servers Intelligent Proxies Service Providers Computational Grid Facet Query Clients Facet Servers Peer-to-Peer Interaction Delegation/ Mobiie code Sparkle Mobile Computing System

16. Sparkle Mobile Computing System • Utilizes Dynamic Component Composition in a Mobile Environment • Applications are made of components – Facets • Each facet fulfills certain functionality • Facets brought in at run-time, executed, then discarded

17. Facet Model • Functionality • single well-defined task in an application • E.g. blurring an image, matrix multiplication • Given a set of inputs, it determines what changes are made and the outputs attained • Contract which specifies • Set of input & output parameters • Description of what is carried out • Pre-conditions and Post-conditions • Side effects • In our model, it is identified by a funcID

18. Facet Model • Separation of functionality from Data and UI • Facets • Pure functional units • Downloaded to client devices on demand • Implement single functionality • single publicly callable method • No residual state • Functionality provided by a facet is independent of any previous invocations • Makes it throwable & replaceable at run-time

19. Facets • Made up of 2 parts • Shadow • specifies properties of the facet • General info: facetID, vendor, version • Functionality info: funcID • Resource requirements: memory, processing, etc • Dependencies • XML based • Code Segment • Executable code to achieve the functionality • Does not keep any permanent state

20. Facet Request • Facet Specification sent to proxy • Functionality, funcID • Other criteria such as vendor, version • Resource Conditions • Memory, processing power, network conditions • Proxy identifies a suitable facet and sends it to the client • matches the criteria with the shadows of the facets available • Finds a facet suitable to run under specified resource constraints

21. x x i j k p q r i j k A B A A B A i j k p q r i j k s t D E F C m n x y G H I g e f Facet Dependencies • Facets may call upon other facets to achieve their functionality • Note: Functionalities have no dependencies • At run-time, different conditions may lead to different execution trees

22. x i j k p q r i j k A B A Execution point s t C Facet Dependencies • During execution, facets which are no longer active can be thrown • Inactive Facet • already executed • completely Facet which Has not yet been Brought in/loaded Active Facet - currently running

23. Check Mail Send Message Print Message Application Functionalities Trash Message Pluggable UI Change Font Facet Spec. 1 Facet Spec. 2 Facet Spec. 3 Storage Area Facet Spec. 4 Facet Spec. 5 Containers • Application-like abstraction • Interacts with the user through the UI • Provides a place to store run-time state • Provides Specifications of the root facets

24. Sparkle Client System Facets and Containers Facet Specification Client System Resource Information Central Manager Get Info Find network entity Proxy Resource Manager Discovery Manager Migrate Send Request LMCS Discard Facet Unload Facet Peer Facet Cache Migration Information Loaded Facet Location of Proxy or Peer Facet Facet Load Facet Network Handler Facet Facet Loader Facet Throw Facet Java Virtual Machine Host Operating System

25. Testbed • Client System • Compaq iPAQ PocketPC H3870 • CPU: 206MHz Intel StrongARM, 32-bit RISC • Memory: 32MB RAM + 32MB Flash • OS: Familiar Linux v0.5.2 • JVM Blackdown-1.3.1-RC1 • Proxy • Ordinary PC • CPU: Intel Pentium II MMX 300MHz • Memory: 128MB RAM • OS: RedHat Linux 7.1 • Web Server: Apache 1.3.19-5 • PPP Deamon: ppd version 2.4.0 • Serial Connection • 115.200kbps

26. Timing Analysis • Timing breakdown of sending a specification to the client system and receiving an loaded facet and a ready to use instance • Range of facets sizes: • JAR: 1KB to 69KB • Code Size: 1KB to 500KB • Largest time consumers • Getting facets from network • Transmission rate: ~ 80kbps • Latency: ~ 2.3 s • Loading the received bytes into JVM and creating instance • Depends on JVM implementation & processing power

27. Effect of References • We look into the effect of references on performance • Strong references • Facets are never discarded • Takes more memory • Soft references • Discarded by GC • Weak references • Discarded by GC • No references • Facets in “garbage” as soon as it is used • Saves memory • Result: • Not much difference between strong and soft ref. • Weak ref and no ref. have poor performance • Not much difference between the different memory configurations

28. Effect of Caching • Investigate if the number of entries of cache has an effect on performance • Soft references were used, heap size 4MB • As cache size increases, less requests are directed to the network, increasing performance

29. Image Processing Application • To illustrate the feasibility of developing a real-world application utilizing the facet model (5) Sizing (3) Image rendering (1) Image Viewer (2) Menu (4) Negative

30. Summary • Main Requirement in Mobile Computing: • Software must be able to adapt dynamically to change and variation • Functionality Adaptation • One of the most versatile adaptation techniques • Makes software very dynamic • Our Solution: • Dynamic Component Composition • Software is assembled at run-time • Facet Model & Sparkle System • Illustrates the feasibility of dynamic component composition in a mobile environment

31. Contributions • Employing Functionality Adaptation (FA) in Pervasive Computing • Proposed Dynamic Component Composition as a solution to achieve FA • Defined the Facet Model • Illustrated the feasibility and applicability of the facet model

32. Related Publications • N. Belaramani, C.L. Wang, and F.C.M. Lau, “Dynamic Component Composition for Functionality Adaptation in Pervasive Environments”, 9th IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS 2003), San Juan, Puerto Rico, May 2003. • V.W.M. Kwan, F.C.M. Lau, and Cho-Li Wang, “Functionality Adaptation: A Context-Aware Service Code Adaptation for Pervasive Computing Environments,” 2003 IEEE/WIC International Conference on Web Intelligence (WI 2003), Halifax, Canada, October 2003.

33. The End More information : http://www.csis.hku.hk/~clwang/projects/sparkle.html