1. Problem On a regular basis we use: –Java applets –JavaScript –ActiveX –Shockwave Notion of ubiquitous computing

2. Problem code mobility –the capability to dynamically change the bindings between code fragments and the location where they are executed

3. Problem Although code mobility is not a new concept, the field is still immature We lack a framework of well-defined: –Terminology –Methodology

4. Understanding Code Mobility Kendrick J. Hang April 5, 2000

5. Agenda Characteristics of mobile code systems Survey of a framework: –Technologies –Design Paradigms –Application Domains Summary Questions

6. Mobile Code Systems Process Migration –Transfer of an OS process between machines Object Migration –Transfer of objects between address spaces Not enough for large-scale systems

7. Mobile Code Systems Code mobility exploited on an Internet scale Programming is location aware Mobility is under programmer control

8. Mobile Code Systems Goal: address a wide range of requirements –Service customization –Dynamic extension of application functionality –Autonomy –Support for disconnected operations

9. Technologies Programming languages and (runtime) supports that provide mechanisms that enable and support code mobility Used by the application developer

10. Technologies Distributed System vs. Mobile Code System w.r.t. the Virtual Machine

11. Technologies Two forms of mobility Strong mobility –Migration of code and execution state of an executing unit (a thread) Weak mobility –Migration of code –Possibly some initialization information

12. Technologies Mechanisms that support mobility Strong mobility –Migration –Remote cloning Weak mobility –Fetch or ship –Standalone or fragment –Synchronous or asynchronous

13. Technologies What happens during migration? Data Space Management Resources are bound to execution units by: –Identifier –Value –Type

14. Technologies Examples of technologies described in Fuggetta, et. al. Java (Sun Microsystems) –Mobility was not the original goal, but it is now –Weak mobility for fetching code (only) –No bindings or data space management

15. Design Paradigms The architectural styles that the application designer uses in defining the application architecture Architectural style = configuration for system components and their mutual interaction

16. Design Paradigms Technology does not determine the design paradigm A good programming language does not imply a good program Traditional approaches are not enough

17. Design Paradigms Concepts –Components (code and resource) are the basic units –Interactions are events between components –Sites host and support execution of components

18. Design Paradigms Three main design paradigms –Remote evaluation –Code on demand –Mobile agent

19. Design Paradigms Characteristics of paradigms –Location of components before and after execution of service –Computational component which is responsible for execution –Location where service takes place

20. Application Domains Classes of applications that share a common goal But first, the benefits…

21. Application Domains Benefit: S/W Deployment and Maintenance –Upgrading programs over the Internet –Can be automated

22. Application Domains Benefit: Fault Tolerance –Partial failures and consistency issues –Computational state is encapsulated –Better fault tolerance compared to the client-server model

23. Application Domains Benefit: Service Customization –Protect the server from change when services need to be changed or customized –Server provides basic operations only –Interface is dynamic

24. Application Domains One application domain stands out… Electronic Commerce –Evolving Transactions –Customization –Move application to information instead of vice-versa

25. Application Domains Other Applications –Distributed Information Retrieval –Active Documents (Java applets on the Web) –Advanced Telecom Services –Remote Device Control –Workflow Management

26. Summary Research in mobile code technologies alone, no formal discipline exists Proposed Conceptual Framework –Applications –Design paradigms –Technologies