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

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

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

Understanding Code Mobility Kendrick J. Hang April 5, 2000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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